Tips for Penetration Testing a PCI environment

Hello everyone! I put together a list of things to help me keep my PCI testing on track, not to mention just as a guideline to start discussions among others doing similar testing. This blog post is not an answer to everything PCI, but I think it’s a pretty good place to start. I pulled this information from https://www.pcisecuritystandards.org/document_library, specifically the PCI DSS v3.2.1 PDF.

Before you start, make sure you ask for (1) a current network diagram that includes all connections (PCI DSS 1.1.2), (2) PCI cardholder data flow diagrams (PCI DS 1.1.3), and (3) IP scope of CDE environment and any secondary networks (PCI DSS 1.1.4). When tasked with a wireless test, (4) gather a list of Authorized Access Points (PCI DSS 11.1.1).

For context, we call the computer from which we are conducting the testing, a Secure Ideas Attack Machine, or SIAM for short. It’s a device we connect to a network to give us the perspective of the environment from whichever subnet we’re placed on. This could change in several engagements, so, we’re going to cover the PCI test from several different viewpoints, starting with the most commonplace, outside of the CDE, the shared services and on a regular user subnet.

During the test:

Keep in mind that the penetration testing methodology has a goal in PCI, and the following describes what is needed for implementing that methodology (PCI DSS 11.3):

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)  
• Includes coverage for the entire CDE perimeter and critical systems
• Includes testing from both inside and outside the network  
• Includes testing to validate any segmentation and scope-reduction controls  
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
• Defines network-layer penetration tests to include components that support network functions as well as operating systems  
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months  
• Specifies retention of penetration testing results and remediation activities results

Get to know the documentation:

To understand an environment, you have to get to know the documentation the client is required to create that you requested previously. It’s necessary to use that as a context for identifying attack vectors and potential gaps to be leveraged.

• Follow the documentation flow and identify entry points into the CDE
• Where does the actual sale/transaction take place?
• Understand the flow of CHD from the customer, where it gets transmitted to and stored, and where you as a tester can access it.
• Validate the connectivity: just because it’s on a diagram, doesn’t mean that it’s an accurate portrayal of the network.

Internal in the environment from SIAM

CDE things to test without credentials:

• Scan the network:
  • Ping sweep can determine which hosts are live — but could also be blocked at the firewall
    • If the ping sweep is blocked, we can pull a list of IPs from DNS (provided they have PTR records)
    • We can attempt to identify dev, test and prod environments — possibly through naming convention of the hosts or application? (PCI DSS 6.4.1)
  • Nmap scans against “live” or “existing” hosts — routing access directly into the CDE from the SIAM (or host on the regular network) is a failure of segmentation. (PCI DSS 1.2)
    • The output of Nmap should help identify what each device is used for and give us a better understanding of how these devices fit into the cardholder data flow (if a device in the CDE has two primary functions, that require different security levels — web server && database || DNS — they should be separated (PCI DSS 2.2.1))
    • If we can’t get into the CDE directly, can we get to the CDE *through* the shared services network?
  • Eyewitness scan
    • Feed output from nmap into Eyewitness, looking for both http and https
      • You can do this by running `nmap -sS <target subnets> -Pn -p1-65535 -oA <filename>`
      • You can feed the eyewitness data with `./EyeWitness -x <nmap file>.xml  –all-protocols –prepend-https -d <directoryname>`
    • Look for any administrative interfaces, attempt to log in with default credentials (PCI DSS 2.1)
  • Nessus scans for vulnerabilities to help round out our understanding of what’s on the network
    • If any SNMP community strings show up in the results as ‘public’ that’s a finding (PCI DSS 2.1)
    • Make sure only necessary services are enabled within the CDE (PCI DSS 2.2.2)
    • Look for any weak SSL findings (PCI DSS 2.3)
    • Utilize Responder’s multi-relay tool for any devices identified to have SMB signing turned off.
  • If they exist, attempt SMB null session access to file shares. Look for any sensitive data or things to leverage. This is often a “last ditch” effort because it takes so long to sort through all of the files, but can generally lead to some pretty useful information and insight into the company.
  • Use responder to leverage LLMNR communication to gain access or credentials on a remote machine
  • Look for dev or test accounts within the CDE application (PCI DSS 6.3.1)
  • If at any point you can access the CDE from this environment, this fails segmentation (PCI DSS 11.3.4)

CDE things to test with credentials:

• Nessus scans for vulnerabilities to help round out our understanding of what’s on the network
  • If at any point you receive credentials, make sure you do a vulnerability scan against the system *with* those credentials.
  • If at any point you elevate your credentials on a machine, scan again.
  • If any SNMP community strings show up in the results as ‘public’ that’s a finding (PCI DSS 2.1)
  • Make sure only necessary services are enabled within the CDE (PCI DSS 2.2.2)
• Access file shares
  • CrackMapExec
    • Attempt to dump sam and lsa for more credentials
    • Inject Meterpreter shell or Powershell Empire stager wherever possible
  • Look for sensitive information (PCI DSS 3.2)
  • Look for any passwords or keys stored in the shares (scripts, configuration files, etc) (PCI DSS 3.5.3, 3.5.4)
• Look for dev or test accounts within the CDE application (PCI DSS 6.3.1)
• LDAP queries for AD group access — these should be limited to individuals whose job requires access (PCI DSS 7.1)
  • Gather AD password policy
    • Lockout after 6 attempts (PCI DSS 8.1.6)
    • Lockout for at least 30 minutes (PCI DSS 8.1.7)
    • Minimum length of 7, both numeric and alphabetic (PCI DSS 8.2.3)
    • Must change at least once every 90 days (PCI DSS 8.2.4)
    • Must not match the last 4 passwords (PCI DSS 8.2.5)
    • First time use MUST be changed (PCI DSS 8.2.6)
  • Look for shared accounts (PCI DSS 8.1.1)
  • Look for any users that may be stale/access needs to be removed, including vendor accounts (PCI DSS 8.1.3, 8.1.4, 8.1.5)
• Attempt to join your own machine to the domain to gain trust.

With elevated credentials:

• Nessus scan
  • Check if the system is not up to date on patching (PCI DSS 5.1)
• Start your pivot into CDE or Domain Admin!

Internal from corporate, trusted, or domain joined device

It’s important to see the environment from several different perspectives. If any of the following are disabled, try to leverage for more access:

• Check if the device has a firewall (or equivalent) enabled and working (PCI DSS 1.4)
• Check for Anti-Virus, up to date, running (PCI DSS 5.1)
  • And check if we can disable it (PCI DSS 5.3)
• Check for application whitelisting (PCI DSS 7.2)
  • Just having it isn’t enough though, if too many applications or publishers are being trusted, or it is implemented more as a blacklisting tool, it is easily exploitable.
• Check for session timeout <= 15 minutes (PCI DSS 8.1.8)

 

External or from an Internet perspective

The following can be tested from the Internet:

• Look for any private IP addresses disclosed in the applications or certificates (PCI DSS 1.3.7). This can be found very easily using Burp.
• Shared hosting providers must be separated (PCI DSS 2.6)
• Look for authentication data after authorization (PCI DSS 3.2)
• Look for weak SSL (PCI DSS 4.1)
• Look for dev or test accounts within the application (PCI DSS 6.3.1)

 

Inside CDE devices/network

Once on the CDE network, either a server or workstation, any endpoint will do, you will want to test a few more controls that may not be obvious from the outside.

• Test if you can get to the Internet (PCI DSS 1.3)
  • You can stand up a server in the cloud that is listening on all ports (I use socat to set up a listening service and then iptables to redirect all other ports to this listening service) to test which ports will make it outside of the firewall.
  • I often also try to bounce off of my own proxy in case I’m being blocked somewhere.
  • Tunnelling over SSL is often easier to get out to the Internet.
• Test if you can get into the CDE database (PCI DSS 3.1, 8.7) — Refer back to network diagrams on how these are connected, if needed.
• Check for full disk encryption (PCI DSS 3.4.1)
• Check for Multi-Factor authentication for access (PCI DSS 8.3)
• Test the point of sale (where the customer gets the card) — Refer back to flow documentation

Inside the test environment

• No production data should be in use (PCI DSS 6.4.4)
• Leverage anything you can find here to pivot into production or any other parts of the network

Inside CDE application

Applications may be websites or applications installed onto a device, either way, all of the following should be tested within the application. Generally using Burp or some other similar tool is often all that’s needed to test inside the application. Keep in mind of anything that can be identified by looking through the code statically, as well as anything that can be found upon the device it was installed to on disk or in memory.

• Look for private IP addresses disclosed (PCI DSS 1.3.7)
• Check for SQL injection (PCI DSS 6.5.1)
• Check for buffer overflows (PCI DSS 6.5.2)
• Check for insecure cryptographic storage (PCI DSS 6.5.3)
• Check for insecure communication (PCI DSS 6.5.4)
• Check for improper error handling (PCI DSS 6.5.5)
• Check for XSS (PCI DSS 6.5.7)
• Check for Cross-site request forgery (PCI DSS 6.5.9)
• Check for improper access control (PCI DSS 6.5.8)
• Look for dev or test accounts (PCI DSS 6.3.1)
• Check for broken authentication and session management (PCI DSS 6.5.10)
• Check for shared accounts (PCI DSS 8.1.1)
• Check for access into the database containing cardholder data (PCI DSS 8.7)

Physical

One of the more fun parts of an assessment is the physical assessment. Provided it’s in scope, identify and look for the following:

• Wireless (PCI DSS 9.1.3)
  • Wireless networks with access into the CDE should be protected and not open (PCI DSS 2.1.1)
  • Look for weak SSL (PCI DSS 4.1)
  • Set up rogue access point and see if it’s detected (PCI DSS 11.1.2)
• Look for badge access and other physical mechanisms (PCI DSS 8.6)
• Test if physical access is being monitored through unauthorized access, cameras, etc (PCI DSS 9.1)
• Look for active network jacks in sensitive areas (PCI DSS 9.1.2)
• Check if it’s easy to distinguish employees vs visitors (PCI DSS 9.2)
• Check if they escort you in areas where cardholder data is processed or maintained (PCI DSS 9.4.1)
• Check if they track you in a visitor log (PCI DSS 9.4.4)
• Look for thumb drives and keyfobs lying around (PCI DSS 9.5)

Network devices

If assessing the network infrastructure, there are a few pretty easy checks you can do to figure out the state of the environment:

• Queried from outside of the device:
  • Networking equipment must not have ‘public’ community strings (PCI DSS 2.1)
  • Check for multi-factor authentication for management (PCI DSS 8.3)
• Looking at the configuration:
  • Firewalls should have a default “deny-all” setting (PCI DSS 7.2.3)
    • This is also assuming that the allow rules before it aren’t wide open as well.
  • Check for session timeout, must be 15 minutes or less (PCI DSS 8.1.8)

Blue team testing

Test to see if their team noticed you accessing any of this data — it should be logged and monitored for any individual with root or administrative privileges (PCI DSS 10.1)

Access into the CDE should be tracked/logged internally — make sure their logs match your testing!!

Test if they have any mechanism to track changes or respond to our testing (PCI DSS 11.5)

Conclusion

If at any point you discover cardholder data encrypted or otherwise (PCI DSS 3.2), full track (PCI DSS 3.2.1), PIN (PCI DSS 3.2.3), or unmasked PAN (PCI DSS 3.3 and 3.4) document it!

If this were an actual audit, we’d request documentation for a large number of their internal processes. But it’s not! Yay! It’s just an audit-like test 🙂

Hopefully, this post is useful to the community. I’m willing to update it if anything needs to be clarified as well as break down any of the technical tests if that’d be beneficial. Please let me know through the comments or email me your thoughts. I’d love to discuss any of these.