In this post I’ll explain what is Sysmon, how to install it and how to use it to detect important pattern.
Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/
For this post, I assume you’ve read my SIEM 100 series where I explain the basics of Logz.io. 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: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon. 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: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx?i=j and select Sysmon from the list.
Installation
Note: There is a TL;DR; section at the end of this section. First download Sysmon here: https://download.sysinternals.com/files/Sysmon.zip 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 https://github.com/SwiftOnSecurity/sysmon-config. In the PowerShell window opened as Administrator, run the command:
Invoke-WebRequest -URI https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile sysmonconfig-export.xmlNow 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.xmlIf you already had Sysmon installed, you can update the configuration with the following command:
./sysmon.exe -c .\sysmonconfig-export.xmlNow 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.
TL;DR;
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 https://download.sysinternals.com/files/Sysmon.zip -OutFile Sysmon.zip
Expand-Archive .\Sysmon.zip
cd .\Sysmon\
Invoke-WebRequest -URI https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -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): https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx?i=j 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 ultimatewindowssecurity.com website. So if we go in our Logz.io account and search for “event.code: 1” (without the quotes), we can see all the process creation logs:
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:
- winlog.event_data.Hash.MD5: This is the MD5 of the current process that was created. This is useful to compare against a list of known malicious MD5. For example, we can look at this file tested in Virus Total: https://www.virustotal.com/gui/file/fb55414848281f804858ce188c3dc659d129e283bd62d58d34f6e6f568feab37/details. The process here is mimikatz, which is a really popular tool used by hackers. It’s MD5 is “2c527d980eb30daa789492283f9bf69e”, so if we were to see this hash in a process creation log, we would know it’s this specific mimikatz process.
- winlog.event_data.Hash.SHA256: This is the same as the MD5, but instead of a MD5, it uses SHA256 to hash the process. It can be used the same way.
- winlog.event_data.Hash.IMPHASH: This is similar to the last 2 fields, but a bit different. This is more advance so I won’t get in the details, but if you’re curious, there is a good article here: https://medium.com/@malcomvetter/defeating-imphash-fb7cf0183ac
Hint: Remember the website virustotal.com, 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.
Conclusion
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.
Feel free to leave your comment down here for any questions or comments.
