SIEM 201 — What is Sysmon

by | Nov 25, 2020 | Cybersecurity, Information Technology, InfoSec, SIEM, SIEM 200 series, TL;DR; | 0 comments

In this post I’ll explain what is Sysmon, how to install it and how to use it to detect important pattern.

For this post, I assume you’ve read my SIEM 100 series where I explain the basics of I’ll be using the stack I created in this series to demonstate what to do.

Sysmon is a tool provided by Microsoft in the Sysinternals suite:  Like they explain:

System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.

Sysmon can be used to detect suspicious and malicious events that would normaly not be visible in the default Windows logs. You can see all it can do and it’s corresponding event IDs here: and select Sysmon from the list.  


Note: There is a TL;DR; section at the end of this section. First download Sysmon here: Once downloaded, extract the content. In the Explorer window that opened after the extraction, open a PowerShell window as Administrator (FIle -> Open Windows PowerShell -> Open Windows PowerShell as administrator). For me, the working directory is “C:\Users\User\Downloads\Sysmon”. Next, we’ll use a config file that reduces the noise sent to the SIEM and that adds some useful logs not enabled by default. The detail of the config file we’ll use can be found at In the PowerShell window opened as Administrator, run the command:

Invoke-WebRequest -URI -OutFile sysmonconfig-export.xml

Now we simply need to install Sysmon giving it this config file. Always in the PowerShell window opened as Administrator, run the command:

./sysmon.exe -accepteula -i .\sysmonconfig-export.xml

If you already had Sysmon installed, you can update the configuration with the following command:

./sysmon.exe -c .\sysmonconfig-export.xml

Now that we installed Sysmon, if you didn’t have it installed before, we need to restart Winlogbeat so it now sends the logs from Sysmon. Always in the PowerShell window opened as Administrator, run the following command:

Restart-Service winlogbeat

That’s it, you should now be receiving the Sysmon logs.


Putting all the commands together for easy installation, in a PowerShell window as Administrator, run the following commands:

cd C:\Windows\Temp\
Invoke-WebRequest -URI -OutFile
Expand-Archive .\
cd .\Sysmon\
Invoke-WebRequest -URI -OutFile sysmonconfig-export.xml
./sysmon.exe -accepteula -i .\sysmonconfig-export.xml
./sysmon.exe -c .\sysmonconfig-export.xml
Restart-Service winlogbeat

How it can be used

The number of detection patterns that Sysmon allows are to numerous to talk about in one post, so I’ll only do a quick summary. I’ll use this site as a reference (select “Sysmon” once on the page): Sysmon can log every process creation that happens in Windows. The processes that actually get logged depends on the config file we gave. With the config we gave in this post, we only exclude some known noisy processes so most of the activity we do can be logged. The event ID for a process creation is 1, as we can see in the website. So if we go in our account and search for “event.code: 1” (without the quotes), we can see all the process creation logs:

Sysmon event code 1 search result

In this picture, I added relevant fields in the columns, here is what they mean:

  • winlog.event_data.Image: This is the name of the process created
  • winlog.event_data.CommandLine: This is the command line that was used when creating the process
  • winlog.event_data.ParentImage: This is the Parent process; the process that created the current process creation log
  • winlog.event_data.User: This is the user that created the process

If we look at all the available fields, we can see some interesting one:

Hint: Remember the website, it’s really useful! I might write a blog about it one day, but there is plenty of information online if you want to know more.Note: A process hash can be changed really easily, so don’t rely solely on these to detect bad behavior. Although they can be really useful for basics attacks, they are not perfect. So at this point, we could create an alert to detect specific process name or parent process name, or look at the hashes of the process that was created. For example, you could alert when you detect the creation of PsExec by looking at the process name, or when PsExec is used with a specific utility (like PowerShell), etc.


Sysmon is one of the best tool for a Blue Teamer. It’s usage will come back a lot. Altough it can’t do everything, it’s one of the best tool in your toolset. In my next blog posts, I’ll often reference to it. I suggest you read more on Sysmon and the patterns you can detect with it. You can also read on it’s configuration file format; I gave you a decent but basic configuration file and it could be enhanced and adapted to your context.


If you like my blog and my posts, please consider donating!


Leave a Reply

%d bloggers like this: