A special kind of malware has been hitting the headlines recently – that which attacks the RAM of Point of Sale (PoS) systems.
Although it’s been getting quite a bit of publicity recently, we actually first identified it as a threat back in December 2009 and wrote about it in an article on Naked Security entitled Will RAM scraping loosen the sky and make it fall?.
Answering that question today, it just might!
Actually, the situation isn’t that bad – yet – but this malware family has definitely become more complex and far-reaching. In this article, we take a step back from the technical details and look at the evolution of PoS RAM scrapers.
What do PoS RAM scrapers do?
In a nutshell, PoS RAM scrapers steal payment data – such as credit card track one and track two data – from the RAM of PoS systems.
The payment card industry has a set of data security standards known as PCI-DSS. These standards require end-to-end encryption of sensitive payment data when it is transmitted, received or stored.
This payment data is decrypted in the PoS’s RAM for processing, and the RAM is where the scraper strikes. Using regular expression searches, they harvest the clear-text payment data and send that information to rogue callhome servers.
Why do we care about PoS RAM scrapers? How does it hurt me?
I believe this malware family has a higher probability of burning a hole in your pocket compared to other prevalent malware families.
In today’s plastic money economy people are carrying cash a lot less than before. Aside from a handful of stores, the majority of retailers accept debit or credit cards. Payment cards are convenient, quick, supposedly-secure, and you don’t have change jingling around in your pockets.
PoS RAM scrapers target the systems which process debit and credit card transactions and steal the sensitive payment information. Your home computer might be super secure, but there is no guarantee the PoS system at your neighborhood grocery store has the same level of security. You might end up losing your credit card data buying a candy bar!
How have PoS RAM scrapers evolved?
Sophos detects PoS RAM scraper malware under the family name Trackr (e.g. Troj/Trackr-Gen, Troj/Trackr-A) Other AV vendors detect this malware family with a variety of names, the most common name being Alina.
Some of the earliest variants of Trackr had simple functionality that worked like this:
- Install as a service
- Use a legitimate-looking name
- Scan RAM for credit card track one and track two data
- Dump the results into a text file. This text file was then probably accessed remotely or manually.
Over the years Trackr has become more industrialized, with some cosmetic changes and added bot and network functionality.
Our friends at Trustwave SpiderLabs have written two excellent articles, Alina: Casting a Shadow on PoS and Alina: Following The Shadow, about the inner workings of the Trackr family.
Till now we have observed the following types of Trackr:
- Basic version (not packed, scrapes RAM for credit card information)
- Complex version (added socially-engineered filenames, bot and network functionality)
- Installed DLL version (the DLL is registered as a service and performs the RAM scraping)
- Versions one and two packed with a commercially-available packer
- Versions one and two packed with a custom packer
Most recently, SophosLabs discovered the highly-prevalent Citadel crimeware targeting PoS systems.
The Citadel malware uses screen captures and keylogging instead of the RAM-scraping technique used by Trackr. Citadel’s focus on PoS systems demonstrates that this avenue is fast becoming a point of serious concern.
Who do PoS RAM scrapers target?
One of the earliest serious PoS RAM scraper attacks that we observed was back in November 2011 when we found that a university and several hotels had their PoS systems compromised. Later we saw varied targets including an auto dealership in Australia infected with Trackr.
To better understand the threat we gathered statistics about the various industries targeted by Trackr during the past 6 months (as observed using Sophos Live Protection):
It doesn’t come as a surprise that the biggest targeted industries are:
- Retail
- Service
- Healthcare
- Food services
- Education
- Hotel and tourism
In these industries there’s a high volume of credit and debit card transactions taking place, meaning they have goldmines of payment data that can be harvested.
Compromising a single PoS system (e.g. in a fast food outlet) may yield thousands of credit cards per week, cheaply – much easier to gather 10,000 credit card details from one PoS system then attempt to infect 10,000 PCs, hoping to grab the data from there.
If not protected properly, PoS systems become easy targets – a single point of failure that can affect thousands of people.
In addition to the breakdown of industries targeted, we also looked at the countries where we saw Trackr infections over the same time period:
Again, no surprises that the developed countries top this chart with the US, where credit cards are abundant, taking the #1 spot.
In fact, the Trackr infection numbers match up closely with the credit card country usage statistics published by Visa.
So how does Trackr get on a PoS system?
We have used the term PoS quite generally throughout this article. PoS is the place where a retail transaction is completed. So a PoS could be some custom hardware/software solution, a regular PC running PoS software, a credit card transaction server, or something similar.
Big box retailers and chain stores have security-hardened PoS systems, and we have not seen any major evidence of these large organizations getting compromised with Trackr.
The victims tend to be mostly small to medium sized organizations who will typically have less investment in defensive counter-measures.
Based on our analysis there were two main methods of infection:
Insider job
Someone with active knowledge of the payment processing setup installs a RAM scraper to gather data. The early Trackr samples dropped their harvested data in a plain text file which we suspect was manually retrieved or remotely accessed.
The malware had no network functionality and we found no evidence of a top-level dropper/installer.
Phishing/Social Engineering
These are the common infection vectors with the more complex versions of Trackr. The socially engineered filenames we have observed include Taskmgr.exe
, windowsfirewall.exe
, sms.exe
, java.exe
, win-firewall.exe
, and adobeflash.exe
. This suggests that the files were delivered as part of a phishing campaign, or social engineering tricks were used to infect the system.
Importantly however, Trackr is not seen regularly in the mass-spammed malware campaigns that we observe daily. Rather it is highly targeted towards a group of relevant businesses.
To conclude, it is not always a safe solution to pay for everything with cards.
Everyone should follow computer security best practices and consumers should proactively sign-up for credit monitoring services so they don’t becomes victims of credit or identity theft.
Businesses big and small need to make investments to protect their critical PoS infrastructure. Just like they wouldn’t keep their cash registers unlocked for someone to grab money out of them, PoS systems need proper protection.
Image of point of sale machine courtesy of Shutterstock.
'Till now' – I see what you done there….. 😉 lol
I don't think any system will ever be 100% secure. Even paying in 'cash' has it's problems from counterfeiting!
As I was once told in a programming class, "If a human devises it, another human can break it"
And what about the use of new “Chip” cards?
Are they affected in the same way?
It would seem logical to assume “chip & PIN” cards are also affected; the data on the chip is meant to replace the track data – though the track data is still there for “legacy” compatibility with older PoS terminals.
Look up the University of Cambridge’s research on “chip & PIN” fraud; they did a very good job of highlighting that standard’s many weaknesses: poor crypto & a lot of assumptions about physical access being difficult for an attacker.
With Citadel being used to do user-land screen-scraping & key-logging, this type of attack becomes very difficult to identify.
I was going over the VISA Data Security Alerts and their latest bulletin is titled:
Preventing Memory-Parsing Malware Attacks on Grocery Merchants
– 11 April 2013 (http://usa.visa.com/download/merchants/alert-prevent-grocer-malware-attacks-04112013.pdf). Looks like my assertion of buying candy and losing your credit card is spot on!
This is what happens when you build a PoS system based on Microsoft Operating systems. They should be using a dedicated OS for embedded systems then this would be FAR less likely to happen.
One thing I don’t understand; whats the point of “end to end encryption” if the POS is decrypting the card after its encrypted at the wedge/pad? I thought the benefit to “end to end encryption” was from the wedge all the way to the processor it was ciphertext and you manipulated it via tokens? Why was it in clear text in the RAM of the POS computer? I’m just an interested third party with minimal understanding – what am I missing?
PCI-DSS, at least as far as I know, mandates that you shouldn’t *store* card data unencrypted.
So the crooks reacted by going after memory. If the data were encrypted inside the terminal and stayed that way until it was inside the merchant’s payment processor then this sort of register-based RAM attack would fail. The crooks would have to compromise the terminal or the processing system at the core of the network. Both of those have been done before, so removing register memory scraping from the equation wouldn’t solve the problem…but it woudln’t hurt either!
PCI-DSS actually doesn’t require end to end encryption. It only requires encryption over public networks or long term storage. You can store card data momentarily while the transaction is in progress and be PCI-DSS compliant. Most card data is sent from the card terminal to the POS in clear text (over a private network or usb/serial,) and is therefore vulnerable to packet sniffing, then stored in RAM unencrypted, vulnerable to RAM Scraping. The network aspect of it can be encrypted, but once it hits the TCPIP stack is is then unencrypted in memory. It is then transmitted over an encrypted connection to the clearing house. Also, RAM scraping is especially effective, because the programmer may grab the card data, then encrypt it internally anywhere they use it, but it could be left vulnerable in memory from a stream or operating system object used to grab it from the network connection. The programmer may have no way to prevent this.
End to End Encryption is not as widely adopted as you may think. It is expensive and difficult to implement, and the certification process is long. It really is the only way to prevent RAM Scraping. It would encrypt the card data on the card terminal, and it would stay encrypted all the way until it hits the processor.
Can Paypal get around this?
Paypal is a convenient way to reduce the number of merchants who have access to your card data. So as long as Paypal emphasizes security as top priority – which as far as I can tell as a long-time user, they do – then you have less to worry about than if you were to enter your card data on every website you purchase from.
Nothing is for sure, but I trust Paypal with my data more than I do some small service website who hasn’t proven their reputation.
I even use Paypal’s debit card because I get an email instantly after a purchase is made. So when I go to a store and buy stuff, my phone beeps within seconds. So if that card gets compromised then I’ll know right away. If I don’t keep funds in the Paypal account, then it just draws from my checking account on file.