Sysmon configuration: include and exclude filtering explained

A Sysmon configuration file is XML that tells the tool which events to record. Each event type has a filter that uses include or exclude rules. Exclude rules win over include rules, rules on the same field combine with OR, and rules on different fields combine with AND, unless you set a rule group.

The skeleton

A config has a schema version, optional settings such as hash algorithms, and an event filtering section. The Microsoft documentation shows an example along these lines:

<Sysmon schemaversion="4.82">
  <HashAlgorithms>*</HashAlgorithms>
  <EventFiltering>
    <NetworkConnect onmatch="include">
      <DestinationPort>443</DestinationPort>
      <DestinationPort>80</DestinationPort>
    </NetworkConnect>
    <NetworkConnect onmatch="exclude">
      <Image condition="end with">iexplore.exe</Image>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

This logs connections to ports 80 and 443 except those from a process ending in iexplore.exe. The schema version is separate from the Sysmon program version.

How the logic works

• onmatch include: only events that match are recorded.
• onmatch exclude: everything is recorded except events that match.
• You may use both for one event type, and exclude matches take precedence.
• Several rules on the same field behave as OR. Rules on different fields behave as AND.
• A rule group lets you set the combination type explicitly, to and or or.

Conditions

Each field comparison has a condition. The default is is. Others include contains, contains any, contains all, excludes, begin with, end with and image, which matches an image path by full path or just the file name. All are case insensitive.

You can also name a rule, which makes Sysmon report which rule caused an event to be logged. That helps when you are tuning.

Commands

The documentation lists the install, update and uninstall switches: install with the i option and optional config file, update with the c option, print the schema with s, uninstall with u.

A safe rollout plan

1. Start from a maintained, community reviewed config rather than a blank file, and read it.
2. Test on a few machines. Watch event volume per host per hour.
3. Tighten noisy filters. Add exclusions only with a comment saying why.
4. Roll out in rings: pilot, a small group, then everyone.
5. Keep the file in version control and require review for changes.
6. Alert on event 16, which records a configuration change, so tampering is visible.

Common mistakes

Excluding too broadly, such as ignoring everything from a folder an attacker could write to. Turning on image load or process access with no filters. Forgetting that the config reloads automatically when changed in the registry, so a bad push takes effect fast.

Sizing the volume

Before a rollout, estimate events per host per day from the pilot, then multiply by host count and retention. Process creation is usually the most valuable and manageable event. Network, image load and process access are the ones that need filters. If your log platform charges by volume, this arithmetic decides what you can afford to keep.

Keeping the config honest

Review the exclusions every quarter. An exclusion added during an incident can outlive the reason for it. Put a comment and a date beside each one, and delete those nobody can explain.

Quick check

Sources

• Microsoft Learn: Sysmon

Last reviewed: 19 October 2026.