Efficient Infrastructure Testing

Before we start let’s set the scene regarding vulnerability assessment. It is imperative that enterprises conduct their own continuous automated scanning, to have up-to-date assessments of threats that their networks may be susceptible to. Infrastructure penetration testing (discussed in this blog post) should be then used to delve further to expose issues and attack chains using manual testing that would have not been uncovered by automated techniques.

To go one step further, mature environments with well-formed patch management policies and good security practice, should then consider Red Team engagements to assess response and detection against emulated real-world adversaries.

On several  infrastructure tests I’ve found myself performing vulnerability assessments on expansive networks. While Nessus and other scanning tools have their place, it is crucial to be able to work efficiently to provide much more value on an engagement rather than providing tool output that clients can run themselves (and should be doing, regularly).

Introduction

Using tools efficiently allows much more time to be spent on performing manual testing. There’s little value in paying a pen tester to simply run scans! Below I outline how I have practised this art, and while in this industry everyone works differently which is a reason that makes this industry so great, this is how I skin my cat.

TL;DR, here’s a list of tools and scripts to get you going:

Nessus – de-facto vulnerability scanner

Sparta – Infrastructure scanner GUI written by SECFORCE

My extended configuration (installer script can be found within the helper-scripts README file)

Scrying / Eyewitness– RDP / Web / VNC screenshotters

Default Creds / seclists – Database of known vendor default credentials / wordlists

nessusToExcel.py – A python Nessus output parser script written by me to ease reporting

Getting started

Unsurprisingly, the first port of call is to run Nessus. While the scan chugs away you can be getting on with the productive work, rather than waiting for results. This is where Sparta comes in. For me Sparta is an underrated tool as it’s a GUI and “real hackers don’t use GUIs”. However, it is essentially a wrapper for nmap and is hugely customisable. Admittedly, as it has not received any updates for a few years and can be clunky at times.

We begin by providing our targets to scan:

To provide more clarity on the two options here:

• Perform initial arp / ping sweeps to discover hosts, or run scans with -Pn (required when ICMP has been disabled but does significantly increase scanning time)
• Run a staged scan (explained further below) or run a full TCP scan.

As per the CHECK guidelines, all 65535 TCP and the top 1000 UDP ports are required to be scanned. Many testers will have experienced the pain of scanning a subnet for the estimated time to exponentially go up. Staged scanning splits these into five different scans, beginning with TCP port 80 and 443 which completes almost instantly, allowing me to start prodding all the web portals within the network. As further scans complete, the results get added into the database for later analysis.

Identifying default credentials

Now the fun can begin! Each command is contextualised depending on what service has been identified, in this example we will look at Microsoft SQL servers:

As several of these services were identified within my scanned network, right clicking the “ms-sql-s”  service within the services tab will run this command against all found databases. The tool output can then be found within the “mssql-default” section which identifies a host possessing a default sa password:

Under the hood within the sparta.conf file, the structure of the command is as follows:

<NAME>=<DESCRIPTION>, <COMMAND>, <SERVICE>

mssql-default=MSSQL - default credentials, hydra -s [PORT]
-C /usr/share/seclists/Passwords/Default-Credentials/mssql
-betterdefaultpasslist.txt -u -o \"[OUTPUT].txt\" -f [IP] mssql, ms-sql-s

Note – My instance of sparta has been configured to use the default location of seclists when installed via apt.

While hydra is integrated into Nessus, this method of working creates much more control over what wordlists are used, as throwing the rockyou wordlist at every single management port is not going to do you any favours. However, adopting this approach has gained me access to 100s of SSH / SMB / FTP / Databases / VNC and RDP services which I may have missed before due to time constraints.

Extending Sparta

With over 100 different commands to run, this is just one example of sparta can be used, many of the other commands are running the appropriate NSE for that service. This can yield different results to Nessus as well as providing confirmation of the vulnerabilities it picks up.

In some instances, running a different command on a service is desired, this can be achieved by holding shift and right clicking the service on a single host. In this example the service is identified as “ccproxy-http”, as the configuration file does not recognise this service, we would like to see all commands and run nikto against this:

Another way of working with sparta is to perform the nmap yourself, then feeding the XML into the software, this will then populate the database as seen above. There is scheduler functionality which will automatically run commands when the appropriate service has been identified. Using my configuration file, you will see that is set to disabled as it may result in running unwanted commands.

Web interfaces

In these larger networks, it is not uncommon to see a multitude of different web endpoints, each with their own set of default credentials. Testing these on each one is not such an easy task. scrying and eyewitness can provide screenshots of all http services within nmap / Nessus xml files and produces a tidy HTML report which categories each service dependant on their response code and headers:

If the default password is known to eyewitness, it will display these for you:

If the credentials are not found, then the DefaultCreds-cheat-sheet database can be queried for the vendor which can outputted in several different formats:

Reporting

Once Nessus has finished and all the tools have been executed, I need to report all the findings. My mantra of automation does not end there, my nessusToExcel python script parses Nessus XML reports into several Excel worksheets to ease data processing. By default, it will run all modules, but I will outline a few below (running -h will describe each module on the command line):

• HTTP – HTTP Servers and versions
• LastUpdated – Windows effective security patch levels
• Compliance – Format CIS Compliance data
• Issues – all plugins that are not informational severity
• Win/nix Patches – summary of missing security patches
• Remediations – third party software remediations

As expected, some of these will only output if the correct scan has been run, authenticated scan for patches, Compliance scan for compliance output etc. Several of these are very useful to clients as they provide an easy to digest audit of their network featuring a complete list of scanned hostnames, IP addresses and Operating Systems within the Host Information tab. HTTP / Open Ports / Databases tabs provide further detailed information.

When it comes to reporting my own issues, I find the “All Issues” tab invaluable as it allows me to group common vulnerabilities such as TLS configuration issues, outdated software etc. I have also hard coded relevant information where possible, such as operating system end of life dates when unsupported versions are discovered:

Final thoughts

Working in this fashion allows me to complete engagements to a high standard within the provided time. Often this also grants me additional time to extend the scope (if the client permits of course) to provide even more value. Commonly this involves performing more in-depth testing of the Active Directory rather than a vulnerability assessment of the Domain Controller. These results typically end up substantially reducing the attack surface within the tested estate, often more than the results of the vulnerability assessment itself.