Sysmon Configuration for Threat Detection

Sysmon configuration is the foundation almost every Windows detection rests on — and the most common reason rules never fire is that the underlying telemetry was never collected or tuned. Sysmon (System Monitor) is a free Sysinternals tool that logs rich, granular endpoint events: process creation with command lines and hashes, network connections, driver loads, LSASS access, DNS queries. Configure it well and your detections have data; configure it badly and you either drown in noise or miss the event. This guide is the practical configuration and the event IDs that matter.

Sysmon is the data source behind the rest of darkpwn’s Windows detections — LSASS credential dumping, NTLM relay, and LOLBins — and it is the practical prerequisite for the detection engineering workflow on Windows.

What is Sysmon and why does it matter?

Sysmon is a Windows system service and driver that records detailed security events to the event log, far beyond what Windows logs by default. A single process-creation event (ID 1) includes the full command line, the parent process, the user, and file hashes — everything a detection needs to spot a malicious pattern. Multiply that across network connections, driver loads, and process-access events, and you have the raw material for behavioral detection.

The catch is configuration. Sysmon with no config logs little; Sysmon with a naive “log everything” config buries the SIEM in noise and cost. The art is a tuned config that captures the security-relevant minority and excludes the predictable majority.

Which Sysmon event IDs should you collect?

These cover the overwhelming majority of behavioral detections. Collect them well before adding the rarer event types — depth on the core beats breadth on the noise.

How to configure Sysmon well

Do not hand-write a config from scratch. Start from a maintained community baseline and tune it:

1. Adopt a baseline — sysmon-modular (Olaf Hartong) or the SwiftOnSecurity config. Both are ATT&CK-aware and filtered.
2. Deploy in a pilot ring and measure event volume per ID before going wide.
3. Tune by exclusion — drop the noisiest predictable sources (signed Microsoft network beacons, browser image loads, known service accounts) while keeping security-relevant events.
4. Forward to the SIEM with the core event IDs above, and confirm field parsing.
5. Review monthly — the noisiest sources drift; refine the exclude filters.

A minimal illustrative slice of a tuned config:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <RuleGroup groupRelation="or">
      <!-- Always capture access to LSASS -->
      <ProcessAccess onmatch="include">
        <TargetImage condition="end with">lsass.exe</TargetImage>
      </ProcessAccess>
      <!-- Capture driver loads (BYOVD), exclude known-good signers elsewhere -->
      <DriverLoad onmatch="include"><Signed condition="is">false</Signed></DriverLoad>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

How a tuned Sysmon config produces detections

Once the telemetry flows, detections write themselves against it. A process-creation event (ID 1) carries the command line, so a LOLBin or encoded-PowerShell rule has the data it needs:

title: Encoded PowerShell via Sysmon Process Creation
id: 3d1f8c52-darkpwn-illustrative
status: stable
logsource:
  product: windows
  category: process_creation   # Sysmon Event ID 1
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: [' -enc ', ' -EncodedCommand ']
  condition: selection
falsepositives:
  - Some legitimate deployment scripts (allowlist by parent/path)
level: medium
tags:
  - attack.t1059.001

How to validate your Sysmon deployment

1. Generate benign versions of key behaviors (a dump of notepad.exe, an encoded PowerShell echo) and confirm the matching event IDs appear.
2. Confirm the events reach the SIEM with fields parsed (command line, hashes, parent).
3. Check event volume per ID against your baseline; investigate any source flooding.
4. Run an Atomic Red Team test and confirm the relevant Sysmon events are captured.

Common Sysmon mistakes

• No config or default config. Captures almost nothing useful.
• Log-everything config. Explodes SIEM cost; gets tuned to death.
• Not forwarding/parsing fields. Events exist locally but the SIEM can’t query them.
• Set-and-forget. Noise sources drift; configs need monthly tuning.

Sysmon configuration checklist

1. Adopt a maintained baseline (sysmon-modular or SwiftOnSecurity).
2. Pilot it and measure event volume per ID before wide deployment.
3. Capture the core IDs: 1, 3, 6, 7, 10, 11, 12–14, 22.
4. Tune by exclusion to drop predictable noise; keep security-relevant events.
5. Forward to the SIEM and confirm field parsing.
6. Validate with Atomic Red Team that key behaviors produce events.
7. Review the noisiest sources monthly and refine filters.
8. Treat the config as a logsource gate for every new Windows detection.

The takeaway

Sysmon configuration is the data foundation of Windows detection: adopt a tuned community baseline, collect the core event IDs, exclude predictable noise to control cost, and treat the config as the logsource gate for every rule. Telemetry first, rules second. Continue with the detection engineering workflow, LOLBins detection and BYOVD attack detection (malicious driver-load events), or browse the full Detection Engineering pillar.