Understanding Sysmon configuration files

Sysmon configuration files define what telemetry Sysmon records and what it ignores. Because Sysmon captures detailed, low-level system activity, configuration design directly determines the usefulness, performance, and investigative value of the resulting data. 

This article explains the structure of Sysmon configuration files, how filtering rules are evaluated, and how to reason about configuration design when deploying Sysmon as a built-in Windows feature. 

Configuration files 

Configuration files define the behavior of Sysmon by specifying global settings and event filtering rules. They make it easier to deploy a preset configuration and to filter captured events. 

In built-in Sysmon, configuration is applied through Windows configuration mechanisms and evaluated at runtime. Configuration updates take effect immediately and persist across reboots. 

Basic configuration structure 

A simple Sysmon configuration XML file looks like this: 

<Sysmon schemaversion="4.82">
  <!-- Capture all hashes -->
  <HashAlgorithms>*</HashAlgorithms>   
  <EventFiltering>   
    <!-- Log all drivers except if the signature -->  
    <!-- contains Microsoft or Windows -->     
    <DriverLoad onmatch="exclude">   
      <Signature condition="contains">microsoft</Signature>
      <Signature condition="contains">windows</Signature> 
    </DriverLoad>        
        <!-- Do not log process termination -->   
       <ProcessTerminate onmatch="include" /> 
       <!-- Log network connection if the destination port equals 443 -->  
       <!-- or 80, and process isn't InternetExplorer -->  
    <NetworkConnect onmatch="include">  
      <DestinationPort>443</DestinationPort>  
      <DestinationPort>80</DestinationPort>  
    </NetworkConnect>      <NetworkConnect onmatch="exclude">   
       <Image condition="end with">iexplore.exe</Image>    
    </NetworkConnect>    
  </EventFiltering> 
</Sysmon>   

This example demonstrates: 

  • Global configuration entries 

  • Event-specific filtering 

  • Combined include and exclude rules to balance visibility and noise 

Schema version 

The configuration file contains a schemaversion attribute on the <Sysmon> tag. This version is independent of the Sysmon binary version and allows Sysmon to correctly parse older configuration files. 

Schema versioning: 

  • Preserves compatibility across Sysmon updates 

  • Allows new capabilities to be added safely 

  • Ensures older configurations continue to function  

Configuration entries

Configuration entries define global Sysmon behavior. They influence how events are enriched or handled rather than which event types are generated.

Entry Value Default Description
ArchiveDirectory String Sysmon Directory at the root of each volume where deleted files are archived when ile-delete archiving is enabled. The directory is protected by a system ACL.
CheckRevocation Boolean True Controls whether digital signature revocation checks are performed when validating signed binaries.
CopyOnDeletePE Boolean False Preserves deleted executable (PE) files by copying them to the archive directory.
CopyOnDeleteSIDs Strings None Comma-separated list of account SIDs for which deleted files are preserved.
CopyOnDeleteExtensions Strings None Process names for which deleted files are preserved.
DnsLookup Boolean True Enables reverse DNS lookup for network events to resolve IP addresses to host names.
DriverName String Auto-generated Specifies the name used for the Sysmon driver and service images.
HashAlgorithms Strings None Hash algorithms applied to files. Supported values include MD5, SHA1, SHA256, IMPHASH, or * (all).

Configuration entries control event enrichment and handling, not event selection.

Configuration schema and event definition

Sysmon configuration is based on a well-defined schema that describes:

  • Supported event types

  • Available fields for filtering

  • Field data types

This schema defines what configuration files can express and ensures consistent parsing across Sysmon versions.

Some configuration entries enable functionality (such as hashing or enrichment), but events must still be explicitly enabled and filtered under <EventFiltering>.

The following example shows the schema definition for the RawAccessRead event type:

<event name="SYSMON_RAWACCESS_READ" value="9" level="Informational" template="RawAccessRead detected" rulename="RawAccessRead" version="2">   
  <data name="UtcTime" inType="win:UnicodeString" outType="xs:string"/>   
  <data name="ProcessGuid" inType="win:GUID"/>   
  <data name="ProcessId" inType="win:UInt32" outType="win:PID"/>   
  <data name="Image" inType="win:UnicodeString" outType="xs:string"/>   
  <data name="Device" inType="win:UnicodeString" outType="xs:string"/>   
</event>

This illustrates that:

  • Each event exposes a fixed set of fields

  • Only schema-defined fields can be used in filtering rules

  • Field types constrain valid filtering conditions

Event filtering

Event filtering controls which Sysmon events are logged. Each event type has its own filter tag under <EventFiltering>.

ID Tag Event Description
1 ProcessCreate Process create
2 FileCreateTime File creation time
3 NetworkConnect Network connection
4 n/a Sysmon service state change (not filterable)
5 ProcessTerminate Process terminated
6 DriverLoad Driver loaded
7 ImageLoad Image loaded
8 CreateRemoteThread Remote thread creation
9 RawAccessRead Raw disk access
10 ProcessAccess Process accessed
11 FileCreate File created
12–14 RegistryEvent Registry modifications
15 FileCreateStreamHash File stream created
16 n/a Sysmon configuration change (not filterable)
17–18 PipeEvent Named pipe activity
19–21 WmiEvent WMI activity
22 DNSQuery DNS query
23 FileDelete File delete (archived)
24 ClipboardChange Clipboard content change
25 ProcessTampering Process image change
26 FileDeleteDetected File delete (logged)
27–29 FileBlock / FileExecutable Executable file events

Include and exclude rules

Each event filter specifies an onmatch attribute:

  • include – only matching events are logged

  • exclude – all events are logged except matching ones

Exclude rules always take precedence over include rules.

Rule logic and conditions

Rules reference event fields and apply conditions to them.

  • Same-field rules behave as OR

  • Different-field rules behave as AND

Condition Description
is Exact match
contains Substring match
begin with / end with Prefix or suffix
image Path-aware image matching
contains any / contains all Multi-value matching
excludes* Negative matching
less than / more than Lexicographical comparison

Named rules

Rules can be named to provide audit context:

<NetworkConnect onmatch="exclude"> 
  <Image name="network iexplore" condition="contains">iexplore.exe</Image> 
</NetworkConnect>

Named rules improve investigation clarity and maintainability.

Rule groups

Rule groups allow explicit control over logical rule combination:

<EventFiltering> 
  <RuleGroup name="group 1" groupRelation="and"> 
    <ProcessCreate onmatch="include"> 
      <Image condition="contains">timeout.exe</Image> 
      <CommandLine condition="contains">100</CommandLine> 
    </ProcessCreate> 
  </RuleGroup> 
  <RuleGroup groupRelation="or"> 
    <ProcessTerminate onmatch="include"> 
      <Image condition="contains">timeout.exe</Image> 
      <Image condition="contains">ping.exe</Image> 
    </ProcessTerminate>         
  </RuleGroup> 
  <ImageLoad onmatch="include"/> 
</EventFiltering>

Rule groups allow:

  • Precise behavioral matching

  • Different logic per event type

  • Reduced rule duplication

Configuration change visibility

Whenever the Sysmon configuration is updated, Sysmon generates a configuration change event, providing auditability and change tracking.

Design principles

Effective Sysmon configurations:

  • Start broad and refine over time

  • Exclude known benign activity

  • Preserve investigative context

  • Avoid over-specific rules

Once telemetry is excluded, it cannot be recovered retroactively.

What configuration files do not do

Configuration files:

  • Do not detect threats

  • Do not generate alerts

  • Do not classify behavior

  • Do not replace SIEM or EDR logic

They define what evidence exists, not how it is interpreted.

Summary

Sysmon configuration files are the foundation of effective Sysmon deployments. Understanding schema structure, filtering semantics, rule logic, and real-world patterns is essential to building configurations that scale and retain long-term investigative value.

  • Last updated on