It has been in the news all over the place lately. "Credit cards from major US retailer stolen", "Cyber criminals use RAM scraping malware to lift credit card transactions", etc. Every week there are stories emerging about another breach of credit card information. I have even heard some of the recent breaches referred to as "economic terrorism" (my own opinion is that comment might be on the extreme side, but it is definitely deserving of our interest).
This blog post is going to walk through some of the details that I've noticed with some of the RAM scraping malware that I have encountered, including one instance of a piece of malware that VirusTotal currently lists as non-malicious (NOTE: The last analysis was performed on 09 November 2011 and the first analysis was performed on 20 April 2011. Until I chose to reanalyze the malware while writing this post, the 0/43 rate was what the VirusTotal result returned. The new result had 30 out of 50 AV vendors detecting the file as possibly malicious, but that is still only 60%)
|Original RAM scraper detection rate was 0/43|
|A much better 30/50 detection rate on rescan. But that is still only 60% of AV programs|
So what makes a RAM scraper? Well, in most cases the RAM scrapers monitor processes running in memory for items that look like the credit card transaction data. Credit cards actually do follow length requirements and beginning numbering schemes, and most follow the "Luhn algorithm" (The wikipedia write-ups on the bank card numbers and the Luhn algorithm is an excellent explanation, so I will not explain it again).
UPDATE: Track1 data contains more information than the Track1 data, and is usually able to be determined by the presence of names as well as the "^" character, where Track2 data usually contains the "=" character. The Track1 data breakdown table is also taken from tech-faq.
|Breakdown of Track1 data|
What we will cover in more detail is Track2 data, which is part of the data which resides on the magnetic stripe on the back of a credit card. Track2 data is the data that a majority of the RAM scrapers, that I have encountered, are monitoring memory for. The table below, copied from tech-faq, lists a brief breakdown of the data that is present in Track2 data.
|Breakdown of Track2 data|
In most cases Track2 data is present, unencrypted in memory, for a very brief period of time, as it is against PCI requirements to store Track2 data. That is where the RAM scraping malware comes into play. It usually monitors processes that are running on the system, and when it sees data that matches the pattern that fits the Track2 data requirements, it grabs that data and either saves it to a file on the device or exfiltrates the data from the compromised system. In this example I loaded the malware into PeStudio (a great, and FREE tool put together by Marc Ochsenmeier that can be downloaded here). The main thing to highlight is this, and many other RAM scrapers, rely on regular expressions that fit either Track1 or Track2 data.
|Track data regular expressions in this piece of RAM scraping malware. 18B46 will grab Track1 data (note the ^ character) and 18F92 will grab Track2 data (note the = character)|
|Possible malware indicators detected automatically by PeStudio|
If only there was a way that AV (or other) solutions could monitor memory and/or processes for other executables that search for Track data... Of course the cyber criminals would then likely change their methodologies in order to circumvent that as well, but this is likely the next stage a very long battle between those trying to steal information and those trying to protect it.