I’m not terribly fond of reality TV (my apologies to those who are). I often wonder, “How are they able to squeeze one more show out of the reality engine?” There are so many out there that appear to be the same thing; the differences are minute.

We run into the same issue during malware analysis. Variants that spawn from the original often differ ever so slightly, forcing analysts to dig deeper than what an antivirus solution detects. One such analyst who rolls up his sleeves and dives in to discern these tiny malware differences is Lance Mueller, senior incident response analyst for IBM’s Emergency Response Services.

You Can’t Always Rely on Antivirus?

While testing and researching the original BlackPOS malware — yes, this thing continues to rear its ugly, data-siphoning head — and a newer variation, Mueller found that it is not hard to find it if you know what to look for. It is not hidden or cloaked by any type of rootkit technology.

In other words, while it does exhibit some of the common malware characteristics, it also does not behave like other malware. Therefore, some of the indicators of compromise that we would typically look for are not there.

Ideally, an antivirus scan would detect both of these threats. At some point, though, these were not detected by antivirus, and/or a scan couldn’t be performed. Mueller said that an antivirus scan would be one of the lowest-effort attempts to find the threats. He then said you should assume that they were either not detected or that conducting a malware scan was not an option.

Oh, Good, We’re Going to Get Technical

In the case of the newest variant of BlackPOS, the malware installed itself as a service. It also has the capability to run as a normal process. However, it would not survive a reboot. Repeated installations of the malware yielded the same service name (mcfmisvc), but there have been reports that it can also pick some random names for the service from the registry, although I have not seen this behavior in any of the samples examined thus far.

The name of the executable pointed to by the ImagePath registry value can be anything, as determined by the attacker. When the malware is installed as a service, the description of the service says, “McAfee Framework Management Instrumentation.” The malware scrapes memory and puts the track data into an innocuous-looking file named “McTrayErrorLogging.dll.” The data is obfuscated, so a GREP search would not find it.

The Scary Part for Those Who Dig Deep

The BlackPOS has no command-and-control mechanism. It is designed to shuffle collected data to a common Windows file share (SMB) on another internal box so it can then be exfiltrated from there.

This presents the following detection and analysis challenges:

• Lack of external connections from the point-of-sale (POS) system
• The POS system will commonly have an SMB share connection to another internal host (Port 445). This would be very common if the POS system were on a domain, but it becomes a little more rare if the POS systems are in a work group.
• The system that it shuffles the data to may not be within scope, which is a missed opportunity to examine that host and identify the data going out.
• The system that is sending the data out may be doing so in an SSL tunnel. Therefore, firewall logs likely won’t reveal anything other than an SSL session.

Given that you may start only with basic collected volatile data in an active threat assessment or incident response, you would only have the following:

• Running processes
• Open network sockets
• Copy of registry
• File listing

The above volatile data would clearly have references to the malware (name, running process), but what, if anything, would distinguish it from any other normal process? What if it’s named to look like an innocuous or legitimate executable?

Ponder This, My Analyst Friends

Given the assumptions that the antivirus solution comes back with a score of zero or is unavailable, what would draw your attention to the malware from reviewing a list of running processes or service names? Not very much. The name of the service, sure; we know, though, that as malware evolves, it uses other mechanisms or names.

Now, assume you had an image of that same system and/or RAM, and the same assumptions applied to that antivirus detection come back as zero. What, if anything, would/could you do to help identify malware such as this?

If you were faced with this scenario on an incident response engagement, what things would you rely on to help you detect malware such as this? If your company relies on a third party to perform incident investigations, ensure it is digging a little deeper and not relying on the “usual” subjects for attributes.