Point of Sale Malware RAM Scrappers
Investigations into recent cyber attacks which focused on retail POS systems and credit card information have revealed that malicious actors are using publically available tools to locate business around the world that utilize remote desktop applications. Remote desktop solutions like Apple’s Remote Desktop, LogMeIn, Microsoft’s Remote Desktop and Splashtop offer the efficiency and convenience of connecting from one computer to another remotely.
Once a remote application is located, these bad actors can attempt to brute force the login feature of the remote desktop solution. After they gain access to what is often the administrator or privileged access accounts, the suspects can then deploy the Malware also known as a “RAM scraper” or “memory parser” which exploits this. When someone swipes their credit card, the POS terminal processes the credit card data in RAM unencrypted. If RAM scraper malware resides on the terminal, it simultaneously scans the payment application’s portion of RAM looking for card-matching patterns.
What are POS RAM Scrapers?
Point of Sale RAM scrapers basically steal payment data from the POS system. They specifically target track one and track two data (2014). Magnetic stripes on payment cards—sometimes called “magstripes” for short—are divided into three tracks of data which are encoded directly to the magstripe. Only Track 1 and Track 2 are actively used in payment card processing. Track 3 is rarely used and may not always be present on a card.
Both Track 1 and Track 2 contain enough basic information for processing payment card swipes. Most card readers will be able to read both Track 1 and Track 2 data, in case one of the tracks has become unreadable.
Track 1 (IATA)
Track 1 (“International Air Transport Association”) stores more information than Track 2, and contains the cardholder’s name as well as account number and other discretionary data. This track is sometimes used by the airlines when securing reservations with a credit card.
Track 2 (ABA)
Track 2 (“American Banking Association,”) is currently most commonly used, though credit card companies have been pushing for everyone to move to Track 1. This is the track that is read by ATMs and credit card checkers. The ABA designed the specifications of this track and all world banks must abide by it. It contains the cardholder’s account, encrypted PIN, plus other discretionary data.
For payment cards, Track 1 Data will be formatted like this:
Track 1 Data Structure
Field Name Length Comments
Start Sentinel (SS) 1 character Indicates the beginning of Track 1; set to”%”
Format Code (FC) 1 character Indicates the card type; “B” indicates a credit/debit card
Primary Account Number (PAN) up to 19 digits Always numerical; usually set to the credit/debit card number
Field Separator (FS) 1 character Delimits Track 1 fields; set to “^”
Name 2-26 characters Account holder’s name
Field Separator (FS) 1 character Delimits Track 1 fields; set to “^” Expiration Date (ED) 4 digits Always in the format MMYY
Service Code (SC) 3 digits Indicates what types of charges can be accepted
Discretionary Data (DD) Variable* Determined by card issuer—may include Card Code and/or PINs
End Sentinel (ES) 1 character Indicates the end of Track 1; set to “?”
Longitude Redundancy Check (LRC) 1 character Used to verify that Track 1 was read accurately
* Track 1 Data cannot exceed 79 characters, including all Sentinels, Field Separators, and the LRC. The length of Discretionary Data is restricted as a result and tends to hold fairly short values.
The format for Track 2 Data was developed by the American Banking Association (ABA) and tends to be much shorter and holds less information:
Track 2 Data Structure
Field Name Length Comments
Start Sentinel (SS) 1 character Indicates the beginning of Track 2; set to “;”
Primary Account Number (PAN) up to 19 digits Always numerical; usually set to the credit/debit card number
Field Separator (FS) 1 character Delimits Track 2 fields; set to “=” Expiration Date (ED) 4 digits Always in the format MMYY
Service Code (SC) 3 digits Indicates what types of charges can be accepted
Discretionary Data (DD) Variable* Determined by card issuer—may include Card Code and/or PINs
End Sentinel (ES) 1 character Indicates the end of Track 2; set to “?”
Longitude Redundancy Check (LRC) 1 character Used to verify that Track 2 was read accurately
* Track 2 Data cannot exceed 40 characters, including all Sentinels, the Field Separator, and the LRC. The length of Discretionary Data is restricted as a result and tends to hold fairly short values.
The payment card industry established a set of data security standards, which is known as PCI-DSS. These standards require end-to-end encryption of sensitive payment data like credit card details when being transmitted or stored. The problem lies in the POS RAM, this is where the payment data is decrypted for processing and where the scraper strikes.
Who is most vulnerable to POS RAM Scrapers?
According to Sophos, they gathered statistics over the last 6 months of the various industries targeted by Trackr a type of POS RAM Scraper (2014). It is no surprise that the biggest targeted industries are as follow:
• Retail
• Service
• Healthcare
• Food services
• Education
• Hotel and tourism
These industries reflect some of the highest volumes of credit and debit card transactions around the world. If their POS systems are not properly protected, they can become easy targets. A single fast food restaurant alone may yield thousands of credit cards per week. It is much easier to obtain 10,000 credit card from a single POS system then attempt to infect 10,000 home PC’s in hopes of obtaining credit card details from there.
Impact
The impact of a compromised PoS system can affect both the businesses and consumer by exposing customer data such as names, mailing addresses, credit/debit card numbers, phone numbers, and e-mail addresses to criminal elements. These breaches can impact a business’ brand and reputation, while consumers’ information can be used to make fraudulent purchases or risk compromise of bank accounts. It is critical to safeguarding your corporate networks and web servers to prevent any unnecessary exposure to compromise or to mitigate any damage that could be occurring now.
Trackr
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:
1. Install as a service
2. Use a legitimate-looking name
3. Scan RAM for credit card track one and track two data
4. 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.
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, Sophos Labs 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.
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.
Impor, antly 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.
Target, Neiman Marcus, Michael’s, and possibly P.F. Chang’s all have one thing in common: They are recent victims of a type of malware called a RAM scraper that infects point of sale (POS) terminals. These data breaches occurred despite some, if not all, of these merchants complying with industry security standards.
In Target’s case, government analysts estimate the total financial impact could reach as high as $12.2 billion. And the fallout continues. Target’s CEO Gregg Steinhafel set a new precedent, marking the first time that the head of a major corporation resigned due to a data breach. Merchants clearly must go beyond merely complying with industry security standards to reduce their risk, especially in relation to POS terminal malware.
Backoff Malware
According to US-CERT, “Backoff” is a family of PoS malware and has been discovered recently. The malware family has been witnessed on at least three separate forensic investigations. Researchers have identified three primary variants to the “Backoff” malware including 1.4, 1.55 (“backoff”, “goo”, “MAY”, “net”), and 1.56 (“LAST”).
These variations have been seen as far back as October 2013 and continue to operate as of July 2014. In total, the malware typically consists of the following four capabilities. An exception is the earliest witnessed variant (1.4) which does not include keylogging functionality. Additionally, 1.55 ‘net’ removed the explorer.exe injection component:
• Scraping memory for track data
• Logging keystrokes
• Command & Control (C2) communication
• Injecting malicious stub into explorer.exe
The malicious stub that is injected into explorer.exe is responsible for persistence in the event the malicious executable crashes or is forcefully stopped. The malware is responsible for scraping memory from running processes on the victim machine and searching for track data. Keylogging functionality is also present in most recent variants of “Backoff”.
Additionally, the malware has a C2 component that is responsible for uploading discovered data, updating the malware, downloading/executing further malware, and uninstalling the malware. See Figure 1 for a depiction of the process for the malware’s execution.
Variants
Based on compiled timestamps and versioning information witnessed in the C2 HTTP POST requests, “Backoff” variants were analyzed over a seven month period. The five variants witnessed in the “Backoff” malware family have notable modifications, to include:
1.55“backoff”
• Added Local.dat temporary storage for discovered track data
• Added keylogging functionality
• Added “gr” POST parameter to include variant name
• Added ability to exfiltrate keylog data
• Supports multiple exfiltration domains
• Changed install path
• Changed User-Agent
1.55“goo”
• Attempts to remove prior version of malware
• Uses 8.8.8.8 as resolver
1.55“MAY”
• No significant updates other than changes to the URI and version name
1.55“net”
• Removed the explorer.exe injection component
1.56“LAST”
• Re-added the explorer.exe injection component
• Support for multiple domain/URI/port configurations
• Modified code responsible for creating exfiltration thread(s)
• Added persistence techniques
Command & Control Communication
All C2 communication for “Backoff” takes place via HTTP POST requests. Note that all data in Figure 2 was generated in a closed sandboxed environment; no legitimate Track data is being shown.
FIGURE 2
As shown in the example, a number of POST parameters are included when this malware makes a request to the C&C server.
• op : Static value of ‘1’
• id : randomly generated 7 character string
• ui : Victim username/hostname
• wv : Version of Microsoft Windows
• gr (Not seen in version 1.4) : Malware-specific identifier
• bv : Malware version
• data (optional) : Base64-encoded/RC4-encrypted data
The ‘id’ parameter is stored in the following location, to ensure it is consistent across requests:
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\identifier
If this key doesn’t exist, the string will be generated and stored. Data is encrypted using RC4 prior to being encoded with Base64. The password for RC4 is generated from the ‘id’ parameter, a static string of ‘jhgtsd7fjmytkr’, and the ‘ui’ parameter.
These values are concatenated together and then hashed using the MD5 algorithm to form the RC4 password. In the above example, the RC4 password would be ‘56E15A1B3CB7116CAB0268AC8A2CD943 (The MD5 hash of ‘vxeyHkSjhgtsd7fjmytkrJosh @ PC123456).
Mitigation and Prevention Strategies
At the time this advisory is released, the variants of the “Backoff’ malware family are largely undetected by anti-virus (AV) vendors. However, shortly following the publication of this technical analysis, AV companies will quickly begin detecting the existing variants. It’s important to maintain up-‐to-‐date AV signatures and engines as new threats such as this are continually being added to your AV solution.
The forensic investigations of compromises of retail IT/payment networks indicate that the network compromises allowed the introduction of memory scraping malware to the payment terminals. Information security professional’s recommend a defense in depth approach to mitigating risk to retail payment systems. While some of the risk mitigation recommendations are general in nature, the following strategies provide an approach to minimize the possibility of an attack and mitigate the risk of data compromise.
Remote Desktop Access
• Configure the account lockout settings to lock a user account after a period of time or a specified number of failed login attempts. This prevents unlimited unauthorized attempts to login whether from an unauthorized user or via automated attack types like brute force
• Limit the number of users and workstation who can log in using Remote Desktop.
• Use firewalls (both software and hardware where available) to restrict access to remote desktop listening ports (default is TCP 3389).
• Change the default Remote Desktop listening port.
• Define complex password parameters. Configuring an expiration time and password length and complexity can decrease the amount of time in which a successful attack can occur.
• Require two-factor authentication (2FA) for remote desktop access.
• Install a Remote Desktop Gateway to restrict access.
• Add an extra layer of authentication and encryption by tunneling your Remote Desktop through IPSec, SSH or SSL.
• Require 2FA when accessing payment processing networks. Even if a virtual private network is used, it is important that 2FA is implemented to help mitigate keylogger or credential dumping attacks.
• Limit administrative privileges for users and applications.
• Periodically review systems (local and domain controllers) for unknown and dormant users.
Network Security
• Review firewall configurations and ensure that only allowed ports, services and Internet protocol (IP) addresses are communicating with your network. This is especially critical for outbound (e.g., egress) firewall rules in which compromised entities allow ports to communicate to any IP address on the Internet. Hackers leverage this configuration to exfiltrate data to their IP addresses.
• Segregate payment processing networks from other networks.
• Apply access control lists (ACLs) on the router configuration to limit unauthorized traffic to payment processing networks.
• Create strict ACLs segmenting public-facing systems and back-end database systems that house payment card data.
• Implement data leakage prevention/detection tools to detect and help prevent data exfiltration.
• Implement tools to detect anomalous network traffic and anomalous behavior by legitimate users (compromised credentials).
Cash Register and PoS Security
• Implement hardware-based point-to-point encryption. It is recommended that EMV-enabled PIN entry devices or other credit-only accepting devices have Secure Reading and Exchange of Data (SRED) capabilities. SRED-approved devices can be found at the Payment Card Industry Security Standards website.
• Install Payment Application Data Security Standard-compliant payment applications.
• Deploy the latest version of an operating system and ensure it is up to date with security patches, anti-virus software, file integrity monitoring and a host-based intrusion-detection system.
• Assign a strong password to security solutions to prevent application modification. Use two-factor authentication (2FA) where feasible.
• Perform a binary or checksum comparison to ensure unauthorized files are not installed.
• Ensure any automatic updates from third parties are validated. This means performing a checksum comparison on the updates prior to deploying them on PoS systems. It is recommended that merchants work with their PoS vendors to obtain signatures and hash values to perform this checksum validation.
• Disable unnecessary ports and services, null sessions, default users and guests.
• Enable logging of events and make sure there is a process to monitor logs on a daily basis.
• Implement least privileges and ACLs on users and applications on the system.
References
Dark Reading.(2014). Ram Scraper. Retrieved
from http://www.darkreading.com/attacks-breaches/ram-scraper-malware-why-pci- dss-cant-fix-retail/
US Cert.(2014). Backoff Point of Sale Malware.
Retrieved from https://www.us-cert.gov/ncas/alerts/TA14-212A
Post your comment on this topic.