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.

Cloud

5/25/2016
12:00 PM
Melia Kelley
Melia Kelley
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

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
Comments
Newest First  |  Oldest First  |  Threaded View
MeliaK840
50%
50%
MeliaK840,
User Rank: Author
5/26/2016 | 8:26:51 AM
Re: greetings!!
Thank you!  Glad it was informative for you.
honey143
50%
50%
honey143,
User Rank: Apprentice
5/26/2016 | 2:29:30 AM
greetings!!
Nice post very informative..
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-29379
PUBLISHED: 2021-04-12
** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered on D-Link DIR-802 A1 devices through 1.00b05. Universal Plug and Play (UPnP) is enabled by default on port 1900. An attacker can perform command injection by injecting a payload into the Search Target (ST) field of the SSDP M-SEARCH discover pa...
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.