Understanding malware targeting Point Of Sale Systems

Author: No Comments Share:

Back in 2009 several companies (including Visa and Verizon) published threat reports describing a new kind of malware – RAM scrapers (Verizon report, Visa report). These are malicious programs that search memory of point-of-sale (POS) systems for bank card information. After that a number of blog entries appeared, but neither of them (to our best knowledge) reveal the inner workings of RAM scrapers. Recently this issue has come back into the limelight with the recent Target breach. The exact details of the Target malware are still unknown but it is important to understand how RAM scrapers work and why they’re a big risk to the retail industry.

In this blog, we analyze several families of POS malware and investigate techniques and approaches deployed to scrape bank card information in the infected system’s volatile memory.



Modern point-of-sale devices are quite complex. Apart from simply selling stuff (and doing refunds) they may include inventory management, warehousing, financials and so forth. Such devices actively deploy networking, cloud computing, some are even organized as Software-as-a-Service (SaaS). This brings a number of information security risks to the POS infrastructure.

One the major problem is bank card information leak. Standards require it to be encrypted when stored on a hard drive or transmitted through the network. But it might be completely unprotected in the volatile memory of the process working with it. Furthermore it might remain in a RAM for some time after card data processing is finished. This gives cybercriminals an opportunity to steal these data by searching through the RAM of a POS machine.

There are many types of bank cards: credit cards, debit cards, gift cards etc. Modern cards have magnetic stripes or chips that store the card data, which includes security code and bank account number. Data formats used in the bank cards are defined by ISO/IEC 7813 and 7816 standard. Our observations show that attackers build their search algorithms in accordance with these documents.

The remainder of the blog describes the analysis of several families of the RAM scrapers, their main components and how they actually work.

General Overview and Dataset

POS malware is organized as trojans, except the malicious activities they perform are narrowed down to bank data search in the processes RAM. Apart from the common malware activities (such as covert launch, anti-forensics, contacting malicious servers or C&C) scrapers workflow includes two essential steps:

  1. Process enumeration and memory dumping – enumerating the processes of interest and reading their memory into a buffer or dumping into a file.
  2. Bank card data search – iterating through the buffered/dumped memory for the card information.

Each family of POS malware uses its own implementation of these steps. At some points RAM scrapers seem to be surprisingly diverse, which makes them an interesting research object.  The list below shows the samples (and their MD5 hash sums) that were analyzed in this research. Since there’s no standard for malware names we specified several.

  1. c43f1be5e71c3cde5f04d4954ab29788 – TrojanSpy:Win32/Alinaos.E (Microsoft), Win32/Spy.POSCardStealer.D (ESET)
  2. 6f0de63e7831c715e1bff9556777ea55 – Backdoor:Wom32/Hesetox.A (Miscrosoft), Infostealer.Vskim (Symantec), Win32/Spy.POSCardStealer.K (ESET)
  3. 2d48e927cdf97413523e315ed00c90ab – PWS:Win32/Dexter (Miscrosoft) Win32/Poxters.A (ESET)
  4. b4f28e51ec62712951ee6292936768c8 – Memory dumper from the Visa report
  5. 100b5329e32dc033eb5e0523dedf4009 – Infostealer.Bancos (Symantec) a variant of Win32/Spy.POSCardStealer.A (ESET)
  6. 7f9cdc380eeed16eaab3e48d59f271aa – TrojanSpy:Win32/Pocardler.A (Microsoft) Infostealer.Reedum (Symantec) Win32/Spy.POSCardStealer.N (ESET)

Process Enumeration and Dumping

This part of scrapers’ workflow is generally the same in all the samples analyzed. To enumerate processes either CreateToolhelp32Snapshot / Process32First / Process32Next bundle is used or EnumProcesses API call. The interesting observation is that each specimen targets a somewhat different set of processes then the other ones. Generally a scraper has either a hardcoded list of processes to scan or a blacklist of processes (so it scans everything but the blacklisted names). Here are the processes checked by scrapers analyzed (‘.exe’ extension omitted):

  • Processes to dump from: sslwg, visad, micros.ssf.service, capms, pms, ccs, microsmux, visatcp;
  • Blacklisted processes: explorer, chrome, firefox, iexplore, svchost, smss, crss, wininit, steam, devenv, thunderbird, skype, pidgin, System, winlogon, services, lsass, spoolsv, wcntfy, alg, mscorsvw, ctfmon.

For each selected process every scraper in our collection does the same thing – it calls VirtualQuery and then ReadProcessMemory to dump the process memory into the buffer or file.

Trustwave reported an outstanding example of a RAM scraper in the SpiderLab’s paper called “POS Memory Parsing Malware Briefings. Attacks on Kernel Memory”. This one seems to be far more complex than the specimen analyzed in this paper since it features rootkit functionality. It installs the driver (called ramsys32.sys), that is capable of scraping every memory page currently mapped in the system. Although to our best knowledge there are no other alerts corresponding to the kernel-level RAM scrapers, the potential of the threat is frightening.

Processes blacklist  as the if…else… sequence

Processes blacklist as if... else... sequence

Processes blacklist as the global array

Processes blacklist as global array

Bank Card Data Search

The most challenging part of a RAM scraper is the search algorithm. It must be able to detect bank card information in a huge chunk of data (and do it as reliably as possible). A number of approaches can be used for this purpose, but the most popular one is based on regular expressions.  The simplest search algorithm was implemented in Dexter. It looks for ‘=’ character and then checks 16 bytes before and 20 bytes after it. If all the bytes are ASCII or Unicode digits then check 16 byte sequence (allegedly a card number) with the Luhn algorithm, which is widely used to check the correctness of bank card numbers. Here is the implementation of the Luhn algorithm in the Dexter sample.

Dexter Luhn Algorithm

And here are some examples of regular expressions used in RAM scrapers (such as Alinaos and vSkim):

  1. ((%?[Bb`]?)[0-9]{13,19}\^[A-Za-z\s]{0,26}/[A-Za-z\s]{0,26}\^(1[2 -9])(0[1-9]|1[0-2])[0-9\s]{3,50}\?)
  2. ([0-9]{13,19}=(1[2-9])(0[1-9]|1[0-2])[0-9]{3,50}\?)
  3. (((%?[Bb`]?)[0-9]{13,19}\^[A-Za-z\s]{0,26}/[A-Za-z\s]{0,26}\^(1[2-9])(0[1-9]|1[0-2])[0-9\s]{3,50}\?)[;\s]{1,3}([0-9]{13,19}=(1[2- 9])(0[1-9]|1[0-2])[0-9]{3,50}\?))
  4. \;?[3-9]{1}[0-9]{12,19}[D=\u0061][0-9]{10,30}\??

These expressions are used to scrape bank card tracks – information written in the magnetic stripe. The format follows the ISO/IEC 7813:2006 specification. Let’s look at one regular expression in more detail. Let’s take the biggest one (which is #3 in the list above) since it covers both tracks of the magnetic stripe.

  • %? – starting symbol of Track 1.
  • [Bb`]? – code of the format (upper or lower case ‘B’).
  • [0-9]{13,19} – credit card number. The size can vary but must not be longer than 19 characters.
  • \^ – field separator.
  • [A-Za-z\s]{0,26}/[A-Za-z\s]{0,26} – cardholder name (two fields 26 characters each).
  • \^ – Field separator.
  • (1[2-9])(0[1-9]|1[0-2]) – expiration date in YYMM format – two digits for the year and two for the month. This particular RegExp can only detect cards with expiration dates from 2012 to 2019.
  • [0-9\s]{3,50} – covers all the remaining data which may include Card Verification Code/ Value (CVC or CVV).
  • %? – Terminating symbol.
  • [;\s]{1,3} – covers longitudinal redundancy and starting symbol of the 2nd track (‘;’).
  • [0-9]{13,19} – credit card number.
  • = – Separator.
  • (1[2- 9])(0[1-9]|1[0-2]) – expiration date.
  • [0-9]{3,50}\? – remaining data including terminating character.

Networking and C&C

The earlier versions of RAM scrapers required a person to retrieve a text file containing the stolen data from the infected machine (as it is implemented in Reedum) – it was mostly an insider tool and did not have any networking capabilities. However newer samples tend to use the Web for the data delivery. The complexity of networking component varies from simple submitting of data to the server to full functional C&C components. A scraper called Alina v.3.3 for example uses HTTP to submit card data to the backend, check for updates and if applicable downloads a newer version. Dexter and vSkim networking components are organized in a similar fashion. A good example of the complex C&C implementation is early 2013 Citadel modification – a Zeus-based banking trojan with bot-net functionality. This version in addition to traditional banking trojan features has a POS RAM scraper component which makes it a serious player in the modern threat landscape.

Discussion and Conclusion

Appearance of the POS RAM scrapers is a good illustration of how cybercrime business evolves. Attackers try to increase their profits by extending the list of potential targets. Hardening home computers is not enough anymore – your bank card data might leak trough the POS machine in the nearest grocery store. For the IT security community it’s a new challenge that requires cooperation between security teams in different sectors of the business and, most importantly, developing new ways to secure customers data.

Of course it’s obvious that traditional endpoint defenses aren’t able to cope up with such malware. At Bromium Labs we’ve been actively working with the Retail industry leaders to mitigate these types of emerging threats.

Previous Article

Client SDN: Securely Delivering the Client-Cloud Transformation (1 of 2)

Next Article

FireEye and Mandiant: A Marriage Forged in Compromise

You may also like

Leave a Reply

Your email address will not be published. Required fields are marked *