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.)
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.
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.
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.
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.
|File name||Form – Aug 07, 2020.doc, COVID-19 report 08 07 2020.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.
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.
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.
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.
It turns out that the string value for the page caption is extremely long. Figure 9 shows part of the string.
According to Figure 7, this string is saved in a variable q, which is passed to a function for de-obfuscation, as shown below.
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.
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.
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.
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).
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.