Scrape FAST, Find’em Cards EASY!

While researching POS RAM scraper malware, I came across an interesting sample: a RAR archive that contained a development version of a POS RAM Scraper malware and a cracked copy of Ground Labs’ Card Recon software. Card Recon is a commercial Data Leakage Prevention (DLP) product used by merchants for PCI compliance. (The contents of this archive are detected as TSPY_POCARDL.AI and SPYW_CCVIEW.)

It looks like the criminal gangs are using the RAM scrapers to dump memory, and (ironically) using DLP to find the cards. The cracked Card Recon software I found in the RAR archive dates back to 2011:

Link date: 9:14 AM 3/11/2011
Publisher: Ground Labs
Description: PCI DSS CHD Scanner
Product: Card Recon
Prod version: Release 1.14.7
File version: Release 1.14.7
MachineType: 32-bit

Hunting for other samples using this cracked version of Card Recon returned more archive files; two interesting ones in the lot were a RAM scraper bundle and a keylogger bundle. Bad guys using a commercial DLP solution wasn’t that surprising, but it got me thinking: why validate? Aren’t the regexes used to collect the data enough?

The short answer is the criminals need to check and validate the data they have stolen, which they then sell in the underground carder marketplace. Selling bad data will damage their reputation and might even have nastier repercussions than merely losing credibility.

We first need to understand payment card numbers (i.e., debit and credit card numbers) in some detail. The format of these numbers is specified in ISO/IEC 7812. The 16-digit numbers used have the following format:


The first six digits of the card is known as the Issuer Identification Number (IIN), and the very first digit of the IIN is the Major Industry Identifier (MII). The major card networks – Visa, MasterCard, Discover, and American Express (AMEX) – all have unique IIN ranges that identifies which institution issued the card. The individual account number is of variable length (up to 12 digits) and final digit, C, is a check digit calculated using the Luhn algorithm.

The Luhn algorithm is a simple checksum formula (defined in the ISO specification), which is designed to catch any errors in the previous 15 digits. All 16 digits are stored in the magnetic strip of the card in distinct magnetic tracks (Track 1 and Track 2), together with other information needed to process transactions. All this is defined in ISO/IEC 7813.

The precise definition of how the Track 1 and 2 data is stored on cards allows POS RAM scraper malware to use regular expression (regex) patterns to search for these in RAM. Here’s an example regex for finding Track 1 data:


Depending on the complexity of the necessary regex, it might also incorrectly capture garbage data from RAM in addition to the target data. A well-defined regex will return clean results, but may be computationally expensive compared to a looser regex. When the goal is to capture data from the RAM quickly, efficiency is more important than quality, especially when the validation can be done offline on the exfiltrated data.

Remarkably, though, there are some purist malware authors who believe in writing good code. One such POS RAM scraper example was written in Visual Basic and actually implemented the Luhn algorithm:

Figure 1. Implementation of Luhn algorithm
(Click image to enlarge)

The malware will use the regex to capture data from the RAM and then use the function Luhn to validate the data. This function takes a string as input and returns a Boolean value: true or false. Invalid data is discarded, and the malware exfiltrates only valid results.

While this code is functional, it’s not particularly suitable for high-volume data collection: it’s just too computationally intensive. Using an offline DLP solution like the cracked Card Recon is ideal. If you recall the massive Target data breach from last year, pragmatically validating 70 million payment cards is best done outside any compromised network.

Going back to the POS RAM scraper with cracked Card Recon software, I discovered that the DLP tool identifies (using IIN) the following cards: AMEX, Discover, Diners Club, JCB, Visa, MasterCard and Test/Others. The “Test/Others” checks the numeric string is Luhn-valid, but doesn’t map it to any specific card brand.

I used an online fake credit card number generator to generate different brands of Luhn-valid credit card numbers and then used the Card Recon DLP tool to scan my drive for valid credit card numbers. (It should be noted that the DLP tool only validates the payment card number and not the entire Track 1 and 2 data.)

Figure 2. Cracked Card Recon tool

The tool incorrectly identified some Python libraries as containing Luhn valid test credit card numbers, which supports the point I made previously about regexes misfiring and collecting garbage data. To a carder the full package: account number, expiry dates, CVC1/CVV1 codes found in Track 1 & 2 are extremely important. Combined, these fetch a higher price in the underground carder marketplace compared to the card number alone. They use regexes to collect both Track 1 and 2 data, and validating the captured card numbers theoretically implies that the rest of the data is valid as well.

Figure 3. Files detected by Card Recon
(Click image to enlarge)

One may then ask: is all this information valued equally in the underground marketplace? Surprisingly, the answer is no, and it all has to do with supply and demand.

Our recent revisit of the Russian underground showed how the price of credit cards in the underground marketplace has declined over the years. However, the variation in prices of different brands of credit cards still exists. Checking various carder sites I found some representative prices for “validated” US -based credit cards:

Table 1. Card prices (per card, in US dollars)

Two things to take away from this. First, buying credit card data in bulk reduces the unit price, in some cases by up to 66%. Secondly, the unit price of Discover and AMEX cards is higher than the unit price of Visa and MasterCard cards.

This is because AMEX and Discover card data are harder to come by compared to the commonly found Visa and MasterCard card data; rarer data costs more. Unfortunately, I failed to find good reasons as to why AMEX and Discover card data is seen as more lucrative than Visa and MasterCard card data. Is it because compromised AMEX and Discover cards are less likely to be detected? Do they carry larger credit limits? They are accepted with a higher level of confidence? We can’t say for sure.

From this investigation we conclude:

  • POS RAM scraper malware regexes used to collect Track 1 and 2 data are observed to be computationally lightweight. This may be to cope with the high volume of data being processed, and to remain stealthy. Exceptions to this obviously exist, but the mainstream RAM scraper families generally don’t implement Luhn validation in code.
  • Card data validation is usually done offline on the exfiltrated data using readily available hacked/cracked DLP tools e.g. Card Recon or using homebrew tools. In addition to validation, the carders also separate out the different card brands.
  • Different card brands have different unit prices in the underground carder marketplace based on availability and demand.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Scrape FAST, Find’em Cards EASY!

Read more: Scrape FAST, Find’em Cards EASY!

Incoming search terms

Story added 28. May 2014, content source with full text you can find at link above.