Security / January 13, 2020

Emotet: Not Your Run-of-the-Mill Malware

Discovered in 2014, the Emotet botnet continues to be a top-tier threat to SMBs, enterprises and government networks. Often downplayed by network defenders as “commodity malware” or “only crimeware”, Gigamon Applied Threat Research (ATR) has seen first-hand the different types of attack that can come with an Emotet infection (including those conducted by high-end FIN and APT threat actors). Although it is widely known, and we’ve been talking about it for a while, Emotet certainly is not run-of-the-mill crimeware. In fact, the U.S. Computer Emergency Response Team (US-CERT) calls Emotet “the most costly and destructive malware” on the Internet.

Furthermore, with the constant diversification and expansion of the criminal network behind it, Emotet continues to evade antivirus and other security technologies to gain access to customer networks. In light of this, Emotet should be at the very top of the list of malware threats you are paying attention to in 2020.

Kicking off a series of deep-dive blogs on Emotet, this entry begins by recapping the role that Emotet plays in the criminal ecosystem and sheds light on the current set of technical capabilities and techniques behind it. Then we’ll take an in-depth look at Emotet’s PowerShell stager/download cradle to show how it’s obfuscated and to provide some endpoint and network detection guidance. Since Emotet has just ended their winter break (which typically begins around the normal western Christmas holiday and ends after the Russian Orthodox Christmas), we’ll also look forward to how this threat will continue to evolve in 2020.

Emotet’s Role in the Criminal Ecosystem

Emotet’s rise as a banking trojan and credential stealer is well documented, and while this should be reason enough not to want it in your network, more chilling is the reality that Emotet has evolved into something akin to “Emotet and Friends”, with the worst kind of “choose your own adventure” scenario for its victims:

Figure 1: Emotet attacks often vary by victimology.

The best way to think about Emotet in the current criminal ecosystem is as the primary provider of access to victims for multiple other large criminal actors. Don’t treat an Emotet infection as a single event in your network, since the bad guys are often reselling access to other criminal groups that will do more than just use your network as a spam hub.

Emotet the Shark – Constant Movement for Maximum Impact and Evasion

In researching Emotet, we have observed a large amount of churn recently in both the cosmetic appearance and the underlying structure of different Emotet components, all aimed at increasing the efficacy of its tools and attacks, as well as at evading or breaking a number of formerly successfully analysis techniques and tools designed to thwart its TTPs.

Figure 2: The layers of Emotet.
Figure 3: Emotet activity before the winter holiday break.

Of particular note are a number of changes in the way Emotet stores its sensitive data, specifically as relates to the PowerShell cradle in the malicious documents that Emotet uses. In the lead-up to the winter break, emotet deployed numerous changes in the document format, such as a switch from using autoopen to document_open to automatically execute the OLE VBA macro when the document is opened, as well as modifications to the use of forms objects that store the PowerShell cradle. The base64-encoded PowerShell has been divided into chunks, with the string “JAB” being separated from the rest of the Powershell payload, which itself has been stored in a different type of VBA object, reducing the ability of analysts to statically identify and decode the cradle code.

Figure 4: A view of the sorted form objects used to store the PowerShell cradle and other data used by the embedded macros.

These efforts largely paid off for the Emotet team. Over the last two weeks before the winter break, we saw detection rates decrease by over 50%, with many major commercial antivirus products failing to detect the malicious email documents or relying on less accurate heuristic detections. Overall, only 24% of security products were succeeding at detecting the file as malicious.

Emotet’s Recent Technical Capabilities

Initial Access Via Linked or Attached Malicious Word Document

Emotet’s malicious Word file methodology is well-documented here. It relies on the document executing a malicious VBA macro that uses a PowerShell cradle to pull down the next stage of the malware. This method makes Emotet highly elusive in that its OLE VBA object is easily obfuscated (and can be obfuscated in a number of ways), making it difficult for antivirus providers to write detections for the malicious documents (actually, we weren’t seeing any specific detections for Emotet by mainline commercial A/V products, and were seeing limited heuristic detection with 13/62 engines). Also, the Word document format is a binary format, for which some antivirus providers are limited in their ability to write stable, specific detections absent the ability to extract and process the OLE VBA objects. Long story short, if you’re depending on antivirus software to keep Emotet out of your network, you may be playing a dangerous game.

The best approach is to limit or filter Office files containing embedded macros at your email gateway, or with SPAM filtering, so that malicious document attachments are never delivered to targets in the first place.

Figure 5: Infection process.

PowerShell Download Cradle

The Emotet PowerShell cradle is the malware’s “download and execute” component, which communicates to a long list of compromised WordPress sites and open website directories. Emotet uses WMI to spawn a hidden PowerShell instance, and each payload comes preconfigured to grab its content from one of five websites. This is especially effective in that it provides Emotet with:

  • Resiliency (usually at the time of an attack, all five of the websites are online, and if any number of them are taken offline, the payload often remains online for days or weeks until all five instances are remediated by the websites’ owners).
  • Non-attributable hosting (generally, the infrastructure used in this model is non-criminal in nature and not tied to Emotet threat actors).
  • Bypassing of proxies and other gateway appliances (legitimate websites are generally not blocked by proxies and web gateways).
Figure 6: A view of the HTTP request and response for the Emotet malware payload.

Stage 1:  Payload Execution

The payload from the compromised website executes as a three-digit .exe, which then unpacks and loads an additional .exe payload with a generated filename like serialfunc.exe, which in turn checks in to the controller (C2).

Stage 2: Dropped Payloads

Dropped payloads continue to be loaded in the PowerShell process selectively, based on the victim machine (for an x86 victim running in a sandbox, the v1vMKw.exe payload gets loaded and then calls back and reloads the original Emotet executable, serialfunc.exe. As others are witnessing, we continue to see TrickBot being dropped on most victims, and there is also clear evidence that FIN6 is leveraging initial access with Emotet to gain entry to victim networks (Emotet: An Analysis of TTPs). On an added note, secondary payloads and communications are typically pulled from dotted quads (http://12.229.155[.]122/kdx8NqIV7F3HAUSLk) in the sample we’re analyzing in this post.

Figure 7: The Emotet process tree.

Deep Dive on the Emotet PowerShell

How It Works

Initially, the OLE VBA object loads PowerShell and executes this giant blob:


From Any.Run Interactive Malware Service


Let’s start by analyzing the basics that we can see plainly. The (-w) option tells PowerShell to load the PowerShell window hidden from the user’s view (using the “hidden” windowstyle), and the (-en) option tells PowerShell to load a base64-encoded command. Loading encoded commands is a standard PowerShell feature, as it helps with commands that require “complex quotation marks or curly braces”. Even after we run a base64 decode in CyberChef, we see that the PowerShell command is still obfuscated:

Figure 8: Decoding the PowerShell payload with CyberChef.

Once we remove null characters (an artifact of PowerShell preferring UTF-16-encoded commands), we start to see what resembles a human-readable PowerShell script that is leveraging NET.WebClient() as a download cradle to pull down the Emotet stage 1 payload from one of the five websites defined in the $Zxnncpikcxlq variable in the script:


We can see from the Bromium Blog from April of this year that while the mode of obfuscation has changed from the multiple layers of base64 encoding and compression method (using Io.Compression.Deflatestream([Io.Memorystream][System.Convert]::Frombase64string)) to a simpler, base64-encoded direct command (using the -encodedcommand argument), it’s still fundamentally very similar underneath (down to the response length try/catch block).

The Role of the Download Cradle

The download cradle component of an attack chain serves as the lynchpin between the first and second stages of an attack. Most attackers in 2019 are more comfortable with a single command line argument than with a download-and-execute-shellcode approach. A cradle command takes input from the first stage of an attack and downloads and executes the second stage of the attack. Download cradles often leverage built-in operating system components like wscript or PowerShell, and in an attack chain such as Emotet, sit between the malicious document and the “real” malware payload. They also provide important capabilities, like built-in support for bypassing proxies using the OS proxy settings.

Download cradles are an often-overlooked portion of the attacker’s toolkit, but are very interesting from a detection and prevention perspective in that they give defenders some unique opportunities to disrupt the attack chain:

  1. Cradles are critical to the attack. If they don’t execute, the attacker does not gain control of the victim machine.
  2. Cradles are a “hard commit” for the attacker, exposing their technique and infrastructure to endpoint logging. There are only so many ways to skin a cat when downloading and executing code (this is one reason why we see so many attackers using encoding and/or compression for their cradles).
  3. When an attacker uses a cradle, they need to get a lot for a little. One line of code needs to decode/decompress arguments, execute them with the correct privileges locally, make a network request and properly process and execute a response.

When building out detection, there are multiple ways of detecting malicious activity, but the place to start should be in enabling command line and PowerShell logging and looking at network-based detection.

  1. In command line logging, look for abnormal parent-child process relationships, specifically with PowerShell or wscript (powershell, mshta, cmd, rundll32, wscript, wmiprvse, certutil or bitsadmin executables) being called from an abnormal parent process like winword, excel powerpnt, mspub, visio or outlook executables.
  2. In command line logging, look for PowerShell running in a hidden window (by way of the -hidden argument).
  3. In network monitoring tools, look for outbound web requests that use a default user agent, such as PowerShell’s net.webclient, or no user agent at all.
Figure 9: Image from @Carlos_Perez on twitter.

For a broader analysis of Emotet’s PowerShell techniques, please see Powershell Static Analysis & Emotet results. We’re big fans of Hatching’s capabilities— a great resource for Emotet analysis.

Future Outlook

While the Emotet team is currently on break, we take this time to ponder what their operation will look like in 2020. Typically, after malware authors/criminals take a holiday, we see a variety of new tools (re-tooling), infrastructure and techniques emerge. What’s not clear in the case of Emotet is the manner of retooling they might undertake and what their future operational tempo will look like. Leading up to this current downtime, Emotet was in a high-output operational mode, producing numerous mutations of the lure documents on multiple levels, rolling through command and control infrastructure and, overall, giving antivirus and security analysis tools a very hard time.

We feel that Emotet’s 2020 ops tempo and success levels will determine future changes to their tools and techniques. If they wish to maintain this high ops tempo, we expect to see further automation and abstraction across their tool chain (like TrickBot’s new PowerTrick utility recently reported by SentinelOne). Emotet has enjoyed high success levels with its practices thus far, so we don’t foresee any forcing function (antivirus detections, new mitigations, etc.) emerging that would cause them to shift methods in the new year.

News over the break has been rife with announcements of massive ransomware outbreaks at major organizations across the globe, and many of these are reported to be linked to Emotet-sourced infections. Emotet’s operation is netting substantial payouts and surely garnering ever-closer attention by the world’s law enforcement agencies. Will Emotet’s earnings continue at the same pace, or will they slow things down and maybe focus on tightening up shop to avoid law enforcement action? We can only hope they slip up with their OPSEC, or perhaps decide that vacations in Spain are very attractive around this time of year.

One thing we’re sure about is that their massive success and dominance over the crimeware landscape will likely continue.


In closing, whether you’re new to dealing with Emotet or an experienced analyst becoming reacquainted with an old adversary, hopefully this first in a series of blog posts has served as a good update to our previous posts, and as a useful deep dive into where to detect Emotet and its TTPs. In an attempt to anticipate or predict future development directions for the group of threat actors behind Emotet, we’re always striving to understand how they are using malware, what their technical capabilities are, which tools they are using, and how mature that toolset is. In future installments, we will continue this pursuit by taking a deeper look at how Emotet’s main agent and payloads are built and loaded, with a special focus on some of the methods being used to evade endpoint detection.


Common Communicators with No User Agent String (Potential FPs for the Network Detection Rule)

Microsoft Endpoints

Google Endpoints

Endpoint Security Agents

Connectivity Checks/Check ins

Proxy Auto Config (PAC) Requests


OCSP Checks


Additional Reading and References on Download Cradles:

Daniel Bohannon on Command Line Obsfuscation

Matthew Green on Powershell download Cradles

(vs wscript.exe)

Obligatory Emotet (and Friends/Payloads) IOC Dump 

Dropped Executable File


DNS Requests




DNS Requests






DNS Requests






DNS Requests







@Cryptolaemus1 and Carlos Perez

Back to top