- 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.
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.
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.