Adding Pentest Sauce to your Vulnerability Management Recipe

Posted on August 6th, 2017

One question we get after performing a penetration test is “Why didn’t I see some of these vulnerabilities during our monthly vulnerability scans?” The truth of the matter is many flaws that both attackers and pentesters exploit do not typically show up in a Nessus, Nexpose, or [insert-vuln-scanner-name-here] scan. Most senior penetration testers and attackers will seldom leverage a vulnerability scanning tool as it’s very noisy on a network and can get you detected/removed/bandwidth issues/etc.

Some pentesting techniques require manual testing and a creative attacker mindset.  With that said, there are several things pentesters do regularly that could be adopted into a vulnerability management program.

Goal: Show how vulnerability analysts can go beyond running an authenticated vulnerability scan.

Here are the tips at first glance (in no particular order) :

  1. Have an understanding of free tools you can use
  2. Find the tech stack
  3. Understand your external footprint
  4. Investigate network shares
  5. Address web applications appropriately
  6. Find devices and appliances
  7. Know what vulnerabilities are interesting to attackers
  8. Be aware of the impact of outdated Windows systems
  9. Understand OPSEC failures and the impact
  10. Implement user awareness exercises

1) Have an understanding of free (open source) tools you can use:

Reconnaissance is King: The most important step associated with hacking, and pentesting is reconnaissance. Many of the tools mentioned above are focused around reconnaissance vs. exploitation and could be considered for a vulnerability management program.

 

2) Find the tech stack: Identify the technology and its versioning to check for default credentials, default content, version specific vulnerabilities and misconfigurations:

  • Many vulnerability scanner tools attempt to identify all these items, but can fall short especially with web technologies.
  • We can’t tell you how many times we have compromised a system simply by figuring out the technology in use and checking Exploit-DB/Google.
  • Many technologies are configured with weak authentication mechanisms in place or No Auth! (SCADA, Printers, Network Cameras, etc.)
  • Nmap -> Parse + Build URL list -> EyeWitness (or Whatweb) -> Attempt default credentials.
  • Wappalyzer browser plugincan make this a lot easier as you browse.

3) Understand your external footprint:

  • Many organizations do not have an external testing box for their vulnerability management team. This can be accomplished relatively inexpensively using cloud-computing services.
  • You can also leverage online databases that will provide you with some idea of what is exposed to the Internet: Censys.io and Shodan! Check out our full blog on this here: https://breakpoint-labs.com/blog/reconnaissance-with-shodan-and-censys/

4) Investigate network shares:

  • What you’ll find: VMs, databases, configuration files, scripts, sensitive group policy files, PII, Data Backups, etc.
  • Smbmap and enum4linux can be useful tools to help automate some reconnaissance around network shares.
  • Parse Nmap for systems with SMB open and extract the IP, then for loop over smbmap command:

5) Address web applications appropriately:

  • Get some skills with Burp Suite and add in some manual testing!
  • Don’t rely on network vulnerability scanners to identify web app flaws.
  • Have a clear picture of what content management systems (CMS) and Web Server technologies are on your network.
  • Consider adding in a web application vulnerability scanning tool (Example: Acunetix), if only for externally exposed applications.
  • Be sure to not only update the core web technologies but the plugins associated as well. 

For further detail on identifying web application vulnerabilities reference: https://breakpoint-labs.com/blog/webapp-vulns/

6) Find the devices and appliances:

  • Printers, NAS, Network Cameras, SCADA, etc.
  • Usually a detailed review of a Nmap scan can go a long way to enumerate the oddball devices and appliances.
  • These are often configured poorly on internal networks (Default Creds FTW!)
  • Review these devices and appliances for excessive ports/services being available on the network.

7) Know what vulnerabilities are interesting to attackers:  

8) Be aware of the impact of outdated Windows systems on your network:

  • Does your organization have any legacy system(s) (Windows XP, Windows Server 2003, etc) on the domain?
  • We commonly see this as accepted risk simply because organizations do not understand the impact.
  • Attackers can get elevated access to these systems easily (MS08-067…) and then dump credentials from memory (Mimikatz), grab hashes, etc. and pivot to additional access.
  • Outdated Windows systems are often the first crack that leads to full domain compromise.
  • Getting local admin on these boxes is really easy…is that shared across your network?
  • These types of dated systems literally get birthday cakes made at hacker conferences!

9) Understand OPSEC failures and the impact:

  • We have yet to go on a penetration test where we have not gathered credentials from sticky notes or note pads left out and around users workstations.
  • We suggest the security analyst do some regular walk-through of the environment for these types of OPSEC failures.

10) Implement user awareness exercises:

  • Consider adding in some harmless phishing exercises focusing on click analysis.
  • Users tend to commonly think, “It will never happen to me…” until it does.
  • Checkout free tools such as GoPhish, Lucy, Phishing Frenzy, etc.

All of these techniques are obviously great for security in a perfect world. In reality there are only so many hours in the day and security analysts can get spread thin. If this is the case focus on understanding your external footprint first and then consider implementing the other tips as resources allow.

Share This:
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInEmail this to someone