Emotet 101, stage 2: The malicious attachment and killchain

The Emotet malware family is in a constant state of evolution and change. From day to day or week to week, the malware’s creators and distributors take an active role in changing up the killchain – the sequence of events that begins with a victim receiving a malicious file attachment, and ends with an infected computer.

So instead of trying to summarize something that, five minutes after we publish this document, will have changed, possibly several times, we’ll focus on just one of the common infection vectors – malicious document files – and some of the steps that the authors have crafted into the Emotet killchain using those documents as our starting point.

As we wrote in our previous post, many Emotet attacks begin with an email message that may have a Microsoft Office document (or, occasionally, an Adobe PDF document) attached to the message; Alternatively, the message may link to a website that delivers the Office document to the user upon clicking the link.

Despite the information security industry cautioning that users should treat Office documents received via email with caution, many users remain unaware that files such as Word documents, Excel spreadsheets, Powerpoint presentations, or PDF files can contain active content in the form of scripts or macros — files we commonly refer to, en masse, as maldocs.

Maldocs have been used for some time as a delivery vehicle for malware. The maldocs used for Emotet delivery follow a template that’s designed to provoke the victim into disabling safety features within Microsoft Office that, themselves, are designed to prevent malicious documents from causing harm. Many of the document templates explicitly encouraged the victim to turn off Macro script blocking features within Office.

Tracing the killchain

Several researchers within SophosLabs track various aspects of the Emotet killchain, plugins, and payloads, and have done so for some time. The infection process can be boiled down to “run several obfuscated command lines until it invokes a PowerShell command that downloads an Emotet executable.” But of course, the devil’s in the details.

When victims open the malicious Word document, just opening the maldoc may not be sufficient, hence the prompting for the victim to disable one or more security features that would prevent disaster if left alone.

What happens next usually takes place out of sight of the user, but is best illustrated by this screenshot of Process Explorer, which shows the stages of a typical infection process.

The maldoc in the screenshot above invokes the Windows command shell, cmd.exe, with a lengthy but obfuscated command. The first command uses three completely bogus directories, and a directory traversal gimmick that navigates the script back to the root of the hard drive, then up the correct folder path to system32, to invoke cmd.exe, again.

That second command further decodes parts of the obfuscation, and launches a third command, which in turn executes a PowerShell command. Typically, no more than four such child processes were launched in the course of the attack, and the attack sometimes took up to a minute to complete as the final script tried to download a payload from each of the hardcoded payload URLs embedded within the final-stage PowerShell script, in sequence.

Another notable aspect of the scripts used in the killchain is that they are like the scripting code equivalent of a Russian nesting doll, with one script decoding part of the next script, which decodes part of the next script, until the final commands to download the payload have been invoked. Here’s a typical example, where each successive command decoded part of the next command until it gets to the final command to invoke PowerShell, and download the payload.

Cat and mouse game

In our experience testing against Emotet maldocs that were only a few hours old, fewer than a third of the websites hardcoded to deliver the payload were active or still hosted the payload executable. Many of the sites had already been cleaned up, shut down, locked or parked, or responded to the request with a HTTP code of “403 Forbidden.” Emotet’s operators play this constant cat-and-mouse game with web hosting services and security companies.

The payload URLs all follow a similar pattern in their construction: They have been hosted on (usually) the root level of a legitimate, but previously compromised, website. The filenames are from 3 to (usually a maximum of) 12 randomized alpanumeric characters in length.

In a handful of instances, the mail messages did not use Office documents but had attached PDF documents instead. In these cases, the PDF linked to a maldoc file and, in at least a few cases, directly downloaded the Emotet executable payload without resorting to the full series of commands and PowerShell script.

The scripts used many techniques, refined over many years, designed to obfuscate the intent of the code. Accounting for all of these techniques falls outside the scope of this analysis. However, when you’re just trying to make the files run, as we were, the intent essentially makes itself clear.

Acknowledgments

SophosLabs researchers Gabor Szappanos and Felix Weyne contributed to this section of the report.