9 min read

SYSMON: Augmenting Windows Logs

SYSMON: Augmenting Windows Logs
Photo by Markus Spiske / Unsplash

What is Sysmon?

By default, Windows provides event collection abilities in 3 main channels which are System, Application and Security.

Sysmon, part of the Windows Sysinternals tools, complements and augments the Windows logging capabilities by generating more types of logs. It does not replace any event logs.

Sysmon is a Windows system service and device driver. It is a lightweight monitoring tool. It runs in the background, even after you restart your computer, to maintain persistence and keep track of and record system activities in the Windows event log.

It is a powerful tool that will come in handy in many scenarios, and specifically “incident response”. It is used alongside your EDR solution to add an additional layer of security.

💡
Sysmon is also available on Linux platforms

Where are Sysmon logs stored?

Symon logs are stored in the Windows Event Log and specifically under: Applications and Services Logs/Microsoft/Windows/Sysmon/Operational

Installing Sysmon

Step 1: Prepare the configuration file

Before installing Sysmon, you will need to have a configuration file ready. Microsoft does provide a fantastic config file to get started with and can be downloaded from:

The XML file can be customized as needed to add or remove unneeded logs.

Step 2: Install Sysmon

In this step, we download and install Sysmon using the configuration file from step 1.

Sysmon can be downloaded from the official website:

Extract the package and copy the configuration file into the same directory:

Launch PowerShell or CMD with administrator privileges and navigate to the Sysmon directory. For example, if you extracted the Sysmon package into C:\temp\sysmon, you will need to install it using the following commands:

cd C:\temp\sysmon

C:\temp\sysmon> .\Sysmon.exe -accepteula -i -c sysmonconfig-export.xml
  • -accepteula: Automatically accept the EULA without prompting the user
  • -i: will install the service
  • -c: sysmonconfig-export.xml will implement the supplied config file
💡
Other parameters to use might include the -h to specify the type of hash algorithms to use

To access the complete list of parameters to install Sysmon, run the setup file using:

  • sysmon.exe -s | more
  • -s will print the schema and contains the parameters in the first section of the output

During installation, Sysmon will leverage the “wevtutil” command line to install the event manifest. It might be a good idea to alert your SOC team to avoid any false positives as “wevtutil” is used by malicious actors to perform activities like clearing events.

Step 3: Verify installation is successful

Open services and verify that you can see the “Sysmon” service

Sysmon also creates registry entries under

  • HKLM\SYSTEM\CurrentControlSet\Services\<driver name>\Parameters

If you used the default driver name, then look for:

  • Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sysmon

Uninstall Sysmon

Run the below command

  • sysmon64 -u

Also supports the [force] parameter:

  • sysmon64 -u force

Update the Sysmon configuration file

To update or load a new Sysmon configuration file, use the -c parameter:

  • Sysmon64.exe -c <new_configuration_file>.xml

The Sysmon configuration is stored as a binary blob in the registry under:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters\Rules

Viewing Sysmon Logs

After installing Sysmon, you can start seeing event logs related to Sysmon under

  • Applications and Services Logs/Microsoft/Windows/Sysmon/Operational

In the above screenshot, you can immediately identify how valuable Sysmon is in generating useful events such as file and process creations.

What types of events does Sysmon generate?

Sysmon generates a wide variety of logs. At the time of this post, there are 29 event types and 1 Sysmon error event. These events can be categorized as per the list below:

💡
The full list of logs can be found in the official documentation: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#overview-of-sysmon-capabilities
💡
An in-depth breakdown can be found in the BlackHills post: https://www.blackhillsinfosec.com/a-sysmon-event-id-breakdown/
  • Event ID 1: Process Creation
    • Logs detailed information about newly created processes, including the command line, unique process GUID, and hash of the process file.
  • Event ID 5: Process Terminated
    • Reports when a process ends, including the ProcessGUID, ProcessId, and UTC time.
  • Event ID 10: Process Access
    • Logs when one process opens another, often a precursor to actions like credential theft or memory reading. It should be used selectively to avoid excessive logging.
  • Event ID 25: Process Tampering
    • Detects process-hiding techniques such as process hollowing or image tampering.
  • Event ID 2: File Creation Time Change
    • Logs when a file's creation time is modified, useful for spotting backdoor installations.
  • Event ID 11: File Create
    • Captures file creation or overwriting operations. Useful for monitoring autostart locations and temporary directories.
  • Event ID 15: FileCreateStreamHash
    • Logs the creation of a named file stream and its hash, useful for identifying files with metadata like Zone.Identifier.
    • To read the Zone.Identifier of a file, run:
      • notepad <filename>:Zone.Identifier
    • To check if a file contains ADS:
      • Get-Item -Path "file.txt" -Stream *
💡
Alternative Data Streams (ADS) can be used for legitimate and malicious activity. They can be used for storing file metadata or malicious scripts. For example, browsers store "Zone.Identifier" stream to identify that a file was downloaded from the internet. More info here: https://github.com/trustedsec/SysmonCommunityGuide/blob/master/chapters/file-stream-creation-hash.md
  • Event ID 23: File Delete (Archived)
    • Logs file deletions and saves a copy in the ArchiveDirectory.
  • Event ID 26: File Delete Detected
    • Logs file deletions without saving the deleted file.
  • Event ID 27: File Block Executable
    • Logs and blocks the creation of executable files (PE format).
  • Event ID 28: File Block Shredding
    • Detects and blocks file shredding operations.
  • Event ID 29: File Executable Detected
    • Captures the creation of new executable files (PE format).
  • Event ID 3: Network Connection
    • Logs TCP/UDP connections, including process details, source/destination IPs, ports, and IPv6 status. Disabled by default.
  • Event ID 22: DNS Query
    • Captures DNS queries executed by processes, including both successful and failed attempts.

Driver and Module Events

  • Event ID 6: Driver Loaded
    • Logs when a driver is loaded, along with its hash and signature information.
  • Event ID 7: Image Loaded
    • Captures modules loaded into processes, including their hashes and signature information. Should be configured carefully to avoid excessive logging.

Thread and Memory Events

  • Event ID 8: CreateRemoteThread
    • Detects threads created in one process by another. Commonly used by malware for code injection.
  • Event ID 9: RawAccessRead
    • Logs when a process reads directly from the drive using low-level access. Often used for data exfiltration.

Registry Events

  • Event ID 12: Registry (Create/Delete)
    • Logs registry key and value creation or deletion. Useful for monitoring registry-based autostarts.
  • Event ID 13: Registry (Value Set)
    • Logs changes to registry values, including the written data for certain types.
  • Event ID 14: Registry (Rename)
    • Captures registry key and value renaming operations.

Pipe Events

  • Event ID 17: Pipe Created
    • Logs the creation of named pipes, often used by malware for interprocess communication.
  • Event ID 18: Pipe Connected
    • Logs when a named pipe connection is established between a client and a server.

WMI Events

  • Event ID 19: WmiEventFilter
    • Logs when a WMI event filter is registered, often used by malware for execution.
  • Event ID 20: WmiEventConsumer
    • Captures registration of WMI consumers, including details about the destination.
  • Event ID 21: WmiEventConsumerToFilter
    • Logs the binding of a WMI consumer to a filter.

Service and Configuration Events

  • Event ID 4: Sysmon Service State Changed
    • Logs changes in the Sysmon service state (start/stop).
  • Event ID 16: Service Configuration Change
    • Logs updates to the Sysmon configuration, such as filtering rule changes. A word of warning, if the configuration is made directly to the registry, then this event is not triggered. However, event 13 is logged showing a registry key modification.

Clipboard Events

  • Event ID 24: Clipboard Change
    • Captures changes in system clipboard content.

Error Events

  • Event ID 255: Error
    • Logs errors occurring in Sysmon, such as performance issues, bugs, or security violations.

Controlling logs generated by Sysmon

Sysmon can be configured to filter/collect events by modifying the configuration file (XML).

To view the current configuration file loaded by your Sysmon instance, run the command:

  • sysmon -s

You should get an output similar to the below:

Logging Cheat Sheet

https://www.malwarearchaeology.com/cheat-sheets

🛡️Additional Insight

Do I need Sysmon if I have an EDR solution?

EDR provides powerful capabilities for blocking and protecting against malware. Sysmon, on the other hand, will improve your telemetry capabilities, giving you in-depth details and event logging. Sysmon does not offer any detection and response capabilities. Both EDR and Sysmon work hand in hand to leverage your threat hunting capabilities.

How do I protect Sysmon from malicious users?

Sysmon doesn't analyze the logs it creates or try to hide itself from attackers. It runs as a protected service, making it harder for regular users or programs to interfere with it.

When attackers compromise a system, they might look for Sysmon instances and try to deactivate or completely disable it using bypass and injection-based attack tools like SysmonEnte to hide their tracks. Microsoft has addressed these concerns in version 15. The Sysmon team has implemented “Protected Process Light” (PPL) to protect from process injection-based attacks. You can read more here: https://codewhitesec.blogspot.com/2022/09/attacks-on-sysmon-revisited-sysmonente.html

Sysmon offers interesting tactics to make it harder to detect but keep in mind that these are obfuscation techniques and thus do not guarantee foolproof security.

Change Sysmon Driver Name

As a start, administrators can rename the Sysmon file and service during installation by:

  • Renaming the Sysmon.exe executable to the desired driver name. The filename should NOT exceed 8 characters. The filename and driver name entries should be different when using the below command.
  • Installing the driver using: <new filename>.exe -i sysmonconfig-export.xml -d <new driver name>.exe

The name can also be modified via the registry

Other Techniques To Detect Sysmon

  • The Eventlog Channel remains the same to avoid breaking SIEM solution integration. The entry can be found under
    • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Sysmon/Operational
  • The EULA entry under the registry path:
    • Computer\HKEY_CURRENT_USER\SOFTWARE\Sysinternals
  • Service description will remain as “System Monitor service” and can be changed via a script

Monitor Event IDs to Protect Sysmon

Thanks to tier zero’s blog for a well-rounded list of events to keep a close eye on.

  • Event ID 1: Process creation, command-line containing sysmon64 -u and fltMC.exe unload SysmonDrv
  • Event ID 4: Sysmon service state changed
  • Event ID 11: FileCreate - monitor executable file creation if you have Event ID 27: FileBlockExecutable enabled
  • Event ID 12,13,14: Sysmon RegistryEvents
  • Event ID 16: Sysmon Service Configuration Change
  • Event ID 255: Config Monitoring Thread, Description: "Failed to send message to update configuration"
  • System Event ID 7000: Service Control Manager, Description: "Sysmon service failing to start"
  • System Event ID 1: File System Filter 'SysmonDrv' unloaded successfully.

Source: https://tierzerosecurity.co.nz/2024/02/27/microsoft-system-monitor.html

I have installed Sysmon.. now what?

Deploy a Sysmon configuration file:

After installing Sysmon, administrators will be asking how to move forward and start collecting logs that actually matter.

A good place to start is by using any of the predefined configurations files listed below:

  • Swift on Security: (https://github.com/SwiftOnSecurity/sysmon-config)
    • This is one of the most popular and widely-used Sysmon configurations. It provides a high-quality default configuration that serves as an excellent starting point for many organizations4. Key features include:
      • Extensive commenting to explain each rule
      • Balanced approach to logging, capturing important events while minimizing noise
      • Regular updates to address new threats and techniques
  • Olaf Hartong's Sysmon-Modular (https://github.com/olafhartong/sysmon-modular)
    • This configuration takes a modular approach, allowing users to customize their Sysmon deployment more granularly
  • Bobby Tablez's FT-Sysmon-Config (https://github.com/bobby-tablez/FT-Sysmon-Config)
    • This configuration is focused on detecting current and active malware TTPs. It features:
      • Modifications to the SwiftOnSecurity config based on threat research
      • Additional logging for potentially malicious activities in specific directories and registry locations

Deploy a SIEM solution to start collecting and practicing:

There are many ways to configure a small lab and start your Sysmon event collecting adventure.

A simple outline to prepare a lab:

  • Download a Windows 10/11 ISO (Free from Microsoft website)
  • Download Wazuh
  • Use Virtual Box to prepare a Wazuh and Windows 11 instance
  • Install the Sysmon service and Wazuh agent on Windows 11
  • Start collecting events in Wazuh

References and Further Reading