Emotet, an Analysis of TTP’s: Part II For the Watch

Posted on by admin

Last post we took a deep dive into what can happen post breach with emotet. But with the return of emotet I think it also bears looking into detection and how the actor has changed their operation to better evade detection over time. To this end I’ll be covering the use of the Ossec fork Wazuh, which I prevously covered during the last round of activity from the emotet group.

The Setup

We are assuming that you have already built a wazuh server and have the wazuh endpoint agent deployed to your windows system. Check out the wazuh documentation if you are starting from scratch on a wazuh deployment. Like last time let’s start with installing sysmon on the windows system, the current version as of this writing is 10.41.

https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Since my last writing I have changed my preferred sysmon configuration from the SwiftonSecurity configuration to one tuned to the MITRE ATT&CK framework by Olaf Hartong called sysmon modular.

You can get the configuration here: https://github.com/olafhartong/sysmon-modular/blob/master/sysmonconfig.xml

Once downloaded install your preferred version of sysmon, I’ll choose the 64 bit version here with the sysmon modular config.

sysmon64.exe -accepteula -i sysmonconfig.xml

Next on your wazuh server add the following rules to your local_rules.xml file:

https://github.com/Hestat/ossec-sysmon/blob/master/local_rules.xml

This configuration should allow wazuh to pick up the key events from sysmon. (As a side note wazuh does not yet pick up all sysmon events, only events 1-15 are currently compatible with wazuh, will dive into that more another time)

Make sure you have your Windows endpoints in a Windows agent group and add the following to the group agent.conf file:

https://github.com/Hestat/ossec-sysmon/blob/master/windows-agent.conf

This should make sure you get Sysmon events as well as Windows Defender Anti-Virus Events.

The History

When Emotet was stalking around as of my last write-up, Fall/Winter 2018 it generally was using Microsoft Word macros to call directly to powershell, or cmd to powershell.

So you could write your detection to just inspect the parent child relationship. IE Word spawns cmd which spawns powershell. By all accounts Word should never perform this kind of activity.

Example of Process Tree of Late 2018 Emotet Execution

By the Spring the Emotet actors had moved to invoking WMI via system API’s lower than what tools like Sysmon track. However you could still look for other “tells” like WMI spawning powershell, or powershell writing executable files.

Example of Process Tree Early 2019

As well you could still extract the macro’s and their malicious powershell through tools like oledump, and olevba.

Powershell found in Emotet doc using Olevba around April 2019

Once found you can deobfuscate the powershell using tools like Cyberchef and partial execution in a powershell interpreter to extract the download urls.

However after the Emotet actors went silent, besides a vacation its quite apparent they retooled, as all of these previous techniques to find the goods in their malicious documents ceased to work. They were still using the WMI method to excute, but the powershell that the macros executed was no longer present in the macro itself. They moved to using the trick of placing variables and the powershell code itself into hidden text boxes in the document itself. (big shout out to Ryan Campbell who we saw first report this).

Emotet Word Doc Circa Sept 2019

Switch to design mode, or open using Libre Office and you notice something that wasn’t there before.

What happened is they started to place variables and the powershell code itself into hidden text boxes in the document making things like oletools useless to extract IOC’s or other useful information.

But I came here for detection

Ah yes back to the original point. While our wily emotet actors have changed up their tactics we can still catch them at execution. Whether it be like last year with looking for Word spawning powershell or cmd, or this year inspecting the patterns in their powershell execution itself. For this go around we are going to use the indicators pulled together by Florian Roth of the Sigma project.

We will adjust it for our wazuh rule here:

And in action you can expect to see the following:

Enable the slack integration and get those sweet sweet alerts to your mobile.

Now you should be able to learn when a system has been infected via emotet, next time we’ll go over how to use Office 2016 GPO policy to prevent emotet execution.

Have questions find me on twitter @laskow26