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.

Events land in the Microsoft-Windows-Sysmon/Operational channel. Two fields deserve particular attention because they enable analysis the native logs cannot. ProcessGuid is a globally unique identifier that stays stable even when PIDs are recycled, which is what makes reliable process-tree reconstruction possible during an investigation. IMPHASH is a hash of the executable’s import table; because it varies with what a binary does rather than its exact bytes, it often clusters variants of the same malware family that differ in SHA256.

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.

The WMI trio (19–21) is worth calling out as an unusually good trade. WMI event subscriptions are a durable, fileless persistence mechanism that survives reboots and is invisible to most file-based scanning, yet legitimate WMI subscription creation is rare in most estates. Low volume, high signal, and almost nobody collects it.

What do you need before deploying Sysmon?

Four prerequisites, and skipping any of them produces telemetry that exists locally and helps nobody.

1. A deployment mechanism. GPO startup script, Intune, SCCM, or your configuration management tool. Sysmon installs with -i and accepts a configuration file; updates use -c.

2. Forwarding to the SIEM. Windows Event Forwarding or your agent must be subscribed to the Microsoft-Windows-Sysmon/Operational channel specifically. This is a distinct subscription from the standard Security log and is regularly forgotten.

3. Field parsing at the destination. Events must arrive as structured fields, not a single XML blob. A rule matching CommandLine cannot work if the SIEM stored the whole event as text.

4. A volume budget. Decide what you are willing to spend before you deploy, then tune to fit. Reversing that order is how organizations end up disabling the feed entirely.

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>

Which baseline should you start from?

Choose SwiftOnSecurity if this is your first deployment and nobody owns tuning yet; choose sysmon-modular when you have a named owner and the budget to absorb higher volume in exchange for broader coverage. Do not hand-roll unless you are filling a documented gap in one of them.

Where the volume actually goes

Before tuning, measure. The distribution is consistent enough to predict the shape, though not the absolute numbers, which depend entirely on your estate:

• Event ID 7 (image load) is nearly always the single largest contributor, often by a wide margin. Every process loads dozens of DLLs. Tune this first.
• Event ID 3 (network connection) dominates on servers, especially anything running a web tier or a chatty agent.
• Event ID 1 (process creation) is moderate on workstations and can spike enormously on build servers and CI agents, which spawn processes constantly.
• Events 6, 10, 17–21, 25 are comparatively rare and carry high signal — the best value in the entire schema.

Derive your exclusions from your own 7-day measurement, not from a published config’s comments. Two estates with the same headcount can differ by an order of magnitude depending on their EDR, their software deployment tooling, and how many build agents they run.

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 do you detect tampering with Sysmon itself?

An attacker who understands your telemetry will try to remove it, and this is the blind spot most Sysmon deployments never close. There are two distinct detections and you need both.

The loud path is a service or configuration change, which Sysmon itself logs:

index=windows source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
  (EventCode=4 OR EventCode=16)
| eval signal=case(
    EventCode=4,  "Sysmon service state changed",
    EventCode=16, "Sysmon configuration changed")
| stats count min(_time) as first max(_time) as last by host, signal, User
| where count > 0

The quiet path is the one that matters more. An attacker who unloads the driver or stops the service produces no further events — including no tamper event. The only detection is the absence of expected telemetry:

let lookback = 7d;
let silence_threshold = 2h;
let expected =
    Event
    | where TimeGenerated > ago(lookback)
    | where Source == "Microsoft-Windows-Sysmon"
    | summarize LastSeen = max(TimeGenerated) by Computer;
expected
| where LastSeen < ago(silence_threshold)
| extend SilentFor = now() - LastSeen
| project Computer, LastSeen, SilentFor
| order by SilentFor desc

Set silence_threshold from your own data: measure the longest normal reporting gap per host class over 30 days and set the threshold just above the 99th percentile. Workstations that sleep overnight need a different threshold from always-on servers, so segment by host class or you will generate an alert storm every morning.

Which false positives will you actually see?

Sysmon itself does not alert, but the rules built on it do, and the noise is predictable enough to plan for.

The last row is the one to implement carefully. Suppressing Event ID 16 outright — because “our tooling changes the config” — deletes the only signal that an attacker rewrote your configuration to blind a specific detection. Correlate against your change management system instead: an unmatched config change is exactly the alert you want.

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.
5. Verify coverage, not just function. Query for distinct reporting hosts and compare against your asset inventory. Deployment gaps are far more common than configuration bugs, and a host that never had the agent generates no alert about it.
6. Test the tamper detections. Stop the service on one lab host and confirm both the Event ID 4 alert and the silence detection fire within their expected windows.

Step 5 is the one that changes programs. Most teams discover, when they run it for the first time, that somewhere between a handful and a substantial fraction of their estate never received the agent — build servers stood up outside the standard image, contractor laptops, and the domain controllers someone excluded during a performance investigation years ago.

Sysmon, Event ID 4688, or EDR — which do you actually need?

These are complementary, not competing, and the common mistake is assuming an EDR deployment makes Sysmon redundant. It does not, for a specific reason: EDR telemetry is generally exposed through the vendor’s console and query language on the vendor’s retention terms, while Sysmon puts raw, portable events in your SIEM under your retention policy and your query language.

The practical answer for most estates: enable 4688 with command-line auditing everywhere as a floor, since it costs nothing and covers hosts that cannot take an agent; deploy Sysmon wherever you can for detection engineering depth and portable retention; and keep EDR for what neither provides — blocking, isolation, and response. On a domain controller or a high-value server, running all three is a reasonable posture rather than a redundant one.

The one scenario where Sysmon is genuinely non-negotiable is when your detection content must be portable. Rules written against Sysmon fields convert cleanly through Sigma to any backend; rules written against a specific EDR’s schema do not survive a vendor change, and vendor changes happen.

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.
• Forgetting the Sysmon channel subscription. The most common forwarding bug.
• No coverage monitoring. You cannot see the hosts that never reported.
• No tamper or silence detection. An attacker disables the sensor and nothing fires.
• Suppressing Event ID 16 globally. Deletes the signal that your config was rewritten.
• 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 — plus 17–21 and 25 where affordable.
4. Tune Event ID 7 first; it is usually the largest cost line.
5. Tune by exclusion to drop predictable noise; keep security-relevant events.
6. Forward the Microsoft-Windows-Sysmon/Operational channel and confirm field parsing.
7. Commit the config to version control; require review to change an exclusion.
8. Alert on Event IDs 4 and 16, correlated against change management.
9. Build an agent-silence detection with a threshold derived per host class.
10. Reconcile reporting hosts against asset inventory monthly to find coverage gaps.
11. Validate with Atomic Red Team that key behaviors produce events.
12. Review the noisiest sources monthly and refine filters.
13. 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, monitor the sensor for tampering and silence, 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) and detecting process injection (CreateRemoteThread telemetry), or browse the full Detection Engineering pillar.