Much attention has been focused recently on ransomware and other threats that go after consumers and businesses directly for monetary payouts. Still, point-of-sale (POS) malware continues to be an important source of stolen credit card data and associated revenue for cyber criminals.
The ongoing rollout of chip-and-pin credit cards and tighter standards following the retail megabreaches of 2014 have put further pressure on the POS malware black market. But as we have seen with the AbaddonPOS malware described here, POS malware is not just alive and well—it’s being actively developed.
On May 5, a financially motivated actor whom Proofpoint has been tracking as TA530 (also featured in our previous blog post "Phish Scales" ) sent out a highly-personalized email campaign targeting primarily retail companies and attempting to install TinyLoader and AbaddonPOS point-of-sale malware. The retail vertical was likely chosen due to the higher likelihood of infecting a POS system. We first observed AbaddonPOS when it was delivered by Vawtrak  in October of 2015. We have also found that TinyLoader and AbaddonPOS have since been updated in several ways.
The messages we observed used subjects such as “Group Booking at [company name]” and the personalized attachment names such as:
- [company name].doc
- [company name]_booking.doc
- [company name]_reservation.doc
The example message shown in Figure 1 uses the recipient's name in the email body and the company’s name in the email body and the attachment name. The attachment, shown in Figure 2, uses an interesting lure. It depicts an image of a spinner one would expect to see when content is loading and asks the user to enable content.
Clicking the “Enable Content” button enables the malicious macro, which then begins the infection by downloading TinyLoader, which in turn downloads AbaddonPOS.
Most of the messages we saw were delivered to retail companies (Figure 3).
Figure 1: Example email delivering TinyLoader
Figure 2: Example document delivering TinyLoader
Figure 3: Top targeted verticals by message volume
The variant of TinyLoader used in this campaign is similar to the one we previously had analyzed in connection with AbaddonPOS. One significant change includes the addition of a basic 4-byte XOR layer of obfuscation over the shellcode that is received from the command-and-control (C&C) server (Figure 4).
Figure 4: TinyLoader decoding and executing shellcode received from C&C
The XOR key is dynamically generated by the C&C and is different in every session. Once the shellcode is decoded, execution is immediately passed to the decoded shellcode. Although the controllers of TinyLoader could theoretically perform any action through custom shellcode, we are still observing this family of malware being used as a downloader. Figure 5 shows a TinyLoader response containing encoded shellcode to build a fake HTTP request used to download a payload.
Figure 5: Encoded response received from TinyLoader C&C
Once the shellcode is decoded, the strings used to craft an HTTP request can be seen (Figure 6). After this code is loaded, the TinyLoader C&C operator(s) is free to provide a target IP and URI to instruct an infected bot to retrieve a payload.
Figure 6: Decoded TinyLoader shellcode used to build HTTP request
In this campaign, we observed the initial TinyLoader payload retrieve another TinyLoader payload that connected to a different C&C. This new TinyLoader infection then received another instruction to download a different payload (Figures 7 and 8), which was a new variant of AbaddonPOS.
Figure 7: TinyLoader receiving instructions to download AbaddonPOS
Figure 8: TinyLoader HTTP request to download AbaddonPOS
The AbaddonPOS downloaded in this campaign functions much like the original samples we discovered. It does, however, include a few significant changes:
- Optimized code for checking blacklisted processes (processes that will not be checked for credit card data)
- Whitelisted process list of potential point-of-sale (POS) related process names (these are the only processes that will be scanned for POS data)
- The exfiltration XOR key has been changed
AbaddonPOS whitelisted process name checking now uses a single string of partial process names (6-bytes each) concatenated together. Both the common process name blacklist and POS process name list (see Process List section) are stored in allocated memory at static offsets (Fig. 8), 0x1A8 for the blacklist and 0x5B4 for the POS process list.
Figure 9: AbaddonPOS storing process lists for later use
AbaddonPOS utilizes both lists separately from each other. That means the common process name list has no effect on the POS name list. Both lists are also checked using the exact same code. However, different results occur based on whether execution is currently in the main thread or a spawned thread. The authors use a hardcoded 0x0C0C0C0C value (Fig 10) to implement this tracking capability.
Figure 10: AbaddonPOS saving main thread identifier
Before checking the process name against either of the lists, the running process name will first be converted to lowercase (Fig. 11). Whether the current execution exists inside the main thread or a spawned thread is checked next. If 0x0C0C0C0C is found, then AbaddonPOS knows it is in the main thread and so will prepare to check process names against the common process name blacklist (Fig. 12). If 0x0C0C0C0C is not found, then the POS process name list will be used.
Figure 11: Change uppercase letters to lowercase
Figure 12: Utilizing process list depending on whether execution is in main or spawned thread
Similar to older AbaddonPOS variants, the first 4-bytes of the process name will be checked first (Fig. 13, A). If they are equal, then the next 2-bytes are checked (Fig. 13, B). If the second check was successful then thread context will be checked again (Fig. 13, C). If the current execution is in the main thread then the current process will be skipped (Fig. 13, D), while in a spawned thread context the process would be opened and searched for POS data (Fig. 13, E).
Depending on which context is being executed, different behavior will occur when the process name being checked does not match anything in the hard coded lists. If in the main execution context and no matches were found, then the process will be opened and checked for POS data (Fig. 13, F), while if in a spawned thread context, the process would not be opened and checked (Fig. 13, G).
This peculiar implementation effectively nullifies the POS process name list because the main thread would eventually search for POS data in all processes not matching the common process name blacklist, including all of the POS processes.
This implementation could result from a mistake on the part of the malware author, but it seems more likely that the author is testing various blacklist/whitelist implementations in this sample. Dedicating a thread to only processes with known POS-related names ensures a thread is always scanning those processes more often vs. the main thread used to scan all non-system related processes. Also, it would not be surprising to eventually see AbaddonPOS variants that contain only the common process name method or POS process name method rather than both.
Figure 13. Process name comparison code
Some minor changes were also made to the way stolen credit card data is exfiltrated. First, the IP address is no longer stored as an ASCII string (Fig. 14). That also means the inet_addr API is no longer needed. Finally, the hardcoded XOR key was changed to 0x4C5D6E7F (Fig. 15).
Figure 14: Hardcoded C&C IP address and port
Figure 15: New exfiltration XOR key
Although the second XOR key was changed, the overall method of encoding and exfiltration of the data has stayed almost identical (Fig. 16, 17) when compared to our previous analysis.
Figure 16: Encoded exfiltrated credit card data
Figure 17: Decoded exfiltrated credit card data
We continue to see TA530 periodically send email-borne threats to target point-of-sale systems using personal details to increase the chances of infection.
TinyLoader and AbaddonPOS are under active development. We expect both to continue to appear in email attacks as cybercriminals target point-of-sale systems to harvest credit card data. Despite changes in the credit-card landscape and more stringent PCI DSS compliance requirements, credit card-related cybercrime remains profitable for threat actors when it can be conducted at scale. Comprehensive email, network, and endpoint protection—along with user education—remain the best ways to protect systems and customer data.
AbaddonPOS Process Lists
Common process name blacklist
POS process name list
Indicators of Compromise (IOC)
Table 1: Indicators of Compromise
|Example macro document
|Initial TinyLoader download
|Example TinyLoader download
|Example TinyLoader update download
|Example AbaddonPOS download
Select ET Signatures that would fire on such traffic:
2022658 || ET CURRENT_EVENTS Possible Malicious Macro DL EXE Feb 2016 (WinHTTPRequest)
2812523 || ETPRO TROJAN TinyLoader.C CnC Beacon x86
2812524 || ETPRO TROJAN TinyLoader.C CnC Beacon x64
2814778 || ETPRO TROJAN TinyLoader.D CnC Beacon x86
2814779 || ETPRO TROJAN TinyLoader.D CnC Beacon x64
2814803 || ETPRO TROJAN Win64.TinyLoader CnC Beacon
2814810 || ETPRO TROJAN TinyDownloader Retrieving PE
2816697 || ETPRO TROJAN AbaddonPOS Exfiltrating CC Numbers 5
2816698 || ETPRO TROJAN AbaddonPOS Exfiltrating CC Numbers 6
2816699 || ETPRO TROJAN AbaddonPOS Exfiltrating CC Numbers 7
2816700 || ETPRO TROJAN AbaddonPOS Exfiltrating CC Numbers 8
Subscribe to the Proofpoint Blog