RAM-scraping or memory-scraping malware has advanced significantly since it first became widely known via the 2010
Verizon Data Breach Investigations Report. Following the 2013 attack on Target in which attackers used a RAM scraper to capture credit card numbers, there has been renewed interest in the topic. While the technical aspect of malware using RAM-scraping has changed little since 2010, the overall sophistication of the attacks has increased tremendously.
Recent developments in both sophistication and automation indicate the constant evolution of malware that will most certainly continue to advance in the future.
In this tip, I will discuss what the recent changes in RAM-scraping malware mean and whether there are any new defenses that enterprises should include in their security strategies to thwart potential attacks.
What has changed since 2010
First, a little background on RAM-scraping malware: While the Payment Card Industry Data Security Standard (PCI DSS) requires end-to-end encryption of all payment data -- including credit card numbers, cardholder names and expiration dates -- there is a period of time during the authorization process when the data is stored unencrypted in RAM on point-of-sale (POS) terminals. RAM-scraping malware was designed to infiltrate these POS terminals and scan the system's RAM, searching for the unencrypted data. Once found, RAM-scraping malware harvests the data and transmits it to attackers.
As it inevitably goes, new malware attacks and variations of malware are constantly emerging to bypass common enterprise security protections, such as firewalls and antimalware -- this is as true now as it was in 2010. And in terms of RAM-scraping malware, access to the POS terminal and network is still required, so those standard protections will still need to be bypassed in an attack.
While these facts remain the same, to me, the major thing that sticks out is how sophisticated and automated the overall attacks have become. The increased usage of encrypted connections has forced attackers to target any place where credit card numbers are transported unencrypted, and these days that's often only at the POS where the initial card data capture occurs.
More on RAM-scraping malware and the Target breach
Major retail breaches highlight point-of-sale security weaknesses
Massive Target data breach: Retailer says 40 million cards compromised
Does retail security take a back seat during the 'holiday IT lockdown'?
Target breach update: Information on up to 70 million customers stolen
Kaptoxa, a new strain of the BlackPOS malware, was reportedly used in the recent Target data breach. This malware monitors for any swipe of a credit card and records it to a file. Note that nothing about this is different from any other RAM-scraping malware. This attack in particular merely used more developed steps to better hide the communications and more sophisticated malware to make detection far more difficult. According to security journalist Brian Krebs, the attackers used a third-party vendor's account to get a foothold in the Target network and exploited the segmentation used by Target to separate the internal network from the PCI network. Using BlackPOS malware, the attacker was able to automate the copying of captured data via a Windows file share on a compromised internal Target server to extract the data. Using this Windows file share helped the attacker hide in plain sight. The compromised server was infected with some unknown malware and used to store the data until it was sent via FTP to servers outside of the Target network, as was mentioned by Dell SecureWorks' investigation. Using FTP also likely helped the malware hide from detection.
Protecting the enterprise from RAM-scraping malware
Many of the strategies to protect an enterprise from RAM-scraping malware are the same in 2014 as they were in 2010. Tools and techniques including patching, antimalware, firewalls, not running as administrator and network monitoring are still all vital -- and all required by the PCI DSS. In January 2014, the U.S. Computer Emergency Readiness Team even released Technical Alert TA14-002A, which reiterated that these protections are critical.
Other basic steps -- such as limiting usage to only the POS software on the cash register, whitelisting or restricting access of the account used for the POS system -- can also boost security. A host-based intrusion-detection system (HIDS) that monitors suspicious access to RAM or system devices can send an alert notifying administrators to further investigate a system or block the access outright if needed. The HIDS or an embedded firewall can also provide an additional layer of protection by allowing only authorized connections. End-to-end encryption from a device connected to the POS to the payment processor can also be used to limit the transport of unencrypted credit card numbers and protect the credit card encryption from malware on the POS system; a chip and PIN will help limit the scope.
In addition to monitoring for suspicious connections, it is critical to also monitor for non-SSL encrypted traffic to detect malicious communication. Point-of-sale malware is often installed remotely, and attackers often use a remote connection to exfiltrate data as well, creating opportunities for detection. However, note that malware authors are moving toward using standard HTTPS for communications, so they won't stick out as much when analyzed. However, botnet communications might not look like normal, browser-based HTTPS communications and could generate an alert from a network anomaly-based detection system to investigate. Detecting a system with more outbound communications or any Internet-bound connection in a properly firewalled network could also generate an alert. Aggressive firewall configurations can also be set to allow the POS system to talk only to the cash registers and vice versa. A dedicated connection with the payment processor could be used in addition to strong firewall rules.
While some enterprises may claim they need to collect credit card numbers to track consumer shopping habits, it is important to note that this can still be done by using a token in the place of the credit card number. Though this could still pose an issue for enterprises storing credit card numbers for uniqueness, companies could mass-convert existing credit card numbers to new tokens using the same algorithm or processing as their payment processor. Despite the fact that mass-converting 40 million credit cards to tokens would be very resource-intensive, know that it would certainly be less costly than a data breach of millions of credit card numbers.
Recent developments in both the sophistication and automation of RAM-scraping malware are indicative of the constant evolution of malware. It is critical that enterprises continually improve their defenses by implementing some of the aforementioned best practices. These will not only thwart potential attacks, but also ensure sensitive corporate and consumer data is protected as effectively as possible.
About the author:
Nick Lewis, CISSP, is the information security officer at Saint Louis University. Nick received his Master of Science degree in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and at Boston Children's Hospital, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.