Detecting Payment Card Data Breaches Today to Avoid Becoming Tomorrow’s Headline

A few months ago we discussed the various ways that consumer PII is compromised. The recent attacks against Target and Neiman Marcus illustrate the constant threat that payment card accepting retailers of all sizes face. Yesterday Reuters reported that similar breaches over the holidays affected “at least three other well-known U.S. retailers”. Given the current onslaught, it’s a good time for retailers to examine their detection capabilities before a payment card data attack, while creating new goals for shortening remediation windows during and after an attack.

 

The Managers’ Bottom Line

Payment card track data (the data stored on track 1 and track 2 of a card’s magnetic strip, also known as “dumps” in criminal parlance) continues to experience increased demand in the criminal Underground (primarily demonstrated in criminal web forums). For well over a decade, criminals have been leveraging globalization and the Internet to create a pipeline that transforms stolen payment card track data into physical spurious credit cards that are used for fraudulent in store purchases. Consumers’ payment card track data with or without PIN is one of the most sought after criminal commodities in the online marketplace. Short of identity theft and tax refund fraud, physical credit card fraud is the quickest way to become a criminal millionaire. Additionally, the United States remains one of the few first world countries still prolifically using magnetic stripe payment cards which means American companies are the extremely lucrative low hanging fruit. Last, the attacks on point of sale (POS) terminals and payment card networks are the most efficient way for criminals to steal track data and (often) associated PINs in bulk.

The past ten years is littered with stories of POS compromises affecting government agencies and businesses in almost every vertical including hotels, restaurants, retailers, etc. Many of the most egregious data breaches are never publicly disclosed, the only externality is an unexpected new payment card in the mail. The threat is real and it will continue unabated until the technological barriers to entry are raised significantly.

To substantially mitigate the risk of future POS compromise, businesses should look at hardware encryption devices at the point of sale. The payment card data attacks on Target and other retailers are possible because the POS payment solution includes third party software installed on a computer/terminal. The problem is that the payment card data is susceptible to interception in memory before the encryption process and transmission across the network.

If POS hardware encryption remains an unjustifiable business expense, companies should re-examine security policies to ensure that payment card data is included in the critical data category. This is data that must receive a logical and operational moat to ensure absolute detection of unauthorized access and irregular movement. There are too many ways to initially compromise the network; rather it is the internal critical data that must be identified, segmented, and monitored.

The Network Security Monitors’ Operational Insight

As a network defender imagine for a second that you are tasked with a penetration test of an enterprise business with the specific mandate to obtain as much payment card track data as possible while avoiding detection. How would you do it?

If the last decade of POS attacks is any indication, while clever, you’re over complicating the process. Gaining access to the corporate network is trivial. Spin the wheel of unauthorized access channels: for bonus speed points, buy a compromised host in the network from a bot herder, craft a reasonable Phish, or use a remote vulnerability in the content management system (CMS) of the marketing department’s most visited web destination for iframe redirection to your Metasploit server.

In any enterprise network, focusing exclusively on intrusion prevention is a lost cause. So assuming the attacker is already in the network their next step is locating the payment card data. While network enumeration and credential brute forcing /privilege escalation is often noisy, to make this simple let’s also assume that the attacker is pre-equipped with the payment processing network segment location and the requisite credentials to access it.

If the target is a large retail company the attacker(s) is going to assume that they are a Level 1 PCI compliant merchant. The attacker is going to fetch a pre-compiled suite of tools, probably in the form of a single compressed file. The download may occur over any one of a dozen different application protocols (FTP, HTTPS, RDP, VNC, DNS, etc.) but the attacker is going to use a protocol that has a higher chance of connection success without encountering egress proxy issues. Once the file transfer is complete, the tools will be unpacked and a regular expression (REGEX) search will be initiated to locate the Windows application process responsible for receiving and encrypting the customer’s swiped card payment data. The memory scraper will subsequently intercept payment card data and store it to log files. Since large files tend to attract attention often these log files will rotate after reaching a specific size threshold. Now the log files are ready for batch exfiltration, but first they need to be compressed and possibly encrypted to hopefully attract less attention.

A prepared attacker will include a script to automate this chain of events and scale the attack to all of the POS terminals in the network. If the script fails somewhere along the way, the attacker will make manual modifications, but little intervention is likely required as the attacker already knows the POS manufacturer and model.

POS Terminal Script

1. Fetch a compressed file from a remote server
2. Extract the file contents
3. Initiate the REGEX process finder, memory scraper, and log location
4. Rotate logs at fixed size intervals
5. Compress the log files (and possibly encrypt)
6. Connect to a remote server and transfer the compressed files at regular intervals

Over the past 24 months a number of memory scraper malware families have been gaining notoriety due to their noisy and aggressive installation numbers across the Internet. Dexter, Alina, Trackr, and POSCardStealer are common anti-virus labels for binaries that scan the victim host process list for data matching the payment card track data REGEX.

Dexter
File name: C:\Documents and Settings\Administrator\Application Data\tiemu\tiemu.exe
SHA1: 6aa8c630c0e2324e85067e7e48348d6919b7a6d5
MD5: 9eee5677a479ea82f07309a2f69128d8
Packer: Borland Delphi 3.0
Mutex: WindowsResilienceServiceMutex
Symantec AV Label: Infostealer.Dexter

Alina
File name: C:\Documents and Settings\Administrator\Application Data\defender.exe
SHA1: 6432e74dc88fd8e1768db908ac78ce82c3177bb7
MD5: 133b384f0a4d66809815bad06aa47ae4
Packer: Microsoft Visual Basic v5.0
Mutex: CTF.TimListCache.FMPDefaultS-1-5-21-1547161642-1715567821-
1275210071-1006MUTEX.DefaultS-1-5-21-154716
Trend Micro AV Label: BKDR_ALINA.NC

Trackr
File name: C:\Users\Administrator\AppData\Roaming\jucheck.exe
SHA1: 5563e4c2987eda056b3f74716c00d3014b9306bc
MD5: 1efeb85c8ec2c07dc0517ccca7e8d743
Packer: UPX
Sophos AV Label: Troj/Trackr-Gen

POSCardStealer
File name: C:\WINDOWS\system32\dwwin.exe
SHA1: 6c52df97370cfcde9fcace3f6e33cd95ec1e2c50
MD5: 87b811b0cd31c05c9506359eb4efdc94
Packer: MingWin32 GCC 3.x
Mutex: MSCTF.Shared.MUTEX.AJE
Eset AV Label: Win32/Spy.POSCardStealer.O trojan

While these families represent reasonable proof of concepts, they have been impotent in “the wild” as they are usually installed on Windows hosts that are not running POS software. The memory scrapers likely used in the most recent targeted retail attacks are almost certainly custom built or heavily modified from existing code for the specific attack. They have probably never been seen publicly prior to the attacks, so known memory scrapers are marginally useful for future profiling.

The most useful indicator of compromise (IOC) chain to focus on for future detection is the importation of a tool set, a new process running on the POS terminal, and finally the exfiltration of compressed files with uniform size and frequency. Create an operational play (and a playbook if needed) specific to alerting on this chain of events or any specific event that can be effectively tuned to dispel the typical noise. There are plenty of tool sets to accomplish the play and I like Netflow for a holistic picture of the network. In the Netflow space there are many resources, but I like Lancope’s StealthWatch Management Console. They provide a number of pre-installed, well thought out alerts, and it’s simple to create new alerts.

If I’m looking for payment card data exfiltration I could create an alert around repeating byte count patterns above a reasonable threshold and potentially add additional criteria for periodicity.

 

 

StealthWatch also includes a rule for “Suspect Data Loss” which alerts on large disparities between the quantity of inbound and outbound packets. Obviously a lot of legitimate traffic falls into this category, not just attacker exfiltration, but as part of the Cisco Cyber Threat Defense Solution, historical flow data on the network is analyzed to create a behavior baseline that in turn alerts on flow sessions that qualify as suspect outliers.

Last, application and process change detection should be in effect on all payment card processing systems. Any change on the end point or multiple end points should be cause for immediate analysis. Also, while most protocols tend to use compression for efficiency and speed gains, the compression tools themselves should be limited to an approved list.

The attacks on payment card data will continue to focus on POS systems, but well thought out detection plays, and/or the implementation of hardware encryption can dramatically help prevent future negative headlines.

Thanks to Martin Lee and Craig Williams for their assistance with this post.