Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Sysmon (System Monitor), part of the Sysinternals suite now maintained by Microsoft, is a Windows kernel-mode/user-mode driver-and-service pair that logs detailed process, network, file, and registry activity to the Windows Event Log (Microsoft-Windows-Sysmon/Operational). Native Windows Security auditing (Event ID 4688 process creation, for example) is coarse by default — Sysmon fills the gap with rich fields like full command line, parent process, hashes, and network connection details that are exactly what detection engineering and incident response need but that stock Windows logging does not reliably provide out of the box.
A default or unconfigured Sysmon install is close to useless in practice: it either logs almost nothing meaningful or floods the event log with so much noise (every process launch, every DNS-adjacent network connection) that the signal is unfindable and log storage/SIEM ingestion costs balloon. The entire value of Sysmon comes from its configuration XML, which defines per-event-type include/exclude rules — this is the actual engineering work of deploying Sysmon, and it is what this article focuses on rather than the installer itself.
Attack Prerequisites
Treating this as “what has to be true for Sysmon to provide useful visibility” rather than an attack precondition:
- Administrative install rights — Sysmon installs a kernel driver and runs as a privileged service (
sysmon64.exe -i config.xml), requiring local admin/SYSTEM to deploy or reconfigure. - A tuned configuration file — without one, Sysmon either captures everything (unmanageable volume) or nothing beyond bare defaults; a good baseline (e.g. SwiftOnSecurity’s or Olaf Hartong’s community configs) is the realistic starting point, then tailored per environment.
- Forwarding to a central log store — Sysmon logs are only durable and searchable if shipped off the endpoint via Windows Event Forwarding (WEF), a SIEM agent, or Winlogbeat; a purely local
.evtxfile is easily cleared by an attacker with admin rights (wevtutil cl). - Ongoing maintenance — config drift (new LOLBins, new attacker techniques) means the ruleset needs periodic review, not a one-time deploy.
How It Works
Sysmon’s driver hooks into the same kernel notification routines Windows itself uses for process, thread, image-load, and file-system events (PsSetCreateProcessNotifyRoutine and siblings), plus a user-mode network component (via WFP callouts) for connection logging. Each observed event is matched against the loaded XML configuration’s <RuleGroup>/<Rule> entries for that event type before being written to the event log — so the config acts as an inline filter, not a post-hoc one, which is what keeps volume manageable even on busy servers.
Each Sysmon event type has a numeric Event ID: 1 (ProcessCreate), 3 (NetworkConnect), 5 (ProcessTerminate), 7 (ImageLoad), 8 (CreateRemoteThread — classic process-injection telemetry), 10 (ProcessAccess — e.g. LSASS handle opens used by credential dumpers), 11 (FileCreate), 12/13/14 (RegistryEvent create/set/rename), and 22 (DNSQuery), among others. The config’s <EventFiltering> block contains one <RuleGroup> per relevance grouping, each holding <Include>/<Exclude> rules keyed by field name (Image, CommandLine, ParentImage, TargetFilename, DestinationIp, etc.) with condition operators (is, contains, begin with, end with, image for path-suffix matching).
The schemaversion attribute on the root <Sysmon> element pins the config to a specific field/event-type set supported by that Sysmon binary version — mismatched schema versions are a common cause of a config silently failing to apply certain rules after a Sysmon upgrade, so it should be bumped deliberately alongside binary upgrades, not left stale.
Practical Example / Configuration
A minimal but real, loadable Sysmon configuration targeting the two highest-value event types for endpoint detection — process creation and outbound network connections — with LOLBin-focused command-line matching and common noise (localhost, private-range broadcast) excluded:
<Sysmon schemaversion="4.90">
<EventFiltering>
<RuleGroup name="ProcessCreate" groupRelation="or">
<ProcessCreate onmatch="include">
<!-- LOLBins commonly abused for download/execute chains -->
<Image condition="end with">\rundll32.exe</Image>
<Image condition="end with">\mshta.exe</Image>
<Image condition="end with">\certutil.exe</Image>
<Image condition="end with">\regsvr32.exe</Image>
<Image condition="end with">\powershell.exe</Image>
<Image condition="end with">\wscript.exe</Image>
<Image condition="end with">\cscript.exe</Image>
<!-- Encoded / download-cradle PowerShell command lines -->
<CommandLine condition="contains">-EncodedCommand</CommandLine>
<CommandLine condition="contains">DownloadString</CommandLine>
<CommandLine condition="contains">-nop -w hidden</CommandLine>
<!-- Office spawning a shell/script host: classic macro-payload chain -->
<ParentImage condition="end with">\winword.exe</ParentImage>
<ParentImage condition="end with">\excel.exe</ParentImage>
</ProcessCreate>
</RuleGroup>
<RuleGroup name="NetworkConnect" groupRelation="and">
<NetworkConnect onmatch="exclude">
<!-- Cut loopback and link-local noise -->
<DestinationIp condition="begin with">127.</DestinationIp>
<DestinationIp condition="begin with">169.254.</DestinationIp>
</NetworkConnect>
<NetworkConnect onmatch="include">
<!-- Focus on processes that should rarely make outbound connections -->
<Image condition="end with">\powershell.exe</Image>
<Image condition="end with">\rundll32.exe</Image>
<Image condition="end with">\mshta.exe</Image>
<Image condition="end with">\certutil.exe</Image>
</NetworkConnect>
</RuleGroup>
<RuleGroup name="ProcessAccess" groupRelation="or">
<ProcessAccess onmatch="include">
<!-- LSASS handle opens: credential-dumping telemetry (Mimikatz, etc.) -->
<TargetImage condition="end with">\lsass.exe</TargetImage>
</ProcessAccess>
</RuleGroup>
<RuleGroup name="CreateRemoteThread" groupRelation="or">
<CreateRemoteThread onmatch="include">
<!-- Cross-process thread creation: classic injection primitive -->
<TargetImage condition="is not">-</TargetImage>
</CreateRemoteThread>
</RuleGroup>
</EventFiltering>
</Sysmon>
Deploying and validating the configuration is a single install/update command plus a schema check, run from an elevated prompt:
# Initial install with the config above
sysmon64.exe -accepteula -i C:\sysmon\config.xml
# Update the running instance's ruleset without reinstalling the driver
sysmon64.exe -c C:\sysmon\config.xml
# Print the currently loaded config back out, to confirm what actually applied
sysmon64.exe -c
Walkthrough / Exploitation
A practical rollout sequence for turning the config above into working, queryable telemetry:
# 1) Validate the XML loads without schema errors before wide deployment
sysmon64.exe -c C:\sysmon\config.xml
# 2) Confirm events are landing in the Sysmon operational log
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 20
# 3) Spot-check a specific high-value event type, e.g. LSASS access (EID 10)
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' |
Where-Object { $_.Id -eq 10 } | Select-Object -First 10 |
Format-List TimeCreated, Message
# 4) Ship the log off-box via WEF subscription (source-initiated), so an
# attacker with local admin cannot destroy evidence with 'wevtutil cl'
wecutil qc /q
wecutil cs C:\sysmon\sysmon-subscription.xml
Steps 1-2 validate the config actually applies and produces events; step 3 confirms the highest-value rule group (credential-access telemetry) is firing; step 4 is what makes the telemetry survive an attacker with local admin rights, which a purely local event log does not.
Note:
groupRelation="and"versus"or"inside a<RuleGroup>controls whether ALL rules in that group must match or ANY one match suffices — a common misconfiguration mistake is leaving the default relation in place when the intent was the opposite, silently over- or under-including events. Always re-checksysmon64.exe -coutput after edits.
Opsec: Sysmon itself is a known target for evasion: attackers with admin rights can unload the driver, tamper with the config, or clear the event log. Detecting Sysmon service-stop (Event ID 4689/7036 for the Sysmon service, or Sysmon’s own Event ID 255/256 config-change events) and shipping logs off-host in near-real-time via WEF are the standard mitigations for this exact tampering scenario.
Detection and Defense
Sysmon is itself a detection tool, so ‘detection and defense’ here is about operating it correctly and protecting it from tampering:
- Ship logs off-host via Windows Event Forwarding, Winlogbeat, or a SIEM agent so
wevtutil cl Microsoft-Windows-Sysmon/Operationalby a compromised admin account does not destroy evidence. - Monitor Sysmon’s own health events — Event ID 4 (service state change), 16 (config change), and Windows service-control events for the Sysmon service itself, since a stopped or reconfigured Sysmon is a strong indicator of an attacker attempting to blind endpoint logging.
- Baseline against a maintained community config (SwiftOnSecurity, Olaf Hartong’s
sysmon-modular) rather than writing rules from scratch, then layer environment-specific include/exclude tuning on top. - Pair with EID 4688 (process creation, Security log) and PowerShell Script Block Logging (EID 4104) for defense in depth — Sysmon complements native auditing, it does not replace it.
- Feed Sysmon events into Sigma-based detections (see the companion Sigma article) so rules stay portable across whatever SIEM ultimately ingests the
Microsoft-Windows-Sysmon/Operationalchannel.
Tuning is an ongoing process: review high-volume event types quarterly, add exclusions for verified-benign noisy applications, and add new include rules as new LOLBins or technique variants become relevant.
Real-World Impact
Sysmon telemetry underlies a large fraction of publicly shared detection content — the SwiftOnSecurity and Olaf Hartong community configs are widely deployed baselines, and MITRE ATT&CK technique write-ups routinely cite specific Sysmon Event IDs (1, 3, 8, 10, 11) as the primary detection data source for process injection, credential access, and lateral movement. Incident responders consistently report that environments with a tuned Sysmon deployment shipped to a central log store resolve intrusion timelines far faster than those relying on default Windows auditing alone.
Conclusion
Sysmon’s value is entirely a function of its configuration: a schema-versioned, deliberately scoped XML ruleset that includes high-signal events (LOLBin execution, LSASS access, remote thread creation) while excluding known noise. Combined with off-host log forwarding so the telemetry survives an attacker with admin rights, a well-tuned Sysmon deployment is one of the highest-leverage, lowest-cost investments in Windows endpoint visibility.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments