So if you talk to most infosec professionals I think you find most would agree that malware goes in and out of fashion, back in 2016 ransomware was hot, at the end of 2017 cryptominers were everywhere. Today I don’t think many would disagree that this year has been the year of Emotet and its associated branches of malware laced documents.
Emotet by itself is often only a vehicle for further exploitation of the affected system. Lets break down a basic Emotet campaign:
Generally the pattern begins with a document getting to an endpoint. Most commonly this is by email. The document type is often different with examples of Office .doc, Excel .xls, and XML documents. Regardless of the type these documents all contain code within them, often VBA scripts that once opened and executed will run powershell commands to get a stage 2 package.
Now stage 2 can be a variety of packages with variations with often other malware being delivered at this stage like Trickbot and Ursnif. The types have ranged from banking trojans to email stealers, and even good old ransomware.
While Antivirus can be effective against known strains of Emotet, the malware often gets tweaks daily to make its way into an environment. And you can find funny ways that it may find a backdoor into your environment, maybe your email gateway is blocking these attachments, but what happens when a user checks their personal gmail from the work machine and opens a malware laced document?
The key it seems at this point to catching these events is to trigger on the processes spawned from documents. To this end I’m going to walk through using the OSSEC host based intrusion detection software package to catch Emotet and maldocs in the act.
I am specifically using a fork of the OSSEC project known as Wazuh, as it has a great integration with and ELK(Elasticsearch, Logstash, Kibana) stack and a great curated ruleset. However to get our Emotet detection in place we will be using some additional tooling and some custom rules.
First we will need to get the Sysmon tool installed on the Windows endpoint.
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
Sysmon is a very capable and extensible log monitoring addition to traditional Windows Event Logs. Specifically I recommend using this software with the following configuration, provided by the Swiftest of Infosec.
https://github.com/SwiftOnSecurity/sysmon-config
Once you download the sysmon package and the configuration xml file you can install with the following on the command line(make sure files are in the same folder and apply regular sysmon or sysmon64 as required):
sysmon.exe -accepteula -i sysmonconfig-export.xmlI will be assuming that you are already using OSSEC or Wazuh. If you want to know how to install these you’d better check out this place for installation.
Wauzh: https://documentation.wazuh.com/current/installation-guide/index.html
Now to properly detect the malware we need to make sure that your Windows endpoints are reporting their Sysmon Log events. I use a Wazuh group to keep my Windows machines in a consolidated configuration. we need to make sure the following is in the windows agent.conf file:
<localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile>
With the agents reporting back the logs add the following rules to your local_rules.xml file located here:
/var/ossec/etc/rules/local_rules.xml
The rules to add are in the xml file at the github repo linked below:
https://github.com/Hestat/ossec-sysmon
Now make sure all systems have the proper reboots in place and we are ready to detect some malwares!
Here’s an how it breaks down. (With a sample from November courtesy of Brad at malware-traffic-analysis.net)
On opening the document we are prompted to enable editing as well as content.
Now once this is done we can see what was kicked off from the document if we check the Sysmon logs which will have collected the new process information, which is invisible to the user.
Now let’s pivot back to our Wazuh Kibana interface to see the alerts triggered for this event.
Here we have isolated just to our client we are investigating and can already see Sysmon alerts present.
The one with the highest priority is the trigger for cmd.exe spawning from a Word Doc. Looking at the raw log for the alert we see the following.
Now often in these style of malicious document’s we see not just one process spawned but multiples, we can track the other processes from that time period, and in this case find a powershell process to get some additional information and IOC’s (Indicators of Compromise).
We can then look a little further at the alerts for powershell network connections to confirm the connections.
Then confirm the IP data with virustotal, or other open source intel.
So there you have it, detecting maldocs using OSSEC and Sysmon. In the future I plan on extending the ruleset so check back at the github repo from time to time and see what new detection’s we have in store. As always hit me up on twitter @laskow26 if you have any questions.