Posted on Leave a comment

Target/Neiman Marcus POS hacks – point-of-sale malware attack vector not that complex after all

image thumb711

Sample disassembled code from POSRAM POS RAM scraper malware


In late 2013, two major retailers were hit with up to a half-dozen more major retailers exploited without even knowing it.  In Target’s case, where credit and bank card data was collected from November 27, 2013 through December 15, 2013, 40 million credit card numbers were obtained by the hackers, impacting more than 70 million customers.  Today details of the attack were released revealing that the technical expertise behind the attacks was really not that impressive.  To understand the attacks however, we have to understand how bank and credit cards work and how earlier variants of POS RAM scraper malware function.  Once we understand the problem, it’s easy to see the long-term solution to credit-card theft.

About bank and credit cards

Components of a credit cardBank and credit cards store account number and security codes in the magnetic stripe located on the back of the card.  A credit card’s magnetic stripe has three tracks.  Typically only the first two tracks (the A and B tracks) are used but track C (the third track) is often used to store miscellaneous information such as the cardholder’s PIN, country code, amount authorized, etc.  The A track contents differ between each card issuer but Track B’s contents are pretty standard amongst all banks.  Several bits of information are stored on Track B of the magstripe including the account number, card verification code/value (CVC or CVV), expiration date, and a LRC (longitudinal redundancy check) digit.  The account number, CVC code, and expiration dates are especially important as carders can sell accounts with all three critical pieces of information at a much higher price than the going rate for a credit card account number alone.

The storage schema of the account number and security codes on the card’s magnetic stripe are publicly available and well known to hackers.  Defined by ISO/IEC 7812, ISO/IEC 7813 and ISO/IEC 7816 standards, the first digit(s) contain a number identifying the system to use for the transaction (e.g. Visa, MasterCard).  The remaining digits vary slight between card issuers but typically contain the bank number, account umber, and a check digit which can be used to validate the account number embedded in the magnetic stripe.

Although standards require all bank card information be encrypted in storage (i.e. harddrive) and when passed across the wire, there is no requirement that the customer’s account information be protected while in memory (RAM) and that’s where RAM scraper malware comes into play.

How RAM scraper malware works

Visualization of the magnetic stripe on a bank credit cardSecurity geeks have known about POS RAM scrapers since 2009.  These POS (point-of-sale) malware variants have one thing in common – they search the POS terminal’s memory, where the account information is typically unencrypted, for bank card information.  Several RAM Scraper variants exist including Dexter, POS Card Stealer, Reedum (BlackPOS), Bancos, vSkim, Alina, and now – POSRAM (the variant used in the Target/Neiman Marcus attacks).

The process by which POS RAM malware grabs credit card information from memory begins with an enumeration of the processes on the Windows-based POS terminal (yes, like ATMs, POS terminals are typcially bare-bones Windows machines, many based on the older Windows XP version).  Using standard Windows API calls, the malware enumerates the processes and compares the processes discovered to either a whitelist of desirable processes or a blacklist of processes to avoid.  Processes commonly sought after include sslwg, visad, micros.ssf.service, capms, pms, ccs, microsmux, pos, posw32, visatcp, and others.

Once a desired process is discovered, the memory for the process is dumped, again using a standard Windows API function such as VirtualQuery or ReadProcessMemory.  The memory that is dumped is then scanned for bank credit card information.  The most common method to scan for bank account data is to use a regular expression such as the one below, to filter out the bank account number.


The account number that was discovered is then run through a Luhn algorithm to validate the bank card number.  A Luhn algorithm, also known as “modulus 10” or “mod 10” algorithm, is a checksum formula used to verify a bank or credit card number against a check digit (the last digit stored on the magnetic stripe of the card) to ensure the sequence of numbers is indeed a bank account number.

Once the account information is captured, it can be transmitted to the hacker in a variety of ways.  Both Dexter and vSkimmer send their captured data across the network wire.  Alina is a bit more complex.  Alina not only submits the card data back to the hackers but also checks for malware updates and downloads and installs new versions as required.  Scary stuff.

BlackPOS and POSRAM sold on black marketTechnical details of the Target/Neiman Marcus attacks

Security researchers determined that the Target and Neiman Marcus attacks were part of a bigger campaign known as “Kaptoxa”.  In addition to Target and Neiman Marcus, the KAPTOXA operation is believed to have targeted “many operators” of retail POS systems.  In fact, between three and six other major national retailers were hit in the attack without even knowing it.

The 2013 Target attack used a new RAM scraper malware dubbed Trojan.POSRAM.  POSRAM is a memory scraping malware tool designed specifically to grab card data from Windows-based POS terminals.  And it’s based on the code from an earlier, well known POS scraper, BlackPOS.

BlackPOS POS RAM scraper malware

BlackPOS was developed in March 2013 by a 17-year-old Russian programmer known as “ree4” (aka Sergey Taraspov or Nizhniy Novgorod).  Over 40 builds of BlackPOS, also known as Infostealer.Reedum.C, were known to have been sold to cybercriminals, primarily from Eastern Europe, who used the malware to attack POS terminals in Australia, Canada, and the United States.  Surprising to some, BlackPOS is written entirely in Microsoft’s very own VBScript.  It can’t get much simpler than that.

POSRAM technical details

Over 75% of the POSRAM code is based on, or more accurately, similar to, BlackPOS.  POSRAM, as a customized version of BlackPOS, is designed to prevent antivirus program detection.  POSRAM modifications to the BlackPOS codebase include changes to allow POSRAM to evade forensic detection, covertly subvert network controls, conceal data transfers, and conceal any executions it may have run.

The nuts and bolts behind the POSRAM malware

Using standard Windows API calls, POSRAAM operation is fairly simple.  EnumProccesses is first used to get a list of active PIDs (process IDs) on the system.  The list of PIDs is then cycled through (it skips its own PID of course) and GetModuleFileNameEx called to get the path to the executable for the process.  The file name is then stripped out of the path, the case lowered, and the result compared to the “pos.exe” string using strcmp (pos.exe is the POS executable that POSRAM is interested in intercepting).  The string used in the compare function (“pos.exe”) is obfuscated in the code so a simple text string search for “pos.exe” won’t produce a match to the casual observer.

Once pos.exe is found, it is opened with OpenProcess and VirtualQueryEx in order to iterate through the process’s memory blocks.  The Dexter POS RAM scraper works in the same manner with the exception of Dexter doing a bit better job than POSRAM – Dexter does not attempt to access any memory marked PAGE_NOACCESS or PAGE_GUARD, segments of memory that would crash POSRAM (or BlackPOS) if the POS application’s memory had properly protected itself from rogue intrusions.

Finally, ReadProcessMemory is then used to read the data into a buffer which is then checked to see if it contains credit card information.

BlackPOS, and presumably POSRAM (all details have not been released) search for “PosW32.exe” in addition to “pos.exe” (both are processes that process the data from the bank card’s magnetic strip).  This string search for “pos.exe” and/or “posw32.exe” brings up an interesting point.  The attack could have been circumvented had the retailers simply renamed the default POS software executable to something other than the out-of-the-box name.

In addition to POSRAM…

Target attackers used a variety of other methods in addition to POSRAM.  It is known that they penetrated the retailers’ networks, likely to install a NetBIOS pipe for data transmission to an internal server (which would have also been exploited).  In addition, researchers revealed that the attackers had put controls into place to ensure they maintained a network presence on the retailer’s network (e.g. a rootkit was installed).

Once the bank card data was captured, it was stored locally on the POS system.  Every seven hours, the malware checked the current time and if within a specified window (said to be 10:00 AM through 5:00 PM although that seems a bit odd given the normal retailer’s business hours – unless the hackers forgot to correct for time zone differences), the malware transmitted the data over a NetBIOS share to a compromised internal host.  The data on the compromised host was then transmitted to a hijacked U.S. server where the attackers, coming from servers in Russia, used FTP to retrieve the data.

In all, POSRAM code is not particularly complex but the overall attack vector, including penetration and pwn’ing of other Target servers, does lend credence to the hackers’ abilities.

Is there a solution to this mess?

The Target attack will likely lead to reforms in the way retailers handle and process point-of-sale transactions.  Interestingly, Target may have had the answer right under their noses.  Target recently introduced what is known as a “loyalty card”.  Marketed under the “REDcard” name, the card is Target specific and linked to the cardholder’s bank account.  To the cardholder, the REDcard works just like their bank or credit card.  To Target however, the card can only be used in their retail stores meaning a compromised REDcard does not necessarily open up the customer’s bank account to the hacker.

Inherently however, the bank/credit card process is flawed, with debit cards being particularly risky for customers.  Tell any non-techie that their debit cards have the PIN (and CCV and expiration date) encoded directly on the card and they will look at you like you’re an idiot.  Even non-techies see the stupidity of the process.  The European method of storing card data on chips (aka “smart cards”) rather than easy-to-clone magnetic stripes, is not much better.  With today’s Internet-connected smartphones and NFC capabilities (sorry iPhone owners), a more secure mobile payment system, using a chip and PIN for in-person transactions and a one-time-use system-generated credit card number for online transactions, is a no-brainer.