We recently completed the delivery of a Realistic Threat PCI focused Penetration Test for a large retail company. As is always the case, we don’t share customer identifiable information, so specific details about this engagement have been altered to protect the innocent. For the sake of this article we’ll call the customer Acme Corporation.
When we were first approached by the Acme Corporation we noticed that they seemed well versed with regards to penetration testing. As it turned out, they had been undergoing penetration testing for more than a decade with various different penetration testing vendors. When we asked them how confident they were about their security they told us that they were highly confident and that no vendor (or hacker to their knowledge) had ever breached their corporate domain let alone their Cardholder Data Environment (CDE). We were about to change that with our Realistic Threat Penetration Testing services.
Realistic Threat Penetration Tests have specific characteristics that make them very different from other penetration tests.
The minimum characteristics that must be included for a penetration test to be called Realistic Threat are:
- IT/Security Staff must not be aware of the test.
- Must include solid reconnaissance.
- Must not depend on automated vulnerability scanners.
- Must include realistic Social Engineering not just elementary phishing.
- Must include the use of undetectable (and non-malicious) malware.
- Must be covert as to enable propogation of compromise.
- Must allow legitimate incident response from the customer.
Lets begin…
As with all engagements Netragard’s team began with reconnaissance. Reconnaissance is the military term for the passive gathering of intelligence about an enemy prior to attacking the enemy. It is what enables our team to construct surgical plans of attack that allow for undetected penetration into targeted networks. During reconnaissance we focus on mapping out all in-scope network connected devices using truly passive techniques and without making direct network connections. We also focus on passive social reconnaissance using everything from Facebook to LinkedIn to Jigsaw.
When Netragard finished performing reconnaissance against Acme Corporation it became apparent that direct technological attacks would likely not succeed. Specifically, Acme Corporation’s externally facing systems were properly patched and properly configured. Their web applications were using a naturally secure framework, appeared to follow secure coding standards, and existed behind a web application firewall. Firing off technological attacks would do little more than alert their IT staff and we didn’t want that (their IT staff were deliberately unaware of the test).
Reconnaissance also identified a related job opportunity posted on LinkedIn for a Sr. IT Security Analyst. Interestingly the opportunity was not posted on Acme Corporation’s website. When Netragard reviewed the opportunity it contained a link that redirected Netragard to a job application portal that contained a resume builder web form. This form was problematic because it worked against our intention to submit a RADON infected resume to HR. We backtracked and began chatting on LinkedIn with the lady who posted the job opportunity. We told her that the form wasn’t loading for us but that we were interested in applying for the job. Then she asked us if we could email our resume to her directly, and of course we happily obliged.
Our resume contained a strand of RADON 2.0. RADON is Netragard’s zeroday malware generator designed specifically with customer well-being and integrity in mind. A strand is the actual malware that gets generated. Every strand of RADON is configured with an expiration date. When the expiration date is reached the strand entirely removes itself from the infected system and it cannot be run again. RADON was created because other tools including but not limited to Metasploit’s Meterpreter are messy and leave files or even open backdoors behind. RADON is fully undetectable and uses multiple, non-disruptable covert channels for command and control. Most importantly when RADON expires it leaves systems in a clean, unaltered, pre-infection state.
Shortly after delivering our infected resume, RADON called home and had successfully infected the desktop belonging to the nice HR lady that we chatted with on LinkedIn. Our team covertly took control of her computer and began focusing on privilege escalation. RADON was running with the privileges of the HR employee that we infected. We quickly learned that those privileges were limited and would not allow our team to move laterally through the network. To elevate privileges we impersonated the HR employee that we compromised and forwarded our infected resume to an IT security manager. The manager, trusting the source of the resume, opened the resume and was infected.
In short time RADON running on the IT security manager’s desktop called home. It was running with the privileges of the IT security manger who also happened to have domain administrative privileges. Our team ran procdump on his desktop to dump the memory of the LSASS process. This is important because the LSASS process contains copies of credentials that can be extracted from a dump. The procdump command is “safe” because it is a Microsoft standard program and does not trigger security alerts. However the process of extracting passwords from the dump often does trigger alerts. To avoid this we transferred the dump to our test lab where we could safely run mimikatz to extract the credentials.
Then we used the credentials to access all three of Acme Corporation’s domains and extracted their respective password databases. We exfiltrated those databases back to our lab and successfully cracked 93% of all the current and historical passwords for all employees at Acme Corporation. The total elapsed time between initial point of entry and password database exfiltration was 28 minutes. At this point we’d reached an irrevocable foothold in Acme Corporation’s network. With that accomplished it was time to go after our main target, the CDE.
The process of identifying the CDE required aggressive reconnaissance. Our team searched key employee desktops for any information that might contain credentials, keys, vpn information, etc. Our first search returned thousands of files that spanned over a decade. We then ordered the files based on date of modification and content and quickly found what we were looking for. The CDE environment could only be accessed by two users via VPN from within Acme Corporation. Making things more complex was that the VPN was configured with two-factor authentication was not tied into the domain.
Fortunately for us, this is not the first time we’ve run into this type of configuration. Our first step towards breaching the CDE was to breach the desktop of the CDE maintenance engineer. This engineer’s job was to maintain the systems contained with in the CDE from both a functionality and security perspective. To do this we placed a copy of RADON on his desktop and executed it as a domain administrator using RPC. The new RADON instance running on the CDE maintenance engineer’s desktop called home and we took control.
We quickly noticed that various VPN processes were already running on the CDE maintenance engineer’s desktop. So we checked the routing table looking for IP addresses that we knew to be CDE related (from the files that we gathered earlier) and sure enough they existed. This confirmed that an there was an active VPN session from our newly compromised desktop into the CDE. Now all we had to do was hijack this session, breach the CDE, and take what we came for.
We used the net shell command (netsh) and created a port forward rule from the infected desktop to the CDE. We then used a standard windows RDP client to connect to the CDE server but when we tried to authenticate, it failed. Rather than risking detection, we decided to take a step back and explore the CDE maintenance engineer’s desktop to see if we could find credentials related to the CDE. Sure enough we found an xls document in a folder named “Encrypted” (which it wasn’t) that contained the credentials that we were looking for. Those credentials allowed us to to log into the CDE without issue.
When we breached the CDE we noticed that our user was a domain administrator for that environment. As a result not only did we have full control over the CDE but our activity would appear as if it were normal maintenance rather than hacker related. In short time we were able to locate customer credit card data, which was properly encrypted. Despite this we were confident that we’d be able to decrypt it by leveraging discoveries from our previous reconnaissance efforts (we did not make that effort at the customers request).
When we began exploring avenues for data exfiltration we found that the CDE had no outbound network controls. As a result, if we were bad actors we could have sent the credit card data to any arbitrary location on the Internet.
In summary, there were three points of failure that enabled our team to breach the CDE. The first point of failure is unfortunately common; network administrators tend to work from accounts that have domain administrative privileges. What network administrators should do instead is to use privileged accounts only when needed. This issue is something that we encounter in nearly every test that we do and it almost always allows us to achieve network dominance.
The second point of failure was the VPN that created a temporary bridge from the LAN to the CDE. That VPN was configured with split tunneling. It should have been configured in such a way that when the computer was connected to the CDE it was disconnected / unreachable from the corporate network. That configuration would have prevented our team from breaching the CDE with the described methodology.
The third point of failure was that the CDE did not contain any outbound network controls. We were able to establish outbound connections on any port to any IP address of our choosing on the Internet. This means that we were in a position to extract all of Acme Corporation’s credit card data without detection and without issue. Clearly, the correct configuration would be one that is highly restrictive and that alarms on unexpected outbound connections.
Finally, the differences between compliance and security are vast. In the past decade we’ve seen countless businesses suffer damaging compromises at the hands of malicious hackers. These hackers get in because they test with more talent, more tenacity, and more aggression than nearly all of the penetration testing vendors operating today. For this reason we can’t stress how important it is that businesses select the right vendor and test at realistic threat levels. It is impossible to build effective defenses without first understanding how a real threat will align with your unique risks. At Netragard, we protect you from people like us.
