Sysmon Deployment and Configuration: Designing a High-Fidelity Telemetry Pipeline

You inherit a Windows domain. There is no EDR budget this quarter. The SOC is drowning in 4688s that lack command lines, and the last time someone dumped LSASS on a domain controller, nobody knew for six weeks. This is the situation Sysmon was built for, and it is also the situation where a bad Sysmon config makes things worse, not better. Deploying Sysmon is easy. Deploying Sysmon so it produces a signal a human analyst can actually work with, without burning your log license by lunchtime, is a design job.

This walkthrough builds that pipeline end to end against a lab: install, configure, tune, forward to SIEM, write Sigma rules, and then attack the box with Atomic Red Team to prove each detection fires. If you cannot demonstrate the detection working after emulating the technique, you do not have the detection.

1. What Sysmon Is (and What It Is Not)

Sysmon is a Sysinternals tool: a Windows service backed by a kernel driver that subscribes to ETW providers and writes structured, high-value events into a dedicated log channel. It is not installed by default. It does not analyze events. It does not block anything (with the narrow exception of the new FileBlock* families, EIDs 27 and 28). It does not alert. It is a sensor. Everything downstream, correlation, alerting, response, is your SIEM’s job.

Two architectural details matter before you install anything:

• Log channel: Microsoft-Windows-Sysmon/Operational under Applications and Services Logs in Event Viewer.
• ETW Provider: Microsoft-Windows-Sysmon, GUID {5770385f-c22a-43e0-bf4c-06f5698ffbd9}. This is what Sigma’s logsource maps to.

Windows 11 introduced a built-in Sysmon capability. It does not coexist with standalone Sysmon: you must uninstall one before enabling the other. For lab work and most enterprise deployments today, standalone Sysmon v15.x is still the right answer, and Sysmon 15+ runs as a Protected Process Light (PPL), which materially raises the bar for tampering.

2. The Complete Event ID Taxonomy

Sysmon v15.2 emits 29 event IDs. Learn them in groups, not as a flat list. When you triage an alert, you are almost always chasing the ProcessGuid correlation chain from one of these groups to another.

The single most useful field across all of these is ProcessGuid. Unlike ProcessId, which Windows reuses, ProcessGuid is unique within a domain and lets you pivot from an EID 1 to every EID 3, 7, 8, 10, and 11 that process later produces. Build your SIEM correlations on it.

3. Installation and Deployment at Scale

Start on a single lab VM with the standalone install. Use Olaf Hartong’s sysmon-modular for anything beyond a five-minute demo; SwiftOnSecurity’s sysmonconfig-export.xml is a solid single-file starter but is easier to outgrow than to extend.

# Grab Sysmon v15.x and sysmon-modular
Invoke-WebRequest https://download.sysinternals.com/files/Sysmon.zip -OutFile Sysmon.zip
Expand-Archive .\Sysmon.zip -DestinationPath .\Sysmon
git clone https://github.com/olafhartong/sysmon-modular.git

# Build a merged config from the modular repo (uses their merge script)
cd .\sysmon-modular
.\Merge-SysmonXml.ps1 -AllRuleFiles -AsString | Out-File ..\sysmonconfig.xml -Encoding utf8
cd ..

# Install
.\Sysmon\Sysmon64.exe -accepteula -i .\sysmonconfig.xml

# Confirm
Get-Service Sysmon64
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 5 |
    Select-Object TimeCreated, Id, LevelDisplayName

You should see EID 4 (service state change, state: Started) followed by EID 16 (config load). If those two are not the first entries in the log, the service did not start with your config. That is your smoke test.

Live-updating the config after install does not require a service restart:

.\Sysmon\Sysmon64.exe -c .\sysmonconfig.xml

Every successful reload fires another EID 16. Alert on EID 16 events where the source is not your deployment pipeline. That is your tamper canary.

For fleet deployment, the pragmatic path is a GPO-enforced scheduled task that runs a small PowerShell wrapper on boot. The wrapper checks whether Sysmon is installed and at the current config hash, and reinstalls or updates as needed. Store Sysmon64.exe and sysmonconfig.xml on SYSVOL. SYSVOL is the right choice because it is already replicated across domain controllers and its ACLs restrict write access to Domain Admins by default. If a helpdesk user can write to the config share, everything downstream is theatre.

4. XML Configuration Deep Dive

The config schema is simple, but the filtering logic bites people. Structure:

<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>
  <CheckRevocation/>

  <EventFiltering>
    <RuleGroup name="ProcCreate_Include" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Rule name="T1059.001_PowerShell_Encoded" groupRelation="and">
          <Image condition="end with">\powershell.exe</Image>
          <CommandLine condition="contains any">-enc;-EncodedCommand;FromBase64String</CommandLine>
        </Rule>
      </ProcessCreate>
    </RuleGroup>

    <RuleGroup name="ProcCreate_Exclude" groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="is">C:\Program Files\Windows Defender\MsMpEng.exe</Image>
        <ParentImage condition="is">C:\Windows\System32\svchost.exe</ParentImage>
      </ProcessCreate>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Two things to internalize:

1. onmatch="include" means log only if this rule matches. onmatch="exclude" means log everything except matches. Within a single event type, include and exclude are separate rule sets, both evaluated. If any include rule matches, the event is emitted (and tagged with RuleName). If any exclude rule matches, the event is dropped.
2. groupRelation="and" inside a <Rule> requires every condition to match. groupRelation="or" on the parent <RuleGroup> is what lets you stack multiple independent rules.

The name="" attribute on each <Rule> populates the RuleName field in the emitted event. Use ATT&CK IDs there: T1059.001_PowerShell_Encoded, T1003.001_LSASS_Access. When a SOC analyst opens the event, they get the technique ID for free.

<HashAlgorithms> is a knob people over-tune. Full-file SHA256 on every ImageLoad sounds thorough and burns CPU on servers that load thousands of DLLs. SHA256,IMPHASH on process create and driver load is enough for hunting and family clustering. IMPHASH in particular is the one you cannot get anywhere else, and it survives trivial repacks.

Rule ordering matters only within a single event type: the first matching rule wins for RuleName tagging, but filtering is evaluated across all rules. Keep the config commented, keep rule names ATT&CK-mapped, and version-pin it in git.

5. Tuning Strategy: Signal vs Noise

The noise problem is real. On a workstation, EID 13 (registry value set) can produce tens of thousands of events per hour if you do not filter. EID 22 (DNS) is worse. EID 7 (image load) is the runner-up. The correct approach is not “log less”; it is “log everywhere an attacker actually goes.”

Practical baseline for noise control:

• EID 13: exclude by default, then explicitly include autorun locations. Log HKLM\...\Run, HKLM\...\RunOnce, Image File Execution Options, AppInit_DLLs, Winlogon\Shell, service ImagePath writes, and Office Trust Records. Ignore the rest.
• EID 22: exclude the top 500 or so domains you know your fleet queries constantly (*.microsoft.com, telemetry endpoints, your own AD DNS names) and log everything else. Set an eye on newly registered domains, DGA-shaped names, and DNS-over-HTTPS bypasses.
• EID 7: exclude signed Microsoft DLLs loading from C:\Windows\System32\ into signed Microsoft parents. Then aggressively log unsigned DLLs loaded from user-writable paths.

Attackers live in user-writable directories. Non-negotiable inclusion paths: %AppData%, %LocalAppData%\Temp, %ProgramData%, %Public%, HKCU\Software\Microsoft\Windows\CurrentVersion\Run, and the per-user Startup folder. I have watched more than one incident where the payload sat in %AppData%\Roaming\<vendor> for weeks because the config excluded “trusted” vendor directories by name.

A small war story worth internalizing: I once shipped a “tuned” config that excluded PowerShell child processes of sdiagnhost.exe because Microsoft Troubleshooter was producing false positives. Six weeks later, red team abused a signed diagnostic path to launch encoded PowerShell and my exclusion swallowed the alert whole. Exclusions are a liability. Prefer narrow includes.

6. Community Baselines: SwiftOnSecurity vs sysmon-modular

sysmon-modular is the correct default for anyone serious. Each technique lives in its own file under 1_process_creation/, 12_registry_event/, and so on. You compose the config with Merge-SysmonXml.ps1, diff it in git, and roll forward. Fork it. Version-pin it. Never install “latest master” as your production config, because upstream changes will silently reshape your detections.

7. Log Forwarding to SIEM

Sysmon writes locally. Something else has to move the events. Three practical patterns:

Windows Event Forwarding (WEF/WEC). Native, agentless from the endpoint’s perspective, and free. Configure a WEC collector, distribute a subscription policy via GPO, and forward Microsoft-Windows-Sysmon/Operational to the collector’s ForwardedEvents channel. From there, an agent scrapes to SIEM.

Splunk Universal Forwarder. In inputs.conf:

[WinEventLog://Microsoft-Windows-Sysmon/Operational]
disabled = 0
renderXml = true
index = sysmon
sourcetype = XmlWinEventLog:Microsoft-Windows-Sysmon/Operational

renderXml = true matters. Rendered XML gives you every field as a parseable KV pair without hoping the default extraction covers CommandLine correctly.

Elastic (Winlogbeat/Elastic Agent). winlogbeat.yml snippet:

winlogbeat.event_logs:
  - name: Microsoft-Windows-Sysmon/Operational
    processors:
      - script:
          lang: javascript
          id: sysmon
          file: ${path.home}/module/sysmon/config/winlogbeat-sysmon.js

Winlogbeat’s Sysmon module normalizes fields to Elastic Common Schema (process.command_line, process.parent.executable). ECS makes cross-source correlation easy but hides the raw Sysmon field names Sigma rules assume. Keep both: index the raw event under winlog.event_data.* and let ECS-mapped fields ride alongside.

Wazuh ingests the channel via its Windows agent by default; no extra config beyond enabling the channel in ossec.conf.

Whatever you pick, verify end-to-end by triggering an EID 1 you can spot (e.g. whoami.exe /priv) and confirming it lands in the SIEM within your expected latency budget. If forwarding lag is above a minute or two, that is a design problem, not a tuning problem.

8. Writing Sigma Rules Against Sysmon Telemetry

Sigma is the lingua franca. Write rules in Sigma once, convert to Splunk SPL, Elastic Lucene, KQL, or whatever your target speaks. The logsource block does the heavy lifting: category: process_creation implicitly targets Sysmon EID 1 (provider Microsoft-Windows-Sysmon, GUID {5770385f-c22a-43e0-bf4c-06f5698ffbd9}, channel Microsoft-Windows-Sysmon/Operational).

Rules use raw Sysmon field names (Image, CommandLine, TargetImage, GrantedAccess) inside detection.

9. Adversary Emulation Lab: Validate the Pipeline

Detection you have not tested is not detection. The lab: a Windows 10 or 11 VM domain-joined to a Windows Server 2019 AD, Sysmon v15 installed with your merged sysmon-modular config, Splunk Free (or Elastic + Kibana) receiving events. Install Atomic Red Team on the target:

Set-ExecutionPolicy Bypass -Scope Process -Force
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics -Force
Import-Module Invoke-AtomicRedTeam

Now walk the techniques.

Phase 1: T1059.001 (PowerShell) validates EID 1

Invoke-AtomicTest T1059.001 -TestNumbers 1

Expected event: EID 1, Image ends with powershell.exe, CommandLine contains -enc or -EncodedCommand, ParentImage is the shell that launched the atomic. SIEM check in Splunk:

index=sysmon EventCode=1 Image="*\\powershell.exe"
  CommandLine="*-enc*" OR CommandLine="*FromBase64String*"
| table _time, host, User, ParentImage, CommandLine

Phase 2: T1003.001 (LSASS Memory) validates EID 10

# Use Sysinternals ProcDump in the lab. Do not do this in production without authorization.
.\procdump64.exe -accepteula -ma lsass.exe C:\Windows\Temp\lsass.dmp

Expected: EID 10 with TargetImage ending in lsass.exe and GrantedAccess in the 0x1010, 0x1438, or 0x1FFFFF range depending on tool. The Sigma rule:

title: LSASS Memory Access Consistent With Credential Dumping
id: 6a2e9a1e-2c3f-4d1a-9f4b-1b0e7cabb1d1
status: experimental
description: Detects high-privilege handle opens to lsass.exe
references:
  - https://attack.mitre.org/techniques/T1003/001/
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1FFFFF'
      - '0x1010'
      - '0x1438'
  filter_edr:
    SourceImage|startswith:
      - 'C:\Program Files\Windows Defender\'
      - 'C:\Program Files\Microsoft Security Client\'
  condition: selection and not filter_edr
falsepositives:
  - AV/EDR agents legitimately opening handles to lsass
level: high

Convert and deploy:

sigma convert -t splunk -p sysmon rules/lsass_access.yml
sigma convert -t elastic-lucene -p sysmon rules/lsass_access.yml

Phase 3: T1547.001 (Run Key Persistence) validates EID 13

Invoke-AtomicTest T1547.001 -TestNumbers 1

Expected: EID 13 (RegistryEvent (Value Set)), TargetObject matches HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\* or the equivalent HKCU path, Details contains the payload path. If your config excludes registry value sets by default, confirm your include rule for autorun keys fires; if EID 13 does not appear, your exclude/include ordering is off.

Phase 4: T1055.001 (DLL Injection) validates EIDs 8 and 7

Small self-written injector in C, compiled with x86_64-w64-mingw32-gcc on the attacker box:

// inject.c: minimal CreateRemoteThread + LoadLibraryA DLL injection (lab only)
#include <windows.h>
#include <stdio.h>

int main(int argc, char** argv) {
    if (argc != 3) { printf("usage: inject.exe <pid> <dll>\n"); return 1; }
    DWORD pid = atoi(argv[1]);
    HANDLE h = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
    if (!h) return 2;

    LPVOID remote = VirtualAllocEx(h, NULL, strlen(argv[2]) + 1,
                                   MEM_COMMIT, PAGE_READWRITE);
    WriteProcessMemory(h, remote, argv[2], strlen(argv[2]) + 1, NULL);

    LPTHREAD_START_ROUTINE loadlib =
        (LPTHREAD_START_ROUTINE)GetProcAddress(
            GetModuleHandleA("kernel32.dll"), "LoadLibraryA");

    CreateRemoteThread(h, NULL, 0, loadlib, remote, 0, NULL);
    CloseHandle(h);
    return 0;
}

Run against a notepad.exe you launched in the lab. Expected:

• EID 8 (CreateRemoteThread): SourceImage is inject.exe, TargetImage is notepad.exe, StartModule is C:\Windows\System32\kernel32.dll, StartFunction is LoadLibraryA.
• EID 7 (ImageLoad): the injected DLL loading into the notepad process, with Signed=false.

Detection: alert on EID 8 where StartModule ends in kernel32.dll and StartFunction is LoadLibraryA, LoadLibraryW, or LdrLoadDll. This is a classic pattern; if your rule set does not fire on it, your rule set is broken.

Phase 5: T1071.001 (Web C2) validates EID 3

while ($true) {
    Invoke-WebRequest -Uri "http://10.0.0.5/beacon" -UseBasicParsing | Out-Null
    Start-Sleep -Seconds 30
}

Expected: recurring EID 3 with Image ending in powershell.exe, DestinationIp = lab C2, Initiated=true. Detect on the beacon interval, not the single connection: PowerShell producing a network connection every 30 (ish) seconds for an hour is the anomaly.

Phase 6: T1546.003 (WMI Persistence) validates EIDs 19-21

Invoke-AtomicTest T1546.003 -TestNumbers 1

Expected: EID 19 (WmiEventFilter created), EID 20 (WmiEventConsumer created), EID 21 (consumer bound to filter). Any one of the three is suspicious in a well-run environment. All three from the same process in seconds is a very high-confidence signal.

Phase 7: Coverage mapping with DeTT&CT

pip install dettect
python -m dettectinator --help
# Generate data-source YAML derived from what your config actually logs
# Import the resulting JSON layer into ATT&CK Navigator to see coverage gaps visually.

DeTT&CT will tell you honestly what your config sees and what it does not. Every white square on the Navigator layer is a bet you are making that no adversary uses that technique. Reduce the surface area of that bet each sprint.

10. Hardening the Sensor Itself

An attacker who owns the endpoint will notice Sysmon. Sysmon v15+ runs as PPL, which blocks user-mode process termination and DLL injection even from Administrator, but PPL is not immune to abuse via signed drivers or configuration attacks. Do all of the following:

• SYSVOL config ACL: verify only Domain Admins can write to the deployment share.
• Confirm PPL: Get-Process Sysmon64 | Format-List Name, Id, ProtectionLevel should show PsProtectedSignerAntimalware-Light or similar.
• Alert on service stop: correlate Security EID 7040 (service state change) with Sysmon EID 4. A Sysmon EID 4 with state Stopped on a running box means someone flipped the switch.
• Alert on config drift: hash sysmonconfig.xml in your deployment pipeline; any EID 16 whose timing does not line up with a pipeline push is an incident, not a maintenance event.
• Restrict the log channel: the Microsoft-Windows-Sysmon/Operational channel should be readable only by Administrators, which is the default. Confirm anyway.
• Complement with Windows audit: enable Detailed Tracking > Audit Process Creation (Security EID 4688) and PowerShell Script Block Logging (EID 4104). Sysmon EID 1 is strictly richer than 4688, but 4104 catches script content that never touches powershell.exe directly.

11. Common Attacker Techniques Against Sysmon

12. Defensive Strategies and Detection

Sysmon is the sensor; detection lives in the SIEM. Cover the following at minimum:

• EID 4 with state=Stopped anywhere off-hours or without a corresponding maintenance ticket.
• EID 16 without a matching pipeline deployment event.
• Security EID 1102 (audit log cleared).
• EID 10 with TargetImage = lsass.exe and any GrantedAccess containing 0x10 (VM read) or 0x1400 (query information + VM read).
• EID 8 where StartModule and StartFunction are the classic injection pair.

Baseline Sigma rule for a canary you actually want:

title: Sysmon Service Stopped or Uninstalled
id: 5b6a1c3a-9f7b-4b19-91ac-1e6b3f6c1234
status: stable
description: Sysmon service state changed to stopped
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 4
    State: 'Stopped'
  condition: selection
falsepositives:
  - Planned maintenance
level: high

13. Tools

14. MITRE ATT&CK Mapping

Summary

• Sysmon is a sensor, not a detection platform. Everything downstream (correlation, alerting, response) belongs to the SIEM. Design the pipeline as a whole or you will end up with expensive noise.
• ProcessGuid is the correlation key. Build SIEM joins on it and treat EID 1 as the anchor for every follow-on event on that process.
• Modular configs win. Fork sysmon-modular, ATT&CK-tag every RuleName, version-pin in git, deploy via SYSVOL-hosted scheduled task.
• Tune with narrow includes, not sweeping excludes. Exclusions silently swallow real attacks; %AppData%, %Temp%, and Startup are non-negotiable inclusion zones.
• Detection you cannot demonstrate does not exist. Run Atomic Red Team, watch the events fire, write the Sigma rule, convert, deploy, and prove it in your SIEM. If it does not fire in the lab, it will not fire in production.

Related Tutorials

• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers
• Introduction to MITRE ATT&CK: Structure, Tactics, Techniques, and Sub-Techniques

References

• references
• Sysmon – Sysinternals | Microsoft Learn (Official Reference Documentation)
• Enable and Configure Sysmon in Windows | Microsoft Learn
• Sysmon Configuration Files | Microsoft Learn
• MITRE ATT&CK Adversary Emulation Plans (Official MITRE Resource)
• olafhartong/sysmon-modular – Modular Sysmon Config with MITRE ATT&CK Coverage (GitHub)
• SwiftOnSecurity/sysmon-config – High-Quality Sysmon Event Tracing Template (GitHub)