Sysmon: How To Setup, Configure, and Analyze the System Monitor’s Events

6 min readOct 22, 2020

Sysmon, short for System Monitor, is a utility tool developed by Mark Russinovich, as part of the Sysinternals suite. The utility is registered in a Windows box as a system service and a device driver, which in sync, help log activities across the environment to the Windows Event log. Just a quick analysis of the logs generated by Sysmon can help identify malware, intrusions, and breaches within the network.

What Does Sysmon Do?

Due to active development of the project, newer artifacts and evidence sources are constantly being added to Sysmon’s capabilities. However, you can get a quick idea on how Sysmon can aid you in identifying anomalous activities by checking this short list of features:

Log process creation — command line, basic process information, parent process information, etc.
Network communications — connection’s source processes, IPs, ports, hostnames, etc.
Hashing process images — a hash of process image files is available in SHA1, MD5, SHA-256, or the IMPHASH format
DLL loading — identify the loading of DLLs along with their hashes
File modification — Identify changes in file creation times, a technique most commonly utilized by attackers to avoid detection
Kernel-mode malware, rule filtering based on False Positives, session identification, correlations, and much more!

How to Install Sysmon

Installing and configuring Sysmon is fairly easy. After acquiring the binaries from Microsoft’s own website — head towards the console in the same directory. First, let’s take a look at the options provided by the binary:

Sysmon64.exe -h

So, the installation of Sysmon as a service/driver required a configuration file. Though there’s a default setting in place, you can also pass your own configuration file to over-ride the default settings. We’ll get back to configuring the service later. For now, let’s install Sysmon with the defaults (from an administrative console):

Sysmon64.exe -i

The default configurations include:

Process images are hashed with SHA-1
Network connections are not monitored

If you don’t wish to configure the service, this was it. Sysmon’s service has already started logging events to its own channel and the driver will now be a boot-start driver. This helps the driver to capture events well before the actual boot-up of Windows or the event logging service.

Where are Sysmon’s Logs?

Sysmon creates its own event log channel under “Applications and Services Logs”. To open the channel and view the logs, you can:

Open “eventvwr.msc”
On the left panel, open up “Applications and Services”
Open “Microsoft”
Open “Windows”
Head to “Sysmon” and under that — the Operational log

If you’ve installed Sysmon’s service successfully, all logs should be updated there. For my own system, I see Event ID’s 1 and 5 for Process Creation and Process Termination the most. We’ll explore a few other Event ID’s later.

How to Configure Sysmon

Let’s start off by dumping the current configuration:

Sysmon64.exe -c

Here’s the output from the default configuration:

Current configuration:
 — Service name: Sysmon64
 — Driver name: SysmonDrv- HashingAlgorithms: SHA1
 — Network connection: disabled
 — Archive Directory: -
 — Image loading: disabled
 — CRL checking: disabled
 — DNS lookup: enabledNo rules installed

Now, let’s start building up a configuration file which we can use to modify our Sysmon installation.

First, let’s understand the dynamics of a configuration file. The file is supposed to start off with the Sysmon tag which has the schemaversion attribute in itself — this helps parse same versioned or older configuration files.

<Sysmon schemaversion="4.22">
   ...
</Sysmon>

You can retrieve the current version using the command:

Sysmon64.exe -? config

Next, under the Sysmon tag, we have Configuration Entries. These entries act like parameters which we normally provide to executables for add-on functionality. For example,

<HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms>

HashAlgorithms specify the hashing algorithms to be used for detection. Though there’s a larger list on Sysmon’s own documentation — you get the gist of it. This is the current structure of our configuration file:

<Sysmon schemaversion="4.22">
   <HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms>
</Sysmon>

Next, we have the EventFiltering tag which is where event filters go. For example, you want specific process creations to be included and the rest to be dropped at the collection point.

The Filter rules are written under the RuleGroup tag. They can contain the relation between the sub-nested tags and an optional name field. For example, for the File creation time event, we can filter for files which are in C:\Users or are an executable. Here’s how we’d write this filter:

<RuleGroup name=”” groupRelation=”or”>
   <FileCreateTime onmatch=”include”>
   <Image name=”T1099" condition=”begin with”>C:\Users</Image>
   <TargetFilename name=”T1099" condition=”end with”>.exe</TargetFilename>
 </FileCreateTime>
 </RuleGroup>

Just as we’ve used include to include such events, we can use the exclude value under the onmatch attribute to specify events which should be dropped.

Example — you wish to monitor registry events for changes to the CurrentVersion\Run registry key. You can do so using the RegistryEvent ID under your RuleGroup. Here’s how:

<RuleGroup name="" groupRelation="or">
    <RegistryEvent onmatch="include">
        <TargetObject name="T160, RunKey" condition="contains">CurrentVersion\Run</TargetObject>
    </RegistryEvent>
</RuleGroup>

This is how our sample configuration file looks like:

<Sysmon schemaversion="4.22">
<HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms>
<RuleGroup name="" groupRelation="or">
    <RegistryEvent onmatch="include">
        <TargetObject name="T160, RunKey" condition="contains">CurrentVersion\Run</TargetObject>
    </RegistryEvent>
</RuleGroup>
<RuleGroup name=”” groupRelation=”or”>
   <FileCreateTime onmatch=”include”>
   <Image name=”T1099" condition=”begin with”>C:\Users</Image>
   <TargetFilename name=”T1099" condition=”end with”>.exe</TargetFilename>
 </FileCreateTime>
 </RuleGroup>
</Sysmon>

Once done writing, let’s update our configuration using: (replace config.xml with your own file)

Sysmon64.exe -c config.xml

Pretty simple right? This is how you can manually construct a powerful configuration file based on your analysis and execution policies. Mind you, Sysmon isn’t a whitelisting tool or a HIDS agent — it’s simply an advanced logging service with built-in filtering. Your analysis is what’s going to matter after you’ve acquired Sysmon logs from an endpoint.

More detailed documentation is available at: https://docs.microsoft.com/en-us/sysinternals/downloads/Sysmon#introduction

Pre-build Sysmon Configurations

Luckily, defenders have done a tremendous job of keeping sysmon configurations up to date. One such amazing example is the sysmon-export.xml from SwiftOnSecurity.

It is highly customizable and supports updates from the latest version of Sysmon. Simply download and update your existing configurations to follow the template laid down by the person. That’s all.

Here’s the link: https://github.com/SwiftOnSecurity/sysmon-config

If you’d like to contribute to the community with your own rules or files, you can easily do so by making a similar open-sourced configuration file.

Sysmon Event IDs

Here’s a list of event IDs corresponding to the logs generated by Sysmon’s service:

Event ID 1: Process creation
Event ID 2: Process changed a file creation time
Event ID 3: Network connection
Event ID 4: Sysmon service state changed
Event ID 5: Process terminated
Event ID 6: Driver loaded
Event ID 7: Image loaded
Event ID 8: CreateRemoteThread
Event ID 9: RawAccessRead
Event ID 10: ProcessAccess
Event ID 11: FileCreate
Event ID 12: RegistryEvent (Creation and Deletion)
Event ID 13: RegistryEvent (Value set)
Event ID 14: Registry Event (Key and Value rename)
Event ID 15: FileCreateStreamHash
Event ID 16: ServiceConfigurationChange
Event ID 17: PipeEvent (Creation)
Event ID 18: PipeEvent (Connected)
Event ID 19: WmiEvent (WmiEventFilter activity)
Event ID 20: WmiEvent (WmiEventConsumer activity)
Event ID 21: WmiEvent (WmiEventConsumerToFilter activity)
Event ID 22: DNSEvent (DNS Query)
Event ID 23: FileDelete
Event ID 255: Error

Analysis of Sysmon Logs

Let’s take a look at one of the logs from the Sysmon log source. Here’s a sample one with my configuration updated as per SwiftOnSecurity’s config file:

Sysmon Event ID 3: Network Connection Detected

Review the information available with a single log in the bottom pane. This is great stuff! Default logging from Windows isn’t that advanced and Sysmon can easily fill those gaps.

If you can forward these logs to a SIEM or a centralized logging solution, that’d be even better.

Conclusion

That’s it for my article on setting up Sysmon. Feel free to play around with the configuration files and see what it does to your system’s logging capabilities. Perfecting the config file might require you to get a broad know-how of how your enterprise works. The lesser the noise, the more productive time your analysts spend hunting for threats.