Quick Post: Host Artifacts from a Recent Emotet Infection


If you’ve been following malware threats and/or the information security happenings of the past couple weeks in general, then you are likely aware that Emotet, everyone’s favorite malware downloader, has returned to active spamming operations. There has been a ton of great coverage on many aspects of its return to active campaigns.

Shameless plug: this included my own coverage from last week analyzing the newest style maldocs leveraging the classic MS Word > VB Macro > PowerShell infection chain.

I don’t want to rehash work that’s already been done, but instead focus on some Emotet details that haven’t received a lot of attention. One aspect that has appeared to be lacking is content that delves into the various host artifacts that Emotet generates on disk from a successful infection. One reason for this could be that a lot of the artifacts haven’t really changed all that much from Emotet’s previous runs in early to mid 2019. Despite this, I think it’s a worthwhile exercise to take a look at an infected host and identify the some basic artifacts such as running process, installation/data paths, and persistence mechanisms. Let’s go!

Delivery and Infection Chain

For this scenario, the infected host we will look at here was infected by a user opening an Emotet Word document and enabling macro content.

  • SHA256: d07bbf9636c223b83dfe333c0428b41b909c19321e5f208bb805a2869cb358d5

Please check out more details in my earlier post on how this works. The following resources will have some additional information about the source file.

Long story short, a PowerShell process runs a base64 encoded command that pulls down the initial Emotet binary:

PowerShell Parent Process

The payload may be staged at 5 possible URLs, typically compromised Word Press sites:

Cyber Chef to decode and extract IOCs


Emotet Payload sites

Host Artifacts

Ok, so when performing some dynamic analysis on a host where malware has executed, we want to focus on the three areas that I mentioned earlier:

  • Running Process (or terminated processes)
  • Installation Directories (or where the binaries are written to)
  • Persistence Mechanisms (Registry keys, Windows Services, Scheduled Tasks, Start-up Items, etc.)

A lot of this work can be done from the standard Windows command line, or PowerShell. I tend to use a little of both. YMMV.

Emotet Processes and Data Paths

With Emotet, there are typically 2 different processes of interest. When the core Emotet binary executes, it runs as a randomly named 3-digit EXE. In this case, by the time I had analyzed the host, this process was long since finished, but I was able to jump back into the logs with Process Monitor to identify the initial process. Sysmon or commercial endpoint detection and response (EDR) products would have similar capability.

As expected we see the typical 3-digit EXE kick off the execution chain from the following location:


The initial 191.exe process pretty much just loads several DLLs:

bunch o’ DLLs

The next step for Emotet also appears to have remained essentially unchanged as a second process is created and a the executable is written to:

the second 2nd EXE

When it writes itself to this directory, it also changes its name. The name for the second binary is a two-part string that is pulled from a word bank included in a config file (in this case “wim”+ “program”). This also is the typical modus operandi for Emotet operations.

Emotet Persistence

Up until this point, the infection appears relatively typical and I do not see any significant divergence from Emotet operations. But one interesting and different feature of the infection I observed on this host was the persistence mechanism. While historically I have seen this achieved with a Service, this looks to not be the case (at least in this instance). I checked this host and saw no sign of Service, scheduled task, or start-up items. However, I did find a registry run key in the user profile hive:

/v wimprogram
registry run key for persistence


So that’s it, a quick look at pertinent host artifacts form a recent Emotet run. It is somewhat surprising that not too much appears to have changed with all of the time the threat actors had to re-tool. That being said, there are other notable features of recent campaigns that are innovative, including fresh email phishing lures leveraging cultural events (Snowden book), a new packer for the malware, and the splitting of the command and control infrastructure into a third epoch.



Indicators of Compromise


Leave a Reply

Your email address will not be published. Required fields are marked *