By: Rick Belisle, Managing Director at Cerberus Security
When it comes to penetration testing, you want to make sure you are selecting the right kind of test to meet your organization’s unique needs, but it can be easy to get lost in terminology. It’s important to understand the different types of security testing, how they compare, what they achieve, and who to trust in helping you navigate your options. Recently, we took a deep dive into collaborative pen tests that involve both a Red Team and Blue Team (purple team testing), to provide real-time remediation for vulnerabilities and gaps. In this week’s installment, we are going to cover standard Black Box testing.
The advantages of a Black Box Penetration Test are many, but rather than speak in theory about pros and cons, let’s first look at some specific scenarios where the Cerberus Security Testing Team has used this approach to meet client needs, and discovered critical issues that were previously missed by automated vulnerability scanners.
Scenario 1: External Black Box Penetration Test – Internet Key Exchange (IKE) Aggressive Mode Issue
In this engagement, the client had a VPN Server with IKE Aggressive Mode enabled. When IKE Aggressive mode is used the authentication hash is based on a Pre-Shared Key (PSK). This hash is transmitted in response to the initial packet of a VPN client trying to establish an IPSec Tunnel, which allows an attacker to grab the hash for offline cracking.
In this scenario, testing started by running Nessus, a vulnerability scanner. Nessus rightly identified the vulnerability with IKE Aggressive Mode as Medium Risk. The next step of our testing was to then attempt to exploit this issue, which allowed us to successfully capture the VPN PSK hash. Given that a weak password was used we were able to crack the hash in 19 minutes. Once the hash was cracked, we were able to connect to the client’s VPN giving us access to critical systems with Protected Health Information (PHI). We reported this to the client immediately as a Critical finding, as it provided remote access to their environment. We recommended the client resolve the issue by disabling IKE Aggressive Mode, using a much stronger passphrase, and configuring the VPN to leverage multi-factor authentication.
The result of this scenario was not only less risk for this client, but also better protection of their PHI. A “medium” finding, according to Nessus, however may not have been treated seriously or ever “gotten around to”. By fully exploiting the issue as part of a Black Box Penetration Test we were able to demonstrate the real risk to the environment, prompting the client to resolve it immediately.
Scenario 2: Internal Black Box Penetration Test – Owning the Domain
This engagement involved an on-site, internal Black Box Penetration Test. During this engagement, we visited the client’s facility, saw a free cubicle, unplugged the network cable from the computer at the cubicle, and plugged it into our laptop giving us instant access to the network. We then performed reconnaissance on the network using Nmap. Our Nmap results showed several web servers running on multiple ports. Manually browsing to these web servers, we discovered one of them was running the Tomcat manager interface. We were able to use a Metasploit tool to crack the Tomcat manager interface username and password, which allowed us to deploy a malicious war file to the server. The war file contained a payload that we encoded to avoid antimalware scans. We were then able to browse to our deployed “package” on the web server, which when executed gave us a shell. Utilizing the shell access, we ran the mimikatz tool to dump credentials from the system’s RAM that includes plaintext credentials for anyone that had recently connected to the server. One of the credentials from the dump included an Active Directory domain “service” account. At this point, with full domain access achieved we worked with the client to mitigate these issues.
It is worth noting that in this scenario, the client routinely performed vulnerability scanning and the vector we used to gain complete access was never identified as a vulnerability by the scanning software.
The outcome of this scenario resulted in the client’s implementation of several security controls including 802.1x, changing service account permissions, removing unnecessary services, and creating stronger passwords.
Unfortunately, many organizations have a false sense of security because they run a vulnerability scanning tool on a routine basis. We certainly believe this is a security best practice, however, a vulnerability scanning tool can not catch everything. If you’re concerned about the real cybersecurity risks to your organization, you may wish to consider adding a Black Box Penetration Test to your regular security practices.
Contact us with questions about what kind of test will best meet your needs.