Security Risk Advisors

Plastic Beach: Gaining Access to CDEs

January 11, 2016 | Posted in Red Teams by Dan Astor

Penetration testing engagements should begin with a mutually-agreed "trophy list" which represent the assets to be targeted for proof-of-concept compromise. During our penetration tests where PCI systems are in-scope, accessing the CDE and the coveted clear text credit cards (PANs) is always the top trophy.

This story from the field illustrates how companies who have been practicing PCI compliance can still be compromised through persistent attack, smart use of open source and custom tools (but not necessarily malware or 0-days) and porous network segmentation. We also provide recommendations to improve controls through better lockdown and detection.

Quick Definitions

Before getting started, let's define some terms that will be key to understanding this post:

  • Cardholder Data Environment (CDE): The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.
  • Network Segmentation: Isolates system components that store, process, or transmit cardholder data from systems that do not. Note: For the purposes of this blog post, we'll mainly be focusing on network segmentation around CDE's.
  • Jump Box: A system that is connected to two networks; the first of these networks is a common network (user LAN), the second network is the sensitive security zone (CDE).
  • Plastic Beach: The datastore containing clear text credit card numbers (PANs)

Step 1: Compromise the Domain

Beginning just like any other penetration test, we use our methodology that begins with stealthier attacks and slowly progresses to noisier ones throughout the week. Fortunately for us, we were able to compromise a domain administrator account hash in about 15 minutes using the tool Responder, which performs LLMNR (Link Local Multicast Name Resolution) spoofing. Using ocl-Hashcat and our GPU cracking server, we made light work of the fairly weak NetNTLMv2 password hash granting us the clear text password. Using our new domain admin credentials we dumped the domain controller to obtain the password hashes for all domain accounts. We also began identifying key systems and applications within the environment including their privileged account management (password vault) application.

Step 2: Let's Go Hunting

Given that we had the ability to access every user's Windows domain password and system, we began our hunt for access to the CDE. Leveraging network file shares and document repositories such as SharePoint, we began identifying documents relating to PCI and ultimately the CDE. Of the documents found, network diagrams and IT guides were the most helpful as it provided us with the means to understand the architecture of how the CDE was "segmented", where those systems resided, and how users were able to access systems residing within the CDE. After attempting to use the defined methods listed within these documents, we were somewhat surprised to find we were still sitting in the user LAN From what we were able to gather, it seemed a custom service would have to be initiated manually on any system attempting to gain access to the jump box that would allow us access into the CDE.

While grabbing additional trophies on our list and finding alternate initial footholds onto the network, we stumbled across a list of helpful links used by the IT and Network Operations teams. One of which was for a CentOS Linux server running Nagios, an infrastructure monitoring tool. Having the root account to this system from the password vault, we authenticated to the server over SSH. To our surprise, the network port scanning tool Nmap had already been installed, so a quick scan from that host to the CDE systems gave us a full listing of the open ports we needed.

Step 3: Port Forwarding Black Magic

Now that we had identified a path to talk directly to the CDE, we had found a potential way in. At this point we split up tasks:

Task 1: Become the Database Administrator (DBA). We were able to borrow the DBA's credentials because we already owned the Windows domain and its passwords. It was therefore trivial to identify the name of the DBA and password, and then retrieve additional privileged database credentials from the password vault. Done.

Task 2: Connect to the CDE. We needed to determine a method to connect into the CDE. Since there was a Microsoft SQL Server on the backend, Microsoft SQL Server Manager seemed like an obvious choice. We created a Perl-based port forwarding script (full source below) so it would run natively on Linux. The script starts a listener on a given port for connections to the host, and any connections it receives it forwards the traffic to our specified destination. Essentially, it creates a direct route from our attacking workstations in the corporate LAN to the server in the CDE. The following diagram depicts the action:

The following code is hosted on our GitHub

Conversely on a Windows based system, the following commands can be used to perform a similar task:

The following code is hosted on our GitHub

Step 4: Breaching Plastic Beach

Once the port forward was in place, we attempted to make our connection to the database. After supplying all the necessary information and aiming it at the Linux server we hit enter and we watched our connection get passed through to the CDE server. Voila, we were in! Now we needed to prove that we had the ability to get clear text PANs. After combing through oddly named tables and columns and a few SQL SELECT statements later, we found the table we were looking for and used a LUHN checking tool to assist in validating that we did in fact have clear text credit cards. As a proof-of-concept we took screen captures as evidence directly from our attacker machine which avoids most data loss prevention (DLP) rulesets if there were any in place.
Unfortunately for the client, all of these actions went completely undetected. While they did have monitoring and access controls setup for accessing the CDE using their "approved and documented" method, they did not have monitoring setup for the backend database connection. Additionally, they did not have controls in place to monitor access to any of the highly privileged accounts from the password vault. We worked with them to implement these recommendations and they are now able to monitor both the database and password vault for potentially malicious activity.

Remediation and Prevention

While we were successful in our attack to gain access to the CDE and ultimately obtain clear text credit cards for their customers, there are several things that can be done to prevent this from happening. As with many things in security, some are effort-intensive but absolutely worthwhile.

  • Multi-Factor Authentication (MFA) – Throughout our attack we leveraged the enterprise password management vault. The vault contains all the information an attacker needs in order to access applications or systems not using "AD Authentication", and should be classified as one of the most sensitive "crown jewels" on the network. While you can limit the credentials users have access to within the vault and log that access, MFA can help to prevent an attacker from gaining access in the first place. Another good spot for MFA on the internal network are the jump boxes which are used to access the CDE.
  • Password Management – Ensure that your highly privileged accounts (domain admins, enterprise admins, server admins, etc.) are using strong passwords and the accounts are separate from user's standard domain account. While you may not be able to implement password blacklisting through AD, user awareness, password managers/vaults, and quarterly reviews of account passwords can go a long way.
  • Logging and Monitoring – Whether it was within the password vaulting application or the database connection to the CDE server, alerts were not triggered. Only a very select subset of users should have the ability to access the CDE and password vault, so any activity outside of normal maintenance windows should be investigated. In addition; monitoring privileged access to databases and servers with a SIEM can help to aggregate and normalize the access logs quickly, and alert on any anomalous behavior.
  • Endpoint Detection and Response (EDR) – In addition to logging and monitoring for Servers, Network Appliances and Security tools, an EDR tool can also provide many benefits to security operations teams. While some of the attacks we performed may have been difficult to detect, having an EDR tool installed on endpoints can greatly improve the capabilities of an incident response team needing to pull relevant information from the host to examine what was done during the compromise. Some EDR tools are highly customizable and could allow rules to detect the odd behavior of our port-forwarder being used to connect into the CDE from the user LAN.
  • Network Segmentation – Probably the hardest of all the steps to implement and do properly. Ultimately, having the network properly segmented would have thwarted our attack. When it comes to network segmentation there two general approaches that can be taken to allow access:
    • Create a host within each restricted network, which is the only host to which the corporate network has access. This host would be considered a jump host which will allow access into the CDE.
    • Create a transitory network which has access to more sensitive networks. Then create hosts within this network to access more specific networks. This is ideal for non-interactive processes.
    Depending on the approach, Microsoft has recently provided guidance on the use of Privileged Access Workstations (PAWs), which can be used to perform sensitive tasks and access sensitive networks.