Detecting Emotet using Windows Event Logs


Emotet is a trojan malware that steals sensitive information. Many companies are concerned that their users will get infected by this malware and might leak sensitive information.

A customer I’m currently helping with their Security Operations Center (SOC) asked me, how they can detect Emotet in their environment.

Here’s what I came up with – maybe it helps you detecting Emotet or similar malware in your environment, too!


Please only analyze malware in a lab and ONLY if you know what you are doing. I’m taking no responsibility for anything you do, following my tutorial. Microsoft also does not.


You can detect Emotet by using Sysmon and PowerShell Module & ScriptBlock Logging, correlating events 13, 4103 and 4104. Happy hunting!

What is Emotet?

Emotet is a malware, which injects code into the network stack of the victim computer to allow the attacker to steal sensitive information from it’s victim.

Most of the time, a document is sent to the victim, containing malicious Macros. When the user enables the Macros for the document, a PowerShell script is being executed and starts it’s bad work.

More information on Emotet and on how to protect against it, can be found in this article:

Building the Lab

What am I focusing on for detecting Emotet?

As Emotet (and similar malware) follows similar steps to infect its victims, I’m looking for the following two characteristics:

  1. Macro usage is enabled/Editing a document is enabled
  2. PowerShell is being executed

Lab Prerequisites

Some malware authors don’t want their malware to be analysed, so they detect if their malware is running in a virtual machine. To avoid a different malware behavior during our analysis, we use a hardware client PC with the following software installed.

  • Software installed on the victim PC:
    • Office
    • Sysmon
    • PowerShell 5.0+

As we don’t want to risk our logs being altered or deleted and since we’d like to correlate them in an easy way, we need to set up a Windows Event Collector Machine.

Getting started

As many malware change their behavior when started on a virtual machine, I use a hardware client PC as a victim machine. This machine needs to be prepared before the malware can be executed on this client.

1. Victim PC: Install MS Office

In many cases, Emotet is received as an attachment over E-Mail. Once the victim opens it, it requires that Macros will be enabled to run the malware. Therefore Office needs to be installed on our victim machine.

If you don’t have an Office installation for your victim machine, you can test Office 365 a month for free after registration. Be sure to NOT enter your sensitive data on the victim device. 😉

2. Victim PC: Install Sysmon

To detect that Macros were enabled, we need Sysmon installed on the system having the following configuration, saved in Sysmon-DetectMacros.xml:

<Sysmon schemaversion="4.00">
<RegistryEvent onmatch="include">
<TargetObject condition="contains">
Security\Trusted Documents\TrustRecords

To enable the sysmon config, run:

sysmon.exe -i detect_macros.xml

3. Victim PC: Enable PowerShell Logging

As Emotet executes PowerShell just after being executed, we want to search for PowerShell usage. Therefore we enable ScriptBlock Logging, Module Logging and Transcription.

Before enabling Module and ScriptBlock Logging, it can be useful to increase the log file size of the Microsoft-Windows-PowerShell/Operational log, as it can hold by default only 15MB logs.

  • Enable ScriptBlock Logging
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
      • EnableScriptBlockLogging = 1
  • Enable Module Logging
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging
      • EnableModuleLogging = 1
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames
      • * = *
  • Transcription
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription\
      • EnableInvocationHeader = 1
      • EnableTranscripting = 1
      • OutputDirectory = <path_to_directory>

When you enable PowerShell Transcription, no additional logs will be written to the event log, but files will be created. How to work with those transcription files, you can read in the blog article PowerShell ♥ the Blue Team.

4. Setting up a Log Collector

As setting up a log collector is out of scope of this article, I won’t describe how to set up a log collector.

If you’d like to use a free log collection solution, you might want to have a look at Windows Event Forwarding (WEF):

But there are also a lot of other log collector solutions on the market – e.g. Azure Log Analytics (which you can also try for free), Kibana, and many more. However – for this blog article we use Splunk as our log collector software.

5. Forwarding agent

Configure the forwarding agent for the log collector of your choice (see 4. Setting up a Log Collector) and configure which events need to be forwarded.

If you need to define the location of the logs, they can be found here:

  • Sysmon Log
    • %SystemRoot%\system32\winevt\logs\Microsoft-Windows-Sysmon%4Operational.evtx
  • PowerShell Log
    • %SystemRoot%\system32\winevt\logs\Microsoft-Windows-PowerShell%4Operational.evtx

Which events to monitor?

Sysmon Events

To test which events will be created by Sysmon when a Macro is enabled, I use a non-infected Excel file.

The Log we need to monitor for Sysmon Events is the following:

  • Microsoft > Windows > Sysmon > Operational

When an Excel file is downloaded from a non-trusted network (e.g. the internet), before editing or enabling Macros, it has to be enabled for editing. When doing so, three different events will be generated:

  • Enable for Editing
    • Registry Value Set: Event ID: 1
    • Registry Value Set: Event ID: 12
    • Registry Value Set: Event ID: 13

Whenever a Macro is enabled for the first time, Event ID 13 is generated. The same Event ID will also be generated if a document was opened, for which the Macros were already enabled earlier.

  • Enable Macros
    • Registry Value Set: Event ID: 13

So it seems that the event with Event ID 13 is the connecting event for Macro usage, we should monitor.

PowerShell Events

The Log we need to monitor for PowerShell Events is the following:

  • Microsoft > Windows > PowerShell > Operational

While having Module Logging and ScriptBlock Logging enabled, when a PowerShell command/script is run (depending of the type), one of those events will be triggered:

  • Module Logging
    • Event ID 4103
  • ScriptBlock Logging
    • Event ID 4104

If you’re interested in the output generated (e.g. for analyzing purposes), have a look at the PowerShell transcripts, you configured earlier.

You might also want the transcripts to appear parsed in your log collection for better searchability (and again: PowerShell ♥ the Blue Team – have a look at it!).

And now the fun starts

Emotet sample

Before we can start we need an Emotet sample. Do not extract or run it on your production PC – do it only (if you know what you are doing!) on a lab PC, which is designated to be infected. 😉

Now we can start to trigger our malware:

As we open the word document and enable it, the malware starts immediately and does it’s work. When we have a look at the process structure via Procexp, we can see the following calls:

  • WinWord.exe
    • conhost
      • powershell.exe

Our events are being created, which can now be evaluated in the attached log collector.

Correlating Sysmon and PowerShell Events

As we configured two different indices for sysmon and powershell events, we have to merge them. We developed this simple query to detect Emotet (or at least a Macros which are showing a similar behavior):

(index=sysmon EventCode=13) OR (index=powershell EventCode=4103 OR EventCode=4104) | transaction startswith="EventCode=13" maxspan=10m | table _time, ComputerName, EventCode, Image, TargetObject

I selected 10 minutes (maxspan=10m) as time range from the enabling macro event until the PowerShell code is executed. Please be aware that some malware might just “sleep” a bit longer to avoid detection. Adjust this time range to your business needs, as this is just an example.

Detect Emotet in your domain

To build this as a detection mechanism for your whole domain, you have to follow these simple steps:

  1. Deploy Sysmon on each client
  2. Enable PowerShell logging on each client
  3. Collect logs
  4. Create alarms

Enable PowerShell logging via Group Policy

As I only demonstrated how to enable PowerShell logging via registry, here’s how it’s done via Group Policy:

Administrative Templates > Windows Components > Windows PowerShell

Turn on Module Logging

Configure all modules to be logged:

Turn on ScriptBlock Logging

Turn on PowerShell Transcription

I hope you liked my little tutorial on how to detect Emotet and other Macro & PowerShell based malware and that it helps you to keep your environment a little safer!

Happy detecting and Emotet hunting!