Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    December 2014
    S M T W T F S
    « Nov    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • Email Subscription

  • About Us

    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:

    IIII-IIAA-AAAA-AAAC

    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:

    ^%([A-Z])([0-9]{1,19})\^([^\^]{2,26})\^([0-9]{4}|\^)([0-9]{3}|\^)([^\?]+)\?$

    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.

    Update as of 12:35 AM PDT, June 4, 2014

    Ground Labs, the publisher of Card Recon, has released a blog post discussing the modified versions of their software used by cybercriminals. They reiterated that legitimate copies of Card Recon should only be downloaded from their website or their partners.





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon






     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice