In this series focusing on Active Directory attacks, we’re running through four different scenarios based on real penetration testing engagements that demonstrate the variety of techniques and tactics that can be used to compromise Active Directory. In part one, we explored how attackers can take advantage of ignored assets like network connected printers and use them as attack vectors, eventually gaining control of domain admin. In this second scenario, we’ll explore how to use domain admin control as a means to get to an organization’s most valuable assets.
Assumed Breach: Beginning with Elevated Privileges
Penetration testing engagements are not always about what it takes to gain access to an IT environment from an external starting point. Much of the time, testers demonstrate what an attacker would do once inside—how they pivot between systems and escalate privileges. In this case, we began with domain administrator privileges with a goal of assessing the security of the PCI network, which consists of systems that impact the cardholder data environment (CDE) of an any organization that handles credit card payments.
Deploying Agents to Gain Insights
We started by deploying a Cobalt Strike agent—a C2 implant—in one of the servers in order to inspect its inner workings. With this visibility, we explored the network interactions, observing several connections to an Oracle database which could potentially house payment related information. After inspecting web application logs from an application that was running on the server, we found indicators that credit cards were likely being handled or processed by this application.
Uncovering Sensitive Information
With this evidence in hand, we next retrieved the web config file, from which we pulled the database credentials. Using these credentials, we accessed the database to see if our theory was correct. Just as we suspected, it was storing credit card numbers for different users. However, they were encrypted, so more work would need to be done before someone could extract and use these numbers.
Commandeering Built-In Decryption
Consequently, our next step was to explore the possibility of deciphering these numbers. We dug deeper to see if decrypting capabilities were available in the payment application that we looked at earlier. It turned out that the application wasn’t obfuscated in any way, so it was fairly easy to decompile DLL services using DNSpy. We found an interesting class called PaymentWrapper that implemented a method called SaveCardInfo. This method called another method, EncodeDecode String, which was being used to encode and decode information from the database. Some of the information was hard coded in the source code, exposing private data. For example, we were able to pull credentials for the SOAP service that the app was using for encryption and decryption.
At this point, we had gathered a great deal of information from the web config file, the decompiled DLL, and the database itself. We had the username, password, SOAP API endpoint, database name, and more. Combining all of this information would allow us to recreate and complete the EncodeDecode method call ourselves, enabling us to extract decrypted credit card numbers.
Validating the Process
When we initially pulled the user information, including the encrypted credit card numbers, there was a column that listed the last four digits of the credit card numbers. These are often listed separately and left unencrypted as way for applications to verify card in payment information processes in which a user has saved their credit card information. They are able to select and verify their saved method of payment by seeing the last four digits of their card. For example:
We were also able to use these four digits to validate if our decryption had been successful. After extracting the decoded numbers, we compared them against these four numbers to ensure they matched up.
Conclusions: Going Beyond Compliance
While many attack scenarios focus on taking over Active Directory, it is also important to run engagements to demonstrate what could happen after domain admin control is achieved. In this case, it served as means of obtaining the company's most valuable assets. Ultimately, we found and compromised more than 26,000 credit card numbers being stored in the database.
This case also highlights the importance of both maintaining and surpassing compliance regulations. While PCI DSS explicitly requires internal penetration testing, many other regulations have more vague language around what type of assessments are needed. While it’s important to protect your perimeter as much as possible, no environment is impenetrable. Attention must also be paid to internal security controls that can help limit the damage of a threat actor who has breached the gates. By finding potential pivot points and privilege escalation opportunities, internal testing efforts are the safest way to find out just how severe the impact of such an attack may be.
Find out what else can happen after an attack on Active Directory
Find out how attackers attempt to achieve persistence in our webinar, Getting Inside the Mind of an Attacker: After the Breach - Next Steps After Compromising Active Directory.
