JackPOS – The House Always Wins

A new point of sale (POS) malware family could be a jackpot for credit card thieves. I recently learned of a new POS malware family, dubbed JackPOS. This certainly has been a busy 2014 with regards to POS malware. During this blog post, I dig into the guts of JackPOS and attempt to determine if this is just another POS malware family, or if JackPOS brings something special to the table. I'm also going to determine if this malware family shares any traits with previously seen POS malware families. For this post, I'll be working with the following sample:

https://www.virustotal.com/en/file/39c13ee490a2c4cf6f3aafe92734edbf2373f25cc6fab8e15cd4cf590f1abdf1/analysis/

http://www.kernelmode.info/forum/viewtopic.php?f=16&t=1756&start=160#p22150

Summary

Overall, this sample is quite simplistic and straightforward. When initially run, the malware will install itself to a subdirectory within %APPDATA%. It then performs memory dumping with a blacklist approach that was previously encountered in the Alina malware family . The malware family exfiltrates its data via a simple POST request and does not perform any encryption. Instead, sensitive data is encoded with the Base64 algorithm. Additionally, the malware has simplistic command and control (C&C) capabilities, which allow the attacker to execute commands on the victim machine, re-install the malware, or stop JackPOS remotely.

Installation

Installation of JackPOS is fairly straightforward. Upon execution the malware will determine whether the following registry key is present:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run - Java SE Platform Updater

If not, the malware will begin the process of installation. The malware installs itself to the hidden %APPDATA%\Java SE Platform Updater directory. The actual executable name is chosen from the following list:

• jusched.exe
• jucheck.exe
• javaw.exe
• jureg.exe
• jse.exe
• java.exe
• javaws.exe
• javacpl.exe

To start, the malware simply tries to use the first executable name in the list. If the name already exists in the install location, the malware will move on down the list until it finds one that is available. JackPOS then copies itself to the chosen location and sets the previously mentioned 'Run' registry key to point to this location. By writing this 'Run' registry key, JackPOS ensures that it persists across reboots. Finally, the malware will spawn a new instance of this copied malware with a single argument. Specifically, the argument denotes the location of the original file path.

The heavy use of Java-related names is a technique used to provide credibility in the event a system administrator encounters JackPOS. Simply put, the malware tries to pretend to be a legitimate Java process.

In the event JackPOS is provided an argument, it will attempt to delete the file specified. By doing so, the original binary is removed after installation completes.

Main Execution

Once the malware is installed, it will proceed to write its process ID (pid) to the following registry location:

HKCU\Software\Javaw – Pid

It will then drop an embedded executable to the %TEMP%\svchost.exe directory. This executable ensures that the main JackPOS binary is constantly running. It will check for the presence of the pid specified in the registry key above to determine if JackPOS is running. If the binary is not running, it will spawn a new instance. The svchost.exe malware will also write its own pid to the following registry location:

HKCU\Software\Javaw – Pid1

This value is checked by JackPOS to ensure that multiple instances of svchost.exe are not running. As an aside, an interesting thing to note is that svchost.exe will not function on Windows XP or below. This is due to the binary's Optional NT Headers. A Windows executable sets a number of headers. The following optional headers allow an author to specify the minimum Windows operating system that the executable supports:

• MajorOperatingSystemVersion
• MinorOperatingSystemVersion
• MajorSubsystemVersion
• MinorSubsystemVersion

In this specific case, the author set the minimum Windows operating system for svchost.exe to Microsoft Vista and above.

I'm assuming this is a simple mistake on the author's part, as I cannot think of any situation where they would not wish for this persistence mechanism to operate on Windows XP, which the JackPOS binary itself supports.

Now that the svchost.exe binary has been dropped and executed (on Vista and above at least), the malware proceeds to make a GET request to the '/post/echo' URI. The hostname of the malicious server is hardcoded within JackPOS itself. The malware expects the webserver to return the 'up' string as a response. This is used as a check to ensure the remote webserver is up and running before any track data is uploaded to it.

The malware then begins iterating through every running process on the system and comparing each process to the following list:

• System
• [System Process]
• smss.exe
• csrss.exe
• winlogon.exe
• services.exe
• lsass.exe
• svchost.exe
• spoolsv.exe
• wscntfy.exe
• alg.exe
• mscorsvw.exe
• ctfmon.exe
• System Process
• taskhost.exe
• dwm.exe
• skype.exe

The malware ignores any process in this list and any 64-bit processes. JackPOS then begins reading memory from the remaining processes and targets physical private and mapped memory sections.

Unfortunately, the malware does not close the handle to the opened process every time the memory dumping occurs. This bug results in an exceeding number of opened handles, which causes problems later on.

Once memory has been dumped, the malware applies track 1 and 2 regular expressions. Track data is another term for the data found on the magnetic stripe of debit cards, credit cards, gift cards, etc. (http://en.wikipedia.org/wiki/Magnetic_stripe_card). Any discovered data is uploaded to the remote webserver via a POST request to the '/post' URI. An example of this can be seen below:

Notice that the track data is Base64-encoded. Additionally, the malware uploads the victim's MAC address, presumably as a way of identifying unique victims. It's also worth noting that the User-Agent 'something' is hard-coded within the malware, making these POST requests somewhat trivial to identify. When these POST requests occur, the attacker has the option of providing one of the following three rudimentary commands as a response:

• update
• kill
• exec

The 'update' command will instruct the malware to follow its install routine, which in turn ensures that the malware is running as a different executable name. The 'kill' command will terminate both the JackPOS malware and the dropped svchost.exe executable. The exec command expects an argument with a space delimiter. For example, 'exec cmd.exe' would be a valid response. However, the malware expects the executable to reside in the %TEMP% directory. So, with my 'cmd.exe' example, the malware would attempt to execute %TEMP%\cmd.exe. With no download functionality, this seems like an odd decision by the author. It's possible to execute cmd.exe, however, you essentially have to use a directory traversal technique, such as the following:

exec ..\..\..\..\..\..\..\windows\system32\cmd.exe

In other words, the functionality is a bit broken. It's just another example of how this malware lacks the polish seen in other families.

A Note About The Author

A number of pdb strings are found in both JackPOS and the dropped file, as seen below:

C:\Users\ziedpirate.ziedpirate-PC\Desktop\sop\sop\Release\sop.pdb
C:\Users\ziedpirate.ziedpirate-PC\Desktop\sop\sop\Release\svchost.pdb

The name 'ziedpirate' is found in a number of Google searches. Additionally, the name is also found in a number of other malicious samples. A number of Israeli web defacements appear to have originated from a user known as 'ziedpirate'. This along with other indicators alludes to the fact that the author may originate in Tunisia.

Closing Thoughts

Overall, this malware is quite rudimentary. A number of bugs (some of which I've mentioned in this blog post) show a lack of sophistication and, possibly, a rush on the author's part. There are a number of artifacts that link this malware family to others we've seen. The blacklist of process names is extremely similar to the ones discovered in the Alina malware family. Additionally, the installation path very much reminds me of the early Dexter variants. It's certainly likely that because these malware families' code has been leaked online, the author used at least some of this code as a basis for JackPOS. While the malware technically has a command and control (C&C) component to it, overall it's quite limited and not nearly as robust as other examples seen in the past. I mentioned originally that I wanted to see if JackPOS brought something special to the table. I'm going to have to answer that question with a resounding "no" in this particular case. However, while this family does not bring any innovative characteristics to the POS malware scene, as history has taught us, it should still very much be considered a real threat.

(Special thanks to Xylitol - http://www.xylibox.com/ for the initial heads up on this malware family)

Appendix A - Blocking JackPOS With SWG

The following steps may be followed by SWG users in order to block the JackPOS threat via the static user-agent employed by it:

Create a new Header Field list with the user-agent in it:

1. Go to Policies -> Condition Elements -> Header Fields
2. "Add Component" to create a new list
3. Name the list, and add the following condition:
   1. Header name: "User-Agent"
   2. Condition "Equals"
   3. Header value: "something"
4. Save the list

Add this list to your custom policy:

1. Go to Policies -> User Policies -> Security (may vary between versions)
2. In you custom policy, under the rule "Detect Trojan Communication Based on Header Fields", in the condition "Header Fields", check the newly created list
3. In the rule "Detect Trojan Communication Based on Header Fields", uncheck "X-Ray"

***Update as of March 6, 2014***

Recently, SpiderLabs was able to acquire a new sample of JackPOS. As such, we're updating this blog post with information about this new binary. Overall, functionality appears to remain the same (bugs and all). However, it appears that the author noticed his mistake the last time around regarding the pdb string, as he/she is now using the following:

I:\hack\dev\pos\sop\Release\svchost.pdb

Additionally, the following MD5s were witnessed:

• Main executable: 75990DDE85FA2722771BAC1784447F39
  
  
• Dropped svchost.exe: 8FE50092EDBDA8D88D835EFC0FFE31EE