Sysmon Configuration: Build a Config That Actually Detects

Sysmon is the single most valuable free upgrade you can give a Windows machine. Out of the box, Windows tells you very little about what programs actually did. Sysmon records process creation with full command lines and hashes, network connections, registry changes, file creation and more. But it is only as good as its configuration, and a bad one will either miss attacks or drown you in noise.

This is Part 11 of 30 in the Blue Team Learning Path. In Part 10 you built a lab and installed Sysmon with a quick setup. Now we learn what the configuration file really does, so you can tune it yourself.

Key takeaways

• Sysmon logs nothing useful until you give it a configuration file that says what to record.
• Start from a trusted community config, then tune it against your own baseline.
• Rules use include and exclude lists. Exclude noisy, known-good behaviour, and never exclude broad folders attackers can write to.
• Change one thing at a time, and watch event volume after every change.

What Sysmon is and where it logs

Sysmon, short for System Monitor, is a free Windows tool in the Sysinternals suite. It installs as a service and a driver, and it keeps running across reboots. Its events are written to the log called Microsoft-Windows-Sysmon/Operational, which in Event Viewer lives under Applications and Services Logs, Microsoft, Windows, Sysmon, Operational. The full reference is on the Microsoft Sysmon page.

Think of it as a second, richer log source that sits alongside the normal Security log we covered in our Windows event logs primer. The Security log tells you who logged on. Sysmon tells you what ran, what it connected to and what it changed.

Install it and load a configuration

Run an elevated command prompt in the folder where you extracted Sysmon. The documented syntax is:

sysmon64 -accepteula -i sysmonconfig.xml
sysmon64 -c sysmonconfig.xml
sysmon64 -c
sysmon64 -u

The first line installs the service with your config and accepts the licence. The second updates the configuration of a running Sysmon. The third prints the current configuration, which is useful when you inherit a machine. The last one uninstalls it. After any change, confirm the active config with the third command, and check that event ID 16 (a configuration change) was logged.

Pick a starting configuration

Writing a configuration from scratch is slow, and there is no reason to start with a blank file. Two community projects are widely used:

• SwiftOnSecurity/sysmon-config is a single, well-commented template described by its author as a starting point with default high-quality event tracing. It installs with sysmon.exe -accepteula -i sysmonconfig-export.xml.
• olafhartong/sysmon-modular is a library of small rule modules, grouped by event type, with ATT&CK metadata, plus a tool that merges the modules you pick into one configuration. It also offers pre-built profiles.

Both repositories say the same thing in different words: treat the result as a starting point, review it, and tune it before wide deployment. We follow that advice below.

The structure of a configuration file

A Sysmon configuration is XML. At the top you set global options, such as which hash algorithms to record. Below that, an EventFiltering section holds one rule group per event type. Here is a small teaching example, not a production config:

<Sysmon schemaversion="REPLACE_WITH_YOUR_SCHEMA">
  <HashAlgorithms>sha256</HashAlgorithms>
  <EventFiltering>
    <RuleGroup name="Process creation" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Image condition="end with">powershell.exe</Image>
        <Image condition="end with">cmd.exe</Image>
        <CommandLine condition="contains">-enc</CommandLine>
      </ProcessCreate>
    </RuleGroup>
    <RuleGroup name="Network" groupRelation="or">
      <NetworkConnect onmatch="exclude">
        <Image condition="is">C:\Windows\System32\svchost.exe</Image>
      </NetworkConnect>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Replace the schema placeholder with the one your Sysmon version expects. You can print the schema with sysmon64 -s. Four ideas from this example matter most.

• onmatch=”include” means “log only events that match these rules”. onmatch=”exclude” means “log everything except events that match”. An empty exclude list therefore logs every event of that type.
• Conditions such as is, contains, begin with and end with decide how a value is compared.
• RuleGroup with groupRelation controls whether the rules inside combine with “or” or “and”.
• Order of thinking matters: decide what you want to see, then write the narrowest rule that gets it.

Include or exclude: choosing a strategy

There are two schools of thought. An include-based config logs only behaviour you already consider interesting. It is quiet and cheap, but it can miss anything you did not think of. An exclude-based config logs everything and removes known noise. It is louder, but it keeps evidence for attacks you never predicted, which matters in incident response. Many teams use exclude rules for process creation and include rules for noisy events such as image loads.

This links back to the Pyramid of Pain: a config built only around known-bad hashes sits at the bottom, while rich process creation and command-line data lets you build detections at the top.

Read the events you are producing

Do not trust a config you cannot see working. After installing, generate a test action and read the event. In PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 20 |
  Select-Object TimeCreated, Id, Message | Format-List

Open a few events and confirm they contain the fields you expect, such as the full command line, the parent process and the hashes. Our Get-WinEvent guide shows how to filter these events by ID and parse their XML.

Tune with a baseline

Tuning is where most of the value is. A repeatable method:

1. Measure first. Run the config for a day or two on a representative machine and count events per ID. Group by process image to see the top talkers.
2. Find the noise. Look for software that generates thousands of identical events, such as backup agents, browsers refreshing or monitoring tools.
3. Exclude narrowly. Exclude the exact signed binary at its exact path, not a whole folder.
4. Re-measure. Confirm volume dropped and attack simulations still appear.
5. Record the reason. Put a comment in the XML next to every exclusion saying why it exists.

The danger is excluding too much. An attacker only needs to name a tool after a trusted process, or run from a folder you excluded, to disappear. Never exclude a path where a standard user can write files.

Which events to turn on first

You do not need every event on day one. A sensible order, which Part 12 explains in detail, is:

1. Process creation (event 1): the highest-value event. It records what ran, with what arguments, started by which parent.
2. Network connections (event 3): shows which process called out, which is how you tie traffic to a program.
3. File creation (event 11) and registry changes (events 12 to 14): persistence and dropped payloads, but filter them hard.
4. DNS queries (event 22): a cheap way to see which domains each process asked for.
5. Process access (event 10) and remote threads (event 8): credential theft and injection signals, which need careful rules to avoid noise.

Add the next group only after you are comfortable with the volume of the previous one.

A short test routine

After every configuration change, run the same five harmless actions on your lab Windows machine and confirm each one is logged. For example: start a PowerShell window and run a command with a long argument, open a connection to a website from a browser, create a new text file on the desktop, add a harmless value under a test registry key, and resolve a domain name. Then read the matching events. If one is missing, your last edit broke something, and because you keep the config in Git, you can compare the two versions and find the line.

This routine also teaches you what normal looks like. When you later study ATT&CK techniques as described in Part 6, you will already know which events a technique produces on your own system, and you will write rules from evidence instead of guesses.

Manage the config in Git

Keep your configuration in version control, and update machines by pushing the file and running sysmon64 -c. When a detection breaks or volume spikes, you can see exactly which edit caused it. Pair this with the test routine from your lab: after every change, run a few harmless actions and confirm the events still appear.

Performance and storage

Sysmon is built to be light, but events are not free. Image load and file-create events can be very frequent. Check the size of the Sysmon log and raise its maximum size if it wraps in less than a day, then forward events to your SIEM so they survive. Part 14 shows how Wazuh collects them, and Part 13 shows how to search them.

Common pitfalls

• Installing without a config. You get little useful data and a false sense of coverage.
• Copying a config blindly. Community configs reflect someone else’s environment.
• Excluding by folder. Attackers can drop files in any writable folder.
• Forgetting hashes. Without hashes you lose the quick pivot to threat intelligence.
• Never retesting. A syntax slip can silently disable a rule group.
• Leaving the log too small. Old evidence is overwritten before anyone reads it.

Frequently asked questions