HP Threat Research Blog The Emotet Banking Trojan: Analysis of Dropped Malware Morphing at Scale

Hackers Keep it Simple: Malware Evades Detection by Simply Copying a File

December 3, 2017 Category: Uncategorized By: Joe Darbyshire Comments: 0

The Emotet Banking Trojan: Analysis of Dropped Malware Morphing at Scale

  • We analyzed samples containing the Emotet banking trojan and broke down the findings in a side-by-side comparison.
  • Malware authors are repacking their malicious software into a unique executable for each potential victim, avoiding any-and-all signature-based detection.
  • Repacked dropped executables on this scale are unprecedented, and this is why application isolation and control is so important. Protect before you detect is the only secure approach.

Recently, the Bromium Lab team uncovered a series of samples containing the Emotet banking trojan, which indicates that malware authors are rapidly rewrapping their packed executables and the documents used to distribute them. Based on feedback and further monitoring, we investigated the polymorphic dropped executables in more detail. The results are quite interesting; the samples don’t just feature trivial changes or the addition of random data. Rather, the sample appears like completely different software in many aspects. This allows the samples to avoid signature-based anti-virus as well as package detection and static analysis.

Extravagant repackaging hides the malware.

We have collected dozens of samples and analyzed several dropped from various malicious servers linked to this campaign. For ease of sharing, we will compare two samples side by side. Both were dropped from different malicious documents received in quick succession from the same malicious server.

Emotet Trojan analysis 1

As you can see, these samples are superficially very different. However, basic dynamic analysis using Procmon shows that, once unpacked, they execute the same sequence of system calls.

Watch application isolation in action: see Bromium contain malware.

To understand what’s happening, we disassemble and compare.

Shortly after the entry-point of each sample we reach the start of what could be considered a “dummy program.” This appears to be randomly generated code designed to look like a legitimate application. For example, Sample One calls CreateMetaFile to make a file “ExwgBDryShtwACnd” that it doesn’t use. Sample Two calls EmptyClipboard and neither appear to change the behavior of the program in any meaningful way. Since the two samples were received in quick succession, we have reason to believe that this process may be automated.Emotet Trojan analysis 2

Analyzing the unpacking algorithm.

Only once this farce comes to an end, we are presented with the unpacking algorithm itself. As you can see, either each sample is protected with a new packer, or the packer itself features advanced polymorphic functionality. These differences make it nearly impossible to profile a new sample based on the footprint of the packer alone, and presents a huge obstacle for anti-virus that attempts automated unpacking as part of its analysis.

Emotet Trojan analysis 3

Verifying the identity of the unpacked code.

When making inferences about the packer’s behavior, we need to be certain that we are dealing with that same underlying executable. To confirm, we let the unpacker complete its work. Then we dumped each sample from memory, located the recently unpacked segments and compared them. Immediately it’s clear that these samples have the same origin:

Emotet Trojan analysis 4

Detect-to-protect security approaches don’t work.

Malware authors are repacking their software into a unique executable for each potential victim, avoiding any-and-all signature-based detection. Although we have seen this with polymorphic documents, repacked dropped executables on this scale are unprecedented. This is why detect-to-protect security approaches won’t work. It will always be a matter of catch up, as the writers of malicious code are one step ahead. The scale we see on these samples suggests they may be more than just a few steps ahead.

It’s time to change the game: application isolation and control allows you to protect before you detect. With Bromium, untrusted tasks execute in a hardware-isolated virtual machine essentially invisible to the end user. This means every time a user downloads an attachment from an email, opens a tab in a browser, executes an untrusted Office or PDF document, or runs an untrusted executable, Bromium isolates that activity. If malware is being delivered, it does so inside the virtual machine thus keeping the protected host operating system safe.

Get started today. Contact Bromium to request a demo.