Written by Nick Hoffman, Jeremy Humble and Jonathan Womack
Abstract
POS and Credit Card scraping families pop up from time to time, but only a few are observed each year. This one in specific is a newly discovered family (despite having a 2017 compile time) and has not been documented before.
In order to defend against this tool, customers need endpoint visibility and the ability to scrutinize processes and services en masse. The tool has no networking capabilities endpoint is really the only method to finding this in a victim environment.
New point-of-sale malware samples occasionally appear from time to time. Following up on an interesting tip, we retrieved and analyzed a sample of previously unseen POS malware, introduced here as RtPOS. This POS malware is named as such after the debug path left in the sample:
(fb749c32b58fd1238f21d48ba1deb60e6fb4546f3a74e211f80a3ed005f9e046).
C:\Users\nblat\Documents\Visual Studio 2015\Projects\rt19\Release\rt19.pdb
Even at the most basic glance at the metadata, we can begin to see some interesting artifacts. Right from the start, the malware with the file name alohae.exe purports to be “Windows Logon Service.” This is a common trick used by malware authors as a basic form of obfuscation. Even more implicative is the presence of a Russian (RU) language code. The full file metadata is presented below:
The program accepts only two arguments “/install” and “/remove” which are responsible for installing and removing the service on the victim’s machine. These functions are clearly visible in IDA, without any special attempt made at obfuscation.
When providing the install argument, the WinLogon service is set up and the following is sent to the logging function:
And the service description is updated:
Analysis of the service configuration, when changed into a more readable form, resembles the following pseudocode:
Following installation, RtPOS then iterates the available/running processes on the compromised machine. This is carried out in two steps; first RtPOS uses CreateToolhelp32Snapshot to obtain a process list, and finally uses Process32FirstW to begin iteration of the process list.
VirtualQuery (VirtualQueryEx) is used to obtain the boundaries of the process:
Finally, RtPOS uses the ReadProcessMemory function to gain access to the compromised system’s memory space. Access to the memory space of a compromised POS terminal or other system handling payment processing is a classic feature of RAM-scraping POS malware, where payment card data is stored and processed before any encryption solutions can be applied to it. Access to the memory space permits RtPOS the ability pass this buffered information containing scrapes payment card data over to a custom track search algorithm:
When Track1 and Track2 data is found, the captures information is passed to a Luhn algorithm for validation. The RtPOS implementation of the Luhn algorithm is visible in IDA at 0x405a50.
After RtPOS verifies the Track1/Track2 data via the Luhn algorithm, the next process is crawled using “Process32NextW”:
When a successful payment card number is found in memory, the Luhn algorithm will successfully validate the number as seen in the screenshot below.
The Track1 and Track2 data that pass this verification are then saved to the DAT file sql8514.dat for later exfiltration. The RtPOS malware creates the DAT file in the \Windows\SysWOW64 folder. The following format string is used
%02d.%02d.%04d - %02d:%02d:%02d| %s: \t\t%s\n
as seen below:
In the screenshot below we see an example of a credit card number being written to the RtPOS log file. Each entry in the DAT log line contains the date and time, the process used to write the information to the DAT log file, and finally the captured information:
An example of the captured payment card data written to the DAT log file resembles the following:
RtPOS is unique in comparison to other fully featured POS malware like Project Hook and TreasureHunter, in that it has no native exfiltration capability. While other POS malware families are perfectly capable of sending captured Track1 and Track2 data to a C2 server, RtPOS merely saves the data locally. As this activity is similar to some POS utilities, this is likely intended to reduce the network activity footprint of RtPOS and ensure the malware remains undetected for longer, thus earning the controllers a healthier profit. The RtPOS malware is also simplistic in features, largely automated in operation, and lacks many of the features that more mature POS malware families do.
The lack of a network exfiltration feature, interaction and user commands, as well as a dropper component hints at more serious implications: in order for RtPOS to execute and in order to retrieve the captured payment card data, the attackers would have existing access to the victim’s machine(s). RtPOS may simply be an in-development POS malware family, though review and analysis suggests RtPOS is a post-compromise tool instead of a standalone malware, and may even be part of a larger, heretofore unidentified tool set.
We offer these recommendations for informational use only and do not make any warranties or other promises they will be effective against the threats described herein.
