Threat Analysis Unit Network Security

Defeat Emotet Attacks with Behavior-Based Malware Protection

The security community has enjoyed a few months of silence from Emotet, an advanced and evasive malware threat, since February of this year. But the silence was broken in July as the VMware Threat Analysis Unit (TAU) observed a major new Emotet campaign and, since then, fresh attacks have continued to surface. What caught the attention of VMware TAU is that the security community still lacks the capacity to effectively detect and prevent Emotet, even though it first appeared in 2014. As an example of this, Figure 1 shows the detection status on VirusTotal for one of the weaponized documents from a recent Emotet attack. Only about 25% of antivirus engines blocked the file, even though the key techniques — such as a base64-encoded PowerShell script used to download the Emotet payload from one of five URLs — are nothing new. (These results were checked five days after they were first submitted to VirusTotal.)

Detection of an Emotet-Related Document on VirusTotal
Figure 1: Detection of an Emotet-related document on VirusTotal

In this blog post, we’ll investigate the first stage of the recent Emotet attacks by analyzing one of the samples from the recent campaign to reveal the tactics, techniques, and procedures (TTPs) used. This will help us understand how this malware was able to escape detection from a majority of antivirus engines.

What is Emotet?

Emotet is a Trojan that mainly spreads through spam emails, disseminated by a cyber group called Mealybug, that contain either malicious macro-enabled documents or links. Emotet is one of the most dangerous botnets, as it enables criminals to effectively monetize attacks via information theft, email harvesting, and ransomware distribution. Figure 2 illustrates the evolution of Emotet since it was first discovered in 2014. Current versions of Emotet have been employed as downloaders for other malware, such as the banking Trojans TrickBot, Qakbot, and Ryuk ransomware.

The Evolution of Emotet
Figure 2: The evolution of Emotet

Let’s examine a typical Emotet infection chain, as shown in Figure 3. The infection chain starts with a spam or phishing email. A successful attack is achieved via a few steps: the first step requires a recipient to open a weaponized Word document attached to an email; the document typically contains some social engineering text that is used to entice the victim to enable VBA macro execution in Microsoft Word (which is normally disabled by default). Once VBA macro execution is enabled, the embedded VBA macro executes, which then triggers an embedded PowerShell script to download and execute the Emotet final payload.

A Typical Emotet Infection Chain
Figure 3: A typical Emotet infection chain

To increase the infection rate, Emotet leverages some common attack tricks, such as social engineering techniques, obfuscated VBA macros, and advanced adversary techniques like hidden PowerShell scripts. This explains why most signature-based detection engines fail to catch new malware variants like the recently observed Emotet attacks. In the following sections, we describe in detail the TTPs used in the recent Emotet infection chain, and we explain how those TTPs enable Emotet to evade static detection.

Unpacking Recent Emotet Attacks

Last month, we saw two major Emotet waves attacking our customers, occurring on August 7 and August 10. Figure 4 shows the detection timeline from this period.

Emotet Attacks That Affected VMware Customers
Figure 4: Detection timeline of Emotet that affected VMware customers from both EMEA and US regions

The attacks used some common techniques, such as data obfuscation and VBA and PowerShell scripting, as shown in Table 1.

Initial Access Execution Defense Evasion
SpearphishingAttachment PowerShell Obfuscated Files or Information
Visual Basic Deobfuscate/Decode Files or Information
Malicious File Hidden Window
Windows Management Instrumentation (WMI)

Table 1: Tactics and techniques used by the downloader

All the samples we checked fall into the following category: the Word document has a typically obfuscated VBA macro, but the PowerShell script is stored as caption metadata in a hidden userform object (more details on this below). The documents feature both conventional names, such as Form – Aug 07, 2020.doc, invoices 00436 & 9445.doc, PO# 08102020Ex.doc, as well as, unsurprisingly, Covid-19 themed names, like COVID-19 report 08 07 2020.doc.

MD5 40961300e6ae0ebbb65cd47c6daa4413
SHA1 032d9de3513b370abbe41803ed792d3bf92b834e
SHA256 dba1dec44b054e17d9551d8832427bbca55d0e7fe1e15bc527e406cdc03628d1
File name Form – Aug 07, 2020.doc, COVID-19 report 08 07 2020.doc
Size 173767 bytes
Type application/msoffice-doc

Table 2: A typical Emotet-weaponized Word document from the attacks

The Emotet downloader

To investigate the attacks, we analyzed one of the samples from the campaign, as shown in Table 2. This is a typical single-page weaponized document, which contains the usual social engineering texts as shown in Figure 5. In this case, the malware writer tries to entice the victim to enable VBA macro execution by stating that the file was created on an iOS device.

A Typical Single-page Weaponized Document
Figure 5: The opening page from the sample listed in Table 2

As we’ve seen in typical document-based attacks, the file contains highly-obfuscated VBA macros. If macros are enabled, the embedded VBA script will be executed. Figure 6 shows a snippet of the macros. The highlighted code is a human-unreadable macro snippet that creates the infamous winmgmts:Win32_Process WMI class object to invoke PowerShell processes.

In past attacks, we could still see traces of the string “winmgmts:Win32” or “PowerShell” in the obfuscated macros. This is important, because most signature-based detections heuristics are based on string patterns, created by human analysts via static analysis. If certain patterns match, detection is triggered. But in the recent Emotet attacks, it’s almost impossible to detect any traces of the class and application names, thanks to the extreme obfuscation of the macros. This partly explains why the attacks successfully evaded many signature-based detection engines.

Obfuscated VBA Macros
Figure 6: Obfuscated VBA macros

Emotet is well-known for leveraging WMI and PowerShell to launch attacks. Therefore, it’s crucial to identify the malicious PowerShell script. The main VBA module extracted from the file is not particularly long, and therefore we believe that some of the payload may be stored in other OLE objects. This is a common tactic used by attackers. Inspecting the macros reveals an interesting line in the code, which seems to load some content from an object’s page (with index as 1) caption metadata, as shown in Figure 7.

Load an Object’s Page “Caption” Metadata
Figure 7: Load an object’s page “Caption” metadata

The page “Caption” metadata is related to a multipage control object with page tabs from a hidden form, as shown in Figure 8. Leveraging form controls is a known technique of malware writers.

PowerShell Script Stored in Page2 “Caption” in a Form
Figure 8: PowerShell script stored in Page2 “Caption” in a form

It turns out that the string value for the page caption is extremely long. Figure 9 shows part of the string.

Figure 9: Highly-obfuscated long string extracted from the form page “Caption”

According to Figure 7, this string is saved in a variable q, which is passed to a function for de-obfuscation, as shown below.

Figure 10: De-obfuscate the PowerShell script

This is actually a de-obfuscation process to generate the working PowerShell script. The decoded content is shown in Figure 11. Here we see the familiar base64-encoded PowerShell script used in most Emotet attacks.

Base64-Encoded PowerShell Script
Figure 11: Base64-encoded PowerShell script

After decoding the base64-encoded script, removing garbage code, and renaming some variables, we see the functionality of the script, as shown in Figure 12. The script tries to download an Emotet payload (depending on which URL responds)from one of five URLs on to the victim’s machine, then executes it by calling the create method in the WMI class.

Figure 12: Decoded and cleaned-up PowerShell script

Once the obfuscated PowerShell script is loaded from the caption metadata (as in Figure 7) and de-obfuscated (as in Figure 9), the PowerShell process is invoked using the create method in the WMI class, as shown in Figure 13 below.

Invoke PowerShell Process via WMI
Figure 13: Invoke PowerShell process via WMI

Figure 14 shows the fishbone chart detailing the infection chain in a controlled environment when executing the VBA and PowerShell scripts in the document file. As we can see, it involves a few interesting subjects, such as powershell.exe (subject 2), the Emotet Trojan 498.exe (subject 4) and the second stage payload (subject 5).

Emotet Downloader Infection Chain
Figure 14: Emotet downloader infection chain


In the attacks discussed above, Emotet successfully leveraged various techniques to maximize its infection rate. As with typical Emotet attacks, the infection process starts with a spam campaign using phishing emails with attached, weaponized Word documents. Our findings show that evasion techniques used in the attacks, such as heavily obfuscating VBA macros and leveraging form controls like multipage captioning to hide a PowerShell script, have proved to be very effective in defeating signature-based detection. This kind of detection-avoidance has made Emotet one of the most dangerous malware threats today. It is expected that Emotet will continue to evolve its TTPs over time to remain undetected — and that fact imposes significant challenges on detection engines that are heavily dependent on signatures. On the other hand, behavior-based approaches, such as VMware’s AI-driven Advanced Threat Analyzer, show great effectiveness in defeating attacks that leverage the techniques discussed above.


Appendix: IoCs














Download URLs


























Emotet payloads