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.

More from Malware

When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

RansomExx Upgrades to Rust

IBM Security X-Force Threat Researchers have discovered a new variant of the RansomExx ransomware that has been rewritten in the Rust programming language, joining a growing trend of ransomware developers switching to the language. Malware written in Rust often benefits from lower AV detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language. For example, the sample analyzed in this report was not detected as malicious in the…