Retail IR: POS Malware, RAM Scrapers, and Card Data Exfiltration

Cybersecurity

POS RAM scrapers are quieter than ransomware but far more lucrative for attackers. This playbook covers detection, PCI DSS forensic requirements, and card data IOCs for retail IR teams.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 6, 2024 · 10 min read

RAM scraping malware targeting point-of-sale systems has been a persistent threat since the Heartland Payment Systems breach in 2008. Unlike ransomware, POS malware operates silently for months, harvesting card data from the memory of payment terminals before it can be encrypted and sent to the payment processor. The 2013 Target breach, the 2014 Home Depot incident, and numerous smaller retail chains have all fallen to variants of this attack class.

How RAM Scraping Works

Between the card swipe (or dip) and the encryption handoff to the payment processor, card data exists briefly in plaintext in the POS terminal's memory. The payment application reads the magnetic stripe data, processes it, and passes it to the encryption library. During that window, memory-resident malware scans running processes for Track 1 and Track 2 data patterns and captures them. Modern EMV chip transactions are significantly more resistant, but many retailers still accept swipe for fallback, and malware can target the fallback path specifically.

• Track 2 data contains the PAN (primary account number), expiry, and service code. This is the minimum required to create a cloned card.
• Track 1 data additionally contains the cardholder name, which enables card-not-present fraud.
• RAM scrapers typically use regex patterns to identify card data: Luhn-valid 15 or 16 digit sequences in a specific format.
• Exfiltration often occurs over DNS tunneling, HTTP to a compromised aggregator server, or via FTP to an external server on port 443 to blend with HTTPS traffic.

Initial Detection: What Triggers the IR?

POS malware incidents are rarely self-detected. The most common detection path is notification from a card brand (Visa, Mastercard) that your location has been identified as a Common Point of Purchase (CPP) in fraud analysis. By the time that notification arrives, the malware has typically been running for 60 to 90 days. Treat every CPP notification as a confirmed breach requiring a forensic investigation.

1. Preserve all POS terminal memory and disk images immediately upon receiving a CPP notification. Do not reboot or update any POS system before forensic capture.
2. Identify the infection window using transaction logs. The card brands will provide a testing window; correlate it against your system logs to establish when the compromise began.
3. Isolate affected POS systems from the network. Do not power them off; keep them isolated and running for memory capture.
4. Notify your acquiring bank and payment processor immediately. They have mandatory reporting obligations to the card brands and will initiate a PCI forensic investigation.
5. Engage a PCI Forensic Investigator (PFI). Under PCI DSS, if a merchant is compromised, a PFI must conduct the forensic investigation and report to the card brands.

PCI DSS Forensic Requirements

The PFI engagement is not optional for Level 1 and Level 2 merchants following a confirmed breach. The PFI must submit a preliminary report to the card brands within five business days of engagement, and a final report within ten business days. The PFI will focus on: confirming the presence of malware, identifying the infection vector, establishing the timeline, determining the scope of card data at risk, and assessing whether PCI DSS controls were in place.

Card Data Exfiltration IOCs

• Outbound DNS queries to domains registered within the last 30 days from POS network segments.
• HTTPS traffic to IP addresses not on the payment processor whitelist from POS terminals.
• Processes running from temp directories or with randomized names on Windows-based POS systems.
• Scheduled tasks or registry run keys added after the system baseline date.
• Firewall logs showing POS terminals initiating outbound connections to public IPs (POS terminals should only communicate inbound from the payment processor or outbound to known processor endpoints).
• FTP or raw TCP sessions on port 443 that do not complete a TLS handshake (common exfiltration trick to bypass simple port-based firewall rules).

POS terminals should never initiate outbound connections to the internet. If your firewall policy allows this, you have a control gap that POS malware will exploit.

Post-Incident PCI Remediation

• Implement point-to-point encryption (P2PE) using a PCI-validated P2PE solution. This removes card data from the POS application entirely and makes RAM scraping ineffective.
• Segment the POS network completely from the corporate network. POS terminals should have no path to the internet except through approved payment processor endpoints.
• Deploy application whitelisting on all POS systems. Only approved payment application executables should be permitted to run.
• Enable file integrity monitoring on POS system directories. Any new executable should generate an immediate alert.
• Conduct quarterly vulnerability scans and annual penetration tests on the cardholder data environment as required by PCI DSS.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.