AbaddonPOS: A new point of sale threat linked to Vawtrak

Share with your network!

UPDATED 11/24/2015

Point of sale (PoS) malware has been implicated in some of the biggest recent data breaches, striking retailers, restaurants, hospitality and organizations from a variety of industries, and often targeting consumers in the US. [1] Once considered too difficult to carry out to be practical for cybercriminals, the retail breaches of late 2013 demonstrated that these attacks are both feasible and highly profitable for cybercriminals, and PoS malware has since continued to evolve and grow in both variety and sophistication. [2]

Proofpoint threat researchers recently detected a new addition to PoS malware landscape. Named AbaddonPOS by Proofpoint researchers, this sample was initially discovered as it was being downloaded in the process of a Vawtrak infection. This use of additional payloads to enhance attack capabilities offers another example of efforts by threat actors to expand their target surfaces through the delivery of multiple payloads in a single campaign, in this case by including potential PoS terminals. This post will analyze AbaddonPOS; discuss the observed infection vectors; and expose, details on the downloader used to retrieve this new PoS malware. We will also provide evidence to demonstrate that the downloader malware and PoS malware are closely related, perhaps even written by the same actor or actors.


Known infection vectors

On October 8, Proofpoint researchers observed Vawtrak [3] (project ID 5) downloading TinyLoader, a downloader that uses a custom protocol for downloading executable payloads from its command and control (C2) server. TinyLoader was then used to download another downloader in the form of shellcode, which then downloaded AbaddonPOS. Although this infection vector was initially specific to Vawtrak’s project ID 5, we have also since observed it delivered in project IDs 6, 9, 10, 12, and 13. The project ID’s are most easily observed with Vawtrak C2 traffic, as they are stored encoded in the PHPSESSID cookie value. Using the cookie value we provided as an example in our research on Vawtrak enables us to see it in a decoded state (Fig. 1). Bytes 4-7 contain the project ID in little-endian byte order. 

Decoded Vawtrak cookie displaying campaign/project ID

Figure 1: Decoded Vawtrak cookie displaying campaign/project ID

In addition to observing AbaddonPOS as it was delivered by an Angler EK → Bedep → Vawtrak infection (Cyphort, [4]) and Angler EK → Bedep (bypassing Vawtrak), Proofpoint researchers have also observed this infection behavior delivered by weaponized Microsoft® Office documents downloading Pony → Vawtrak (Fig. 2).

AbaddonPOS infection chain

Figure 2: AbaddonPOS infection chain



TinyLoader’s sole purpose in this infection chain is to retrieve executable instructions from the C2, which allows the attackers to execute their own custom shellcode on infected machines in addition to downloading and executing additional malware payloads. True to its name, TinyLoader is typically 2-5KB in size. One notable characteristic of TinyLoader is that prior to contacting its single hardcoded C2 IP address, the malware will first check to see if it is running as an x64 or x86 process using the IsWow64Process Windows API (Fig 3.). TinyLoader selects a value based on the result of this API call, and the result is then used to tell the C2 which executable code should be downloaded to the infected client.

TinyLoader API call checking for x86 or x64

Figure 3: TinyLoader API call checking for x86 or x64

As shown in Figure 3 above, 0x84 is used with x86 processes while 0xBA is used with x64 processes; however, the values used for each architecture vary depending on the variant. Once the correct architecture is selected, TinyLoader builds a packet to send to the C2 to initiate the payload download process. Prior to retrieving the downloader that downloads AbaddonPOS, we have observed TinyLoader first retrieve a copy of itself (this step may vary slightly), which is then used as a persistence method by adding a registry key to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (Fig. 4). TinyLoader may also download a DLL version of itself, in which case the registry key observed is similar to the following: regsvr32.exe /s “C:\PROGRA~2\[a-zA-Z0-9]+\.dll”

TinyLoader persistence registry key example

Figure 4: Example of TinyLoader persistence registry key

Once the persistent payload is written to disk, another payload is downloaded by TinyLoader in the form of shellcode (Fig. 5), the purpose of which is to manually craft a HTTP request that is then used to download an AbaddonPOS payload (Fig. 6). 

TinyLoader binary protocol retrieving shellcode

Figure 5: TinyLoader binary protocol retrieving shellcode

HTTP request retrieving AbaddonPOS variant, crafted by shellcode

Figure 6: HTTP request retrieving AbaddonPOS variant, crafted by shellcode



AbaddonPOS is another addition to the PoS malware category, which has attracted a significant amount of attention from malware authors over the years. [4] Similar to TinyLoader, AbaddonPOS is a relatively small package, with most samples being 5KB in size. While the core functionality of this new addition is fairly simple, it contains several features that merit analysis and further discussion: anti-analysis, code obfuscation, persistence, locating credit card data, and a custom protocol for exfiltrating data.


Anti-analysis and obfuscation

AbaddonPOS implements several basic anti-analysis and obfuscation techniques to hinder manual and automated analysis techniques. For example, AbaddonPOS employs a CALL instruction to push a function parameter onto the stack rather than simply using, for instance, the more common PUSH instruction. A CALL instruction pushes the next address onto the stack, which is typically used as a return address following a RETN instruction. In this case, the CALL instruction is used to push the address containing a string (Fig. 7): specifically, the address containing the string “devil_host” is pushed onto the stack, which is then used as a mutex.

AbaddonPOS using CALL instruction to hinder static analysis

Figure 7: AbaddonPOS using CALL instruction to hinder static analysis

Most of AbaddonPOS’ code is not obfuscated or packed, with the exception of the code used to encode and transmit stolen credit card data. This shellcode is encoded using a 4-byte XOR key; however the key is not hardcoded. Instead, using the first 4-bytes of the decoded shellcode, the malware iterates over all possible 4-byte XOR keys until the correct one is found by checking the result against the hardcoded instructions: 0x5589E58B (Fig. 8). Once the XOR result matches the hardcoded instructions, then the correct key has been found and the malware continues to decode the shellcode using that key.

AbaddonPOS shellcode decoding routine

Figure 8: AbaddonPOS shellcode decoding routine


Locating credit card data

AbaddonPOS searches for credit cards by reading the memory of all processes except itself by first blacklisting its own PID using the GetCurrentProcessId API. To find credit card data, AbaddonPOS roughly follows this process:

  1. Search for 3, 4, 5, or 6 string characters, indicating the first number of a potential credit card
  2. Credit card number length >= 13 and <= 19
  3. Valid track delimiter (track 1: “^”, track 2: “=”, or “D”)
  4. Track 1 max length: 120, Track 2 max length: 60
  5. Additional checks based on whether track 1 or track 2 delimiters were found
  6. Check credit card number with the Luhn algorithm

The AbaddonPOS sample with md5 hash: f63e0a7ca8349e02342c502157ec485d was analyzed for the process above. The slightly older version of AbaddonPOS may contain slightly modified functionality, including not allowing “D” as a track 2 delimiter.


Exfiltrating stolen credit card data

Although many of the different PoS malware families rely on HTTP to exfiltrate data, AbaddonPOS uses a custom binary protocol. Communication and exfiltration of credit card data is carried out by the decoded shellcode discussed above. A single hardcoded IP address is used as the C2 address, as well as the encoding routine that is used to obfuscate exfiltrated data. An example of the network traffic generated during a single credit card data exfiltration attempt is shown in Figure 9.As a result of this analysis, Proofpoint created and published ET Pro IDPS signatures (ID’s 2814677-2814680) to detect exfiltration attempts on October 30.

AbaddonPOS exfiltrating encoded credit card data to C2

Figure 9: AbaddonPOS exfiltrating encoded credit card data to C2

The first four bytes of the network traffic are the length of the encoded data, while the following four bytes are the value of the process handle returned by OpenProcess. The subsequent bytes are the encoded exfiltrated data, which in a decoded state follows this format:

[credit card data] ***[process name]

To encode the data, the malware first XORs four bytes of the plaintext with the process handle, followed by a second XOR with a hardcoded 4-byte key. The exfiltration network traffic in Figure 9 is shown in its plaintext state in Figure 10. 

Plaintext exfiltrated credit card data and process name

Figure 10: Plaintext exfiltrated credit card data and process name

The following Python script can be used to decode the network traffic, provided it has been encoded using the technique described above:

import sys,struct,hexdump

filename = sys.argv[1]

with open(filename, 'rb') as f:

        c2_traffic = f.read()

encoded_size = struct.unpack('<I',c2_traffic[:4])[0]

openprocess_handle = c2_traffic[4:8]

encoded = c2_traffic[8:]

key = [0x22,0x11,0xAA,0xFF]

decoded = ''

for i in range(encoded_size):

        decoded += chr((ord(encoded[i])^key[i%4])^ord(openprocess_handle[i%4]))

print 'Decoded AbaddonPOS exfiltration network traffic:'



AbaddonPOS Variations

Of the samples Proofpoint researchers have discovered and analyzed so far, very few samples seem to have had any functionality added or removed. While “devil_host” is the most prominent mutex used by this malware, we have also found a sample that uses “devil_kor” (md5, a55843235cd8e36c7e254c5c05662a5b), and another that uses “DeviL_Task” (md5, ac03e0e9f70136adede78872e45f6182). We also observed a slightly updated version of AbaddonPOS (see IOCs) where almost all functionality was relocated to the encoded shellcode. In these updated samples the mutex “MG_REX” was used and the credit card search algorithm was also modified by adding ‘D’ as a valid track 2 delimiter.


Connecting the dots

TinyLoader has now been in development for at least a year, with a first sighting reported on January 16, 2015. Over the past year, TinyLoader has undergone several developmental changes, including:

  • Switching from UDP protocol to TCP
  • Removing process and UUID reporting
  • Adding different anti-analysis
  • Adding obfuscation and encoding

With the emergence of AbaddonPOS, it was quickly apparent that TinyLoader and AbaddonPOS are closely connected, and not simply because TinyLoader was used as the downloader. The code of TinyLoader and AbaddonPOS share some important similarities, including:

  • Anti-analysis (CALL to push strings onto stack)
  • Obfuscation (encoding shellcode using exact same encoding routine)

The similarities with code excerpts including a timeline according to Proofpoint data are provided below (Fig. 11).

Code history comparison for TinyLoader and AbaddonPOS

Figure 11: Code history comparison for TinyLoader and AbaddonPOS



The practice of threat actors to increase their target surfaces by leveraging a single campaign to deliver multiple payloads is by now a well-established practice. While using this technique to deliver point of sale malware is less common, the approach of the US holiday shopping season gives cybercriminals ample reason to maximize the return on their campaigns by distributing a new, powerful PoS malware that can capture the credit and debit card transactions of holiday shoppers.


UPDATE November 24, 2015

Further research on TinyLoader and AbaddonPOS turned up samples indicating that this threat has been in the wild since at least August 2015. The current earliest known samples of AbaddonPOS include:

266ce6d907a90e83da0083eee06af123 -> svchost_bin -> -> Compilation timestamp 2015-08-19 22:29:46

91992a1cac7f15e899b22d9a53cabf71 -> svchost_bin ->

538482356b4eb4e0552d16b08d5c2908 -> svchost_bin ->

05134cd6a50440b2c6d9ef62d2c2c3a3 -> svchost_bin ->

7b137055fd40c39bdc76d27ff4fc82ed -> -> Location: [hxxp://50.7.71[.]99/970/ad06b6e922623e436c7a.exe], downloaded by TinyLoader.C (md5: 4aa0ca129358b82a285e0d069a36e7fb)

7e49d646cb74718dcce21d3d3ad948d1 -> svchost_bin -> -> Location: [hxxp://50.7.71[.]99/upload/7e49d646cb.exe], downloaded by TinyLoader.C (md5: 3733bb7a96e3091183d80b7a4914c830)

c7db01ba6b73188640e0fb65aab0d535 -> svchost_bin ->

The earliest versions of AbaddonPOS are distinguished primarily by fact that it first targets track data delimiters ("=" and "^") for finding potential credit card data instead of a beginning number ("3", "4", "5", and "6").

Three earlier versions of AbaddonPOS have been identified (credit: Nick Hoffman):

81055d3e6ab2f349f334a87b090041dc -> svchost_bin -> 50.7.138[.]138:13030

da0cd8228745081b58594103163d22b8 -> svchost_sin -> 50.7.138[.]138:13030

04b68e4f4c7583201397d6674a3e2503 -> svchost_ghost -> 50.7.138[.]138:14040

The primary difference between these versions and the AbaddonPOS version analyzed in the original post is that these other versions contain a process blacklist: these processes will not be scanned for credit card data. The implementation is unique in that it searches only the first four bytes of each process; if those four bytes match, then it will search two more; and if those match as well, that process will be skipped. (Fig. 12) The blacklist contained the following partial process names:















AbaddonPOS svchost.exe blacklist instructions

Figure 12: AbaddonPOS svchost.exe blacklist instructions

Proofpoint researchers discovered the following additional hashes for AbaddonPOS:

4a85feef07d4aed664624331cdbcdd66 -> DeviL_TasK -> 5.8.60[.]23:21920

6ac78bc0bd16273c654cec105567c73e -> no startup mutex -> 5.8.60[.]23:21930

6b02efef0580dce8e49d27196cff6825 -> M_RAY -> 193.28.179[.]13:20930

6f1d8ca36190668163f005c7f2c9007f -> M_RAY -> 193.28.179[.]13:20950

421dfc4856262445d12fe110bf4f2c56 -> DeviL_TasK -> 5.8.60[.]23:21940

9646e0a87be71c225f2aa8639354bd4f -> M_RAY -> 193.28.179[.]13:20940

46810f106dbaaff5c3c701c71aa16ee9 -> no startup mutex -> 176.114.0[.]165:21940

e9aeb88d393e6259b5fb520bc7a49ac0 -> M_REX -> 193.28.179[.]105:20910

Other malware that are likely used by these actor(s) include:

TinyLoader.C (md5: aa7897623f64576586e4b6ec99d8ccc6) was used to download Fleercivet/Bagsu, a Trojan used to commit adfraud (md5: 79dc1ce122f7bddd730d886df1a4739a, location: [hxxp://50.7.71[.]99/file/bin86crypt_full.exe])

TinyLoader.B (md5: a94c51c5e316d6e3b1cde1f80f99eb94) downloaded Fleercivet (md5: 637b764c78ddda0e1d5351a10b19bcb8, location: [hxxp://50.7.71[.]214/upload/7777.exe])

TinyLoader.C (md5: 739cea68598ae347fae1d983e16a7d27) downloaded ReactorBot/Rovnix (md5: c755c9532c1ee517b25f98719968e154 and md5: 9a2fb9aa94d78313420c4106108b5fef, location: [hxxp://80.79.123[.]98/aurum/c.work.exe]

TinyLoader.C (md5: 19516ab9a7169c53bd811c975d5fea7d) was used to download Fleercivet (md5: 227e6b1f3e66f00a4fc683d4f39da904, location: [hxxp://50.7.143[.]61/id_1123.exe]) and a packed TinyLoader.C (md5: a86b91fda7ec634e44e4b6b7e69ed659, location: [hxxp://50.7.143[.]61/40930.exe] )

These actors may have also employed CryptoWall at some point, as the imphash for 227e6b1f3e66f00a4fc683d4f39da904 matches the imphash for a known CryptoWall sample (md5: 2af149845f4d1ce8e712622d3f1ec46e). Both samples are packed, so it is possible that two actors utilized the same packer/crypter or packing/crypting service.



[1] https://www.washingtonpost.com/news/the-switch/wp/2014/08/22/secret-service-estimates-type-of-malware-that-led-to-target-breach-is-affecting-over-1000-u-s-businesses/

[2] http://www.cio.com/article/2910024/data-breach/history-repeats-itself-as-pos-breaches-continue-in-2015.html

[3] https://www.proofpoint.com/us/threat-insight/post/In-The-Shadows

[4] http://www.cyphort.com/psychcental-com-infected-with-angler-ek-installs-bedep-vawtrak-and-pos-malware/

[5] http://researchcenter.paloaltonetworks.com/2015/10/understanding-and-preventing-point-of-sale-attacks/


Indicators of Compromise (IOCs)

IDS/IPS Detection (ET signature IDs)



TinyDownloader (downloader shellcode HTTP request):





TinyLoader Samples:





































TinyLoader C2 IP addresses:







AbaddonPOS Samples:


























AbaddonPOS Exfiltration C2 IP addresses:















Observed AbaddonPOS Location URLs:

















AbaddonPOS Yara signature:

rule AbaddonPOS



                        description = "AbaddonPOS"

                        author = "Darien Huss, Proofpoint"

                        reference = "md5,317f9c57f7983e2608d5b2f00db954ff"


                        $s1 = "devil_host" fullword ascii

                        $s2 = "Chrome" fullword ascii

                        $s3 = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run" fullword ascii


                        $i1 = { 31 ?? 81 ?? 55 89 E5 8B 74 }


                        uint16(0) == 0x5a4d and (all of ($s*) or $i1) and filesize <= 10KB



Code Comparison Samples