Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


12:00 PM
Melia Kelley
Melia Kelley
Connect Directly
E-Mail vvv

A Newer Variant Of RawPOS: An In-Depth Look

There's no silver bullet for RawPOS prevention, but you can impede RawPOS's ability to execute successfully by understanding how it works.

If you discovered malware that steals payment card information had been hiding— undetected—on a client’s machine for a year or more, would you be concerned? What if you knew that variants of this malware had been around nearly a decade, yet the standard AV engines still failed to recognize it? What would you do?

I’ve seen a lot of this type of malware lately—RawPOS. This malware not only had a unique ability to evolve and adapt to changing environments over time, but could also be used to pilfer just about any kind of data that can be searched for using a regular expression, including Social Security numbers, telephone numbers, email addresses, and more. I decided to do some reverse-engineering to see exactly how it works, and devise a strategy for combatting it. Here’s what I learned:

RawPOS is a Windows-based malware family that targets payment card data. It’s been around at least since 2008, hitting the retail and hospitality industries especially hard. Although well-known and relatively easy to understand, RawPOS has proven effective in perpetuating long-term, devastating card breaches. The malware will typically “hide” on a machine for a year or more before the data is withdrawn and sold, and some of the largest breaches go undetected for months or even years. That’s a very effective strategy and genuinely scary.

For the many organizations that still rely on signature-based defense and lack a built-in exfiltration detection mechanism for traffic flow analysis, all it takes for attackers to continue evading detection is a simple file name change and a tweak or two in the code.

How Does It Work?

RawPOS combines three pieces of code to evade detection by ordinary means. Infection is basically a three-part process involving 1) a persistence mechanism, 2) a memory scraper, and 3) an encryption routine. Basically, the malware “scrapes” RAM for a regular expression (regex) that will capture Track 1 and Track 2 payment card data, and then places the data into a dump file to await exfiltration. Early iterations simply combined the memory scraper with the persistence mechanism. Over time an encryption function was added to the dump file.

Persistence mechanism: This ensures the data-scraping malware stays active on the system, even after a reboot. Whenever RawPOS runs, it installs the next component as a Windows service that runs continuously in the background. The particular strain we will examine here—discovered on a client’s casino kiosk—is named MSFSVC.exe. (Other iterations include rdasrv.exe and sppt32.exe.)

Once a service is created on a system, it can be named and described however the author chooses. In our example, the service was given the name Microsoft File Manager Services. Here’s the description: “Creates, updates, manages, and removes files for applications such as S/MIME and SSL. If this service is stopped, certificates will not be created. If this service is disabled, any services that explicitly depend on it will fail to start.” While the service itself was not signed by Microsoft, this description reveals how attackers can avoid admin scrutiny and “hide in plain sight” on a given system. At present, only 25 out of 55 AV engines on VirusTotal recognize the hash for the persistence mechanism as a threat.

Memory scraper: Attackers use this to circumvent existing security controls protecting data at rest and in transit. After it became too difficult to “sniff” a network for PCI data or grab a stored data file without detection, attackers turned to finding the desired data in its ephemeral state in memory. Many locations taking credit card data will have Track 1 and/or Track 2 data unencrypted in memory—though very short lived—for processing at some point.

Memory scrapers such as avicap.exe continuously monitor memory and look for certain regular expressions that match cardholder data. When data is found, the program creates a folder called “Memdump” in the current working directory and begins to export the regex hits. Newer versions of the malware place the data into a .dmp file named after the memory process ID that data was found inside. That data will then be moved into an encrypted file and time-stamped, awaiting exfiltration using an encryption routine.

The names of various iterations of this type of memory scraper vary widely. As of this writing, none of the 55 AV engines on VirusTotal recognized avicap.exe as a threat.

Encryption routine: Once card data has been identified, scraped, and aggregated, the malware is ready to execute its next function. In our example, the service called up a program called msiert.exe, a name that closely resembles names for valid Windows processes such as msiexec.exe, a Windows Installer component. Another version we found was called sqlmgmt.exe, a name that cleverly (if falsely) suggested its removal might disrupt a client’s running instance of SQL.

A fascinating characteristic of this executable is that it utilizes Perl2Exe, a program that will allow the conversion of Perl scripts into Windows executables. That’s good news: Perl2Exe executables are very “loud” and easy to spot if run on a system—if investigators know what to look for. Additionally, there is a way to “break” the code and get the original Perl source code itself, right down to the comments (in Russian) and encryption password. The prolific comments suggest that the code base is constantly being repurposed to suit new environments and evade detection.

The code’s not exactly pretty, but it works. As of the writing of this report, only 15 out of 55 of the AV solutions in VirusTotal recognized the hash of the casino sample as malicious.

Prevention, Detection and Mitigation

There’s no silver bullet for RawPOS prevention, but you can impede RawPOS’s ability to execute successfully. Whitelisting approved programs is a possibility, although probably too aggressive for most organizations. Another, less drastic route would be blacklisting Perl2Exe and other administrative tools that attackers use for propagation, such as PsExec. Finally, visibility on endpoints to determine what’s running and identify anomalous processes is critical to prevent the spread of malicious actors as well as find and mitigate more quickly.

Related content:


As a member of UnitedLex's Cyber Risk Solutions practice, Melia works with clients on a wide range of incident response and risk assessment engagements. During her career, Melia has worked on a large number of high profile data breaches both domestically and internationally, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
5/26/2016 | 8:26:51 AM
Re: greetings!!
Thank you!  Glad it was informative for you.
User Rank: Apprentice
5/26/2016 | 2:29:30 AM
Nice post very informative..
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Hunny, I looked every where for the dorritos. 
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver Vault Plugin prior to v0.0.6, Azure Plugin prior to v0.0.10, and GCP Plugin prior to v0.2.0 allow an attacker who can create specially-crafted SecretProviderClass objects to write to arbitrary file paths on the host filesystem, including /var/lib/kubelet/pods.
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver versions v0.0.15 and v0.0.16 allow an attacker who can modify a SecretProviderClassPodStatus/Status resource the ability to write content to the host filesystem and sync file contents to Kubernetes Secrets. This includes paths under var/lib/kubelet/pods that conta...
PUBLISHED: 2021-01-21
Kubernetes CSI snapshot-controller prior to v2.1.3 and v3.0.2 could panic when processing a VolumeSnapshot custom resource when: - The VolumeSnapshot referenced a non-existing PersistentVolumeClaim and the VolumeSnapshot did not reference any VolumeSnapshotClass. - The snapshot-controller crashes, ...
PUBLISHED: 2021-01-21
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executi...
PUBLISHED: 2021-01-21
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typicall...