Summary
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:
The payload may be staged at 5 possible URLs, typically compromised Word Press sites:
hxxps://www.studiomovil.com[.]mx/wp-content/erRpJAmInz/
Emotet Payload sites
hxxp://krzewy-przemysl[.]pl/wp-includes/yf1etsmsp_esqjtujn-589/
hxxp://laalpina[.]cl/sisi/cncXoJaqj/
hxxp://aysotogaziantep[.]com/wp-content/DSovUnSbnf/
hxxp://www.noshnow.co[.]uk/ybzew/wMaxwSMC/
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:
C:\Users\<USERNAME>\<PROCESSNAME>
The initial 191.exe process pretty much just loads several 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:
C:\Users\<USERNAME>\AppData\Local
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:
HKEY_USERS\<USERSID>\software\microsoft\windows\currentversion\run
/v wimprogram
Summary
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.
References
https://security-soup.net/analysis-of-a-new-emotet-maldoc-with-vba-downloader/
https://www.virustotal.com/gui/file/d07bbf9636c223b83dfe333c0428b41b909c19321e5f208bb805a2869cb358d5/detection
https://app.any.run/tasks/e9834a30-eb21-4468-a08d-096b49ddd3a8/
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
Indicators of Compromise
d07bbf9636c223b83dfe333c0428b41b909c19321e5f208bb805a2869cb358d5
47159abdd9c8dc0962a3d9173002f47ff5438a27a24c3fcc21ba35550ba5923b
hxxps://www.studiomovil.com[.]mx/wp-content/erRpJAmInz/
hxxp://krzewy-przemysl[.]pl/wp-includes/yf1etsmsp_esqjtujn-589/
hxxp://laalpina[.]cl/sisi/cncXoJaqj/
hxxp://aysotogaziantep[.]com/wp-content/DSovUnSbnf/
hxxp://www.noshnow.co[.]uk/ybzew/wMaxwSMC/
190.106.97.230
186.4.172.5