Media outlets have been abuzz the past week or so about a supposedly new variant of the infamous BlackPOS malware family.
BlackPOS gained notoriety as the malware responsible for the massive Target breach that occurred in late 2013. Security vendor Trend Micro recently published a blog post discussing a potential new variant to BlackPOS. Then Brian Krebs posted an article about a potential connection between this malware and the Home Depot breach.
While I agree that a connection between the malware used in numerous high-profile breaches would make for a good headline, the reality is there is no empirical evidence of such a connection.
As a malware analyst, I’ve looked at a number of point of sale (PoS) malware families, such as BlackPOS, Alina, JackPOS, Chewbacca, Dexter, and most recently Backoff. So my ears perked up when I heard about this new BlackPOS variant.
After careful review of both samples, I don’t believe the sample in question is actually part of the BlackPOS malware family. While I thought Trend Micro’s technical analysis was fantastic and overall a good read, it does not clearly identify a connection between the two samples. The goal of this post is to highlight the inherent differences in coding style and functionality and hopefully to stop any misinformation from spreading.
So, why do I think this malware sample is something different entirely and not BlackPOS? There are a number of reasons.
First, let’s discuss how subsystems were configured for both samples. A subsystem is used to specify what sort of environment an executable will be run in. The most common choices are “CONSOLE” and “WINDOWS” (or “GUI” as it’s sometimes shown).
A console application is designed to run on the command line, while a Windows application typically needs some sort of graphical component. The BlackPOS sample that hit Target was written with a windows subsystem, while the new malware was written with a console option. It’s a minor modification, but demonstrates an initial difference.
Subsystems use in BlackPOS and the new malware.
Interestingly enough, both samples are configured to run as a service. Being configured as a service is a common persistence technique we see on a wide range of malware samples.
Unfortunately, this persistence mechanism is where the similarities end. BlackPOS was configured to be run without any command-line arguments. It would check if it was running as a service, and in the event it wasn’t, it would create a new service with the following information:
Service Name: POSWDS
Display Name: POSWDS
Startup Type: Automatic
It’s also important to note that the BlackPOS malware doesn’t include a description, while the new malware does.
Unlike BlackPOS, the new malware is configured to take a number of command-line arguments, as we see below:
C:\Documents and Settings\Administrator\Desktop>FrameworkServiceLog.exe
As we can see, a number of arguments can be supplied. Additionally, the malware can take the ‘-service’ argument when it is being run as a service.
Another tactic we see this new malware family use is the service dependency technique. This is an important addition, which we didn’t see in the BlackPOS malware family. By adding itself as a dependency to another service, the new malware prevents it from easily being removed. After the malware installs itself as a service, it will execute the following system command that will configure it as a dependency for the legitimate LanmanWorkstation service:
%WINDIR%\\SYSTEM32\\sc.exe config LanmanWorkstation depend= mcfmisvc
The following image shows a de-compilation of the installation routine.
Installation routines for BlackPOS and the new malware.
Both samples use string obfuscation, however the techniques they employ are quite different. BlackPOS uses a simple character shift technique that rearranges previously garbled characters into their original form. It’s somewhat similar to taking your alphabet soup and rearranging the letters so they make actual words.
Conversely, the new malware makes use of a simple XOR encryption routine, where the string is XORed against a one-byte key of 0x4D. XOR, or “exclusive OR”, is a logical operation that malware authors often use for simple encryption routines.
Dump File Obfuscation
While both samples dump their harvested card data to a fake DLL file, the dumped data is obfuscated in very different ways.
BlackPOS uses a customized version of Base64 to obfuscate dumped track data. As a reminder, Base64 is an encoding scheme that is often used for translating binary data into an ASCII representation.
The new malware makes use of a substitution cipher, not unlike those decoder rings that were really popular a number of years back. The following two tables are used for character swapping.
Additionally, the format of the harvested data is quite different. BlackPOS includes a command, such as |%ADD%|, while the new malware includes the victim’s IP address, as we can see below (The following data samples is an example only, and does not represent actual payment card data):
Example BlackPOS dump data (de-obfuscated):
Example new malware dump data (de-obfuscated):
This category is where the two samples are most similar, as they both use network shares to move dump files to another machine on the compromised network.
The technique of using network shares to move harvested data is not terribly common. However, after the excessive press coverage of the Target breach, the technique is common knowledge among security researchers and malware authors.
While both malware samples moved data via network shares, their methods for doing so were very different. BlackPOS uses direct system() calls while the new malware writes its commands out to a batch script and executes it with a call to the CreateProcessA() Windows API. For less technical readers, this simply means the author for each malware sample took a very different approach to accomplishing the same thing.
In yet another example of how the two samples are different, we see differences in how they enumerate processes. BlackPOS uses the common EnumProcesses() Windows API call to identify processes to target, while the new malware uses the CreateToolhelp32Snapshot() Windows API call. Similar to what we saw in exfiltration, both authors essentially perform the same task in a different way.
The following code shows the de-compiled process enumeration techniques described above.
Memory scraping code from BlackPOS and the new malware.
Additionally, the original BlackPOS sample that was used in the Target breach used a whitelist approach to determine what processes to target for memory scraping. It specifically looked for a pos.exe executable.
The new malware, however, uses a blacklist approach. As originally reported, it has a large list of known good process names that it will ignore. Subsequently, it will scrape memory from any process not in this list.
This means that the author of BlackPOS took a far more targeted approach to memory scraping, as it will only look for card data in a single process. The new malware, however, has a much less targeted approach, as it is simply ignoring known Microsoft Windows processes.
As we’ve seen, there are a number of differences between the BlackPOS family witnessed in the Target breach, and the most recently discussed malware family.
A single difference, or perhaps a couple of differences, might be the result of minor changes in a code base. However, the number and degree of variances between these two samples are a clear indication that they were more than likely coded by different people. I think you’ll agree that when we look at the big picture, the new malware does not share any significant resemblance with the malware that hit Target.
It is unclear at this time whether this new malware is in fact the malware that was seen in the Home Depot breach. Many details have not yet been made public, so at this point in time, your guess is as good as mine. That’s the unfortunate reality and nature of electronic breaches, as ongoing investigations often prevent the dissemination of information.
While this particular sample may not be the newest variant of BlackPOS, it is still very much a serious threat. It employs a number of simple tactics that make it difficult to detect without specific knowledge of the malware family itself. Overall, I think we can all agree that no matter what this family of malware is called, it still certainly has the capability to steal a wealth of information.
See also: VirusTotal analysis for the BlackPOS Sample and the new malware sample