Sysmon Configuration for Windows Security Monitoring

0 Comments 10 min read

Native Windows auditing covers a surprising amount of ground, but it has known gaps: no file hashes on process creation, no outbound network connections, no LSASS access telemetry, and no built-in DNS query log. Sysmon configuration for security monitoring closes most of those gaps and is the single highest-value addition to a Windows endpoint detection stack after audit policy itself. This post is the deployment we use internally — install, baseline config, scaled rollout, and the event IDs that actually carry signal.

Key Takeaways

  • Sysmon is a free Sysinternals tool that augments the Windows event log with process, network, registry, file, image-load, and DNS telemetry — none of which native auditing covers well out of the box.
  • The configuration file is what matters. An empty Sysmon install logs almost nothing useful; a tuned config (SwiftOnSecurity or Olaf Hartong's modular project) is the sane starting point.
  • Deploy via a Group Policy scheduled task or Intune script so updates flow through the same channel as the rest of the fleet's tooling.
  • Event IDs 1 (process), 3 (network), 10 (process access), 11 (file create), and 22 (DNS query) cover the majority of high-value detection use cases.
  • Forward the Microsoft-Windows-Sysmon/Operational channel to a Windows Event Collector or SIEM. Sysmon on its own is per-host; centralised logs are what make it useful for a fleet.

Environment

  • Windows 10/11 and Windows Server 2019/2022 endpoints.
  • Sysmon v15 for Windows (the current major version as of writing — Sysmon for Linux is a separate project with a different event schema).
  • An existing Group Policy or Intune deployment channel to push binaries and config updates.
  • A Windows Event Collector (WEC) or SIEM to receive forwarded Sysmon events. See our Windows Event Forwarding setup guide for the collector side.
  • PowerShell 5.1 or 7.4 for hunting queries on the collector.

The Problem

Built-in Windows auditing is good at telling you that a process started (4688), that an account logged on (4624), or that an AD object changed (5136). It is less good at the things modern detection actually depends on: the SHA-256 of the binary that ran, the IP it then connected to, the DLL it loaded that did not match a Microsoft signature, the handle it requested on the LSASS process. Some of that is available with extra audit subcategories, command-line inclusion settings, or Object Access auditing, but the coverage is uneven and the events are designed for compliance more than detection.

Sysmon was written by Sysinternals (Mark Russinovich and Thomas Garnier) to fill those gaps. It installs as a kernel driver plus a user-mode service, hooks the events of interest at the source, and writes them to a dedicated event channel. Crucially, it is free, signed by Microsoft, supported on every modern Windows version, and produces telemetry that maps cleanly to MITRE ATT&CK techniques. The trade-off is that it ships with no useful configuration — running sysmon.exe -i with no config file logs almost nothing of value. The configuration file is the entire product.

The Solution

Step 1 — Install Sysmon on a test endpoint

Download Sysmon from the Sysinternals page on Microsoft Learn. Verify the signature, then install with a configuration file in one step: 

# Run elevated
sysmon.exe -accepteula -i sysmonconfig.xml

# Confirm install
Get-Service Sysmon* | Format-Table Name, Status, StartType

The installer registers the driver, starts the service, and begins writing to the Microsoft-Windows-Sysmon/Operational channel. To update the config later, run sysmon.exe -c sysmonconfig.xml — no reinstall, no reboot. The channel is small by default; bump it before traffic builds up: 

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824   # 1 GB

Step 2 — Pick a configuration baseline

Two community baselines cover virtually every production Sysmon deployment in the wild:

  • SwiftOnSecurity/sysmon-config — a single curated XML, heavily commented, conservative on volume. The right starting point for most environments.
  • olafhartong/sysmon-modular — a modular framework where rules live in separate files per ATT&CK technique. More work to assemble, but cleaner to maintain and easier to map to detection coverage.

Both projects are open source and well-maintained. We use SwiftOnSecurity's baseline as the floor and pull additional modules from sysmon-modular for areas the baseline omits — most notably credential-access (LSASS handle requests) and lateral-movement (named pipe creation) coverage. The rule of thumb is to enable everything except event ID 7 (image load) initially, then turn 7 on for a defined set of high-value processes once log volume is understood.

Step 3 — Deploy and update across the fleet

At scale, copy the Sysmon binary and config to a known location and trigger install or reconfigure on every endpoint. A Group Policy scheduled task is the simplest mechanism that does not require additional tooling: 

# Idempotent deployment script
$bin    = '\\dfs\sysmon\Sysmon64.exe'
$config = '\\dfs\sysmon\sysmonconfig.xml'

if (Get-Service Sysmon* -ErrorAction SilentlyContinue) {
    & $bin -c $config
} else {
    & $bin -accepteula -i $config
}

Wrap that in a scheduled task that runs daily as SYSTEM, target it via GPO at every domain-joined endpoint, and config changes propagate within 24 hours of being copied to the share. Intune Win32 app deployment works the same way for cloud-managed endpoints. Whichever channel is used, the binary and configuration both need version pinning — Sysmon's schema occasionally adds new fields, and a config authored against schema 4.90 will fail to load on a host running an older binary.

Step 4 — The Sysmon event IDs that carry signal

Sysmon emits 27 distinct event IDs at the time of writing. A much smaller subset is where most detections live:

  • 1 — Process creation. Includes the SHA-256 hash, parent process, full command line, and integrity level. The single most valuable Sysmon event.
  • 3 — Network connection. Outbound TCP/UDP including destination IP, port, and the process that initiated it.
  • 7 — Image loaded (DLL load). High volume; enable selectively for processes like lsass.exe, winlogon.exe, and Office binaries.
  • 8 — CreateRemoteThread. Classic process injection primitive.
  • 10 — Process access. The GrantedAccess field is where LSASS credential dumping shows up (values around 0x1010 or 0x1410).
  • 11 — File create. Useful for staging detections (executables written to %TEMP%, %APPDATA%, or web-shell paths).
  • 12 / 13 / 14 — Registry events. Pair with autorun and persistence keys.
  • 22 — DNS query. Every resolution made by every process — the single best telemetry source for C2 callback detection.
  • 25 — Process tampering. Process hollowing and image replacement.

Step 5 — Forward Sysmon to the collector

Add Microsoft-Windows-Sysmon/Operational to the subscription XML on the Windows Event Collector. The simplest path is a second Select path inside an existing baseline subscription: 

<Select Path="Microsoft-Windows-Sysmon/Operational">
  *[System[(EventID=1 or EventID=3 or EventID=7 or EventID=8 or
            EventID=10 or EventID=11 or EventID=22 or EventID=25)]]
</Select>

Sysmon volume is significant — a single workstation can push 500 to 2,000 events per minute depending on which IDs are enabled. Plan for a separate forwarded log if the collector is serving more than a handful of endpoints; the WEF setup post covers custom event channels for exactly this case.

Step 6 — Hunting queries

A few queries that pay off the first time they run against forwarded Sysmon data: 

# Event 10 — handle requests on lsass.exe with credential-dumping access masks
Get-WinEvent -FilterHashtable @{
    LogName = 'ForwardedEvents'
    ProviderName = 'Microsoft-Windows-Sysmon'
    Id = 10
    StartTime = (Get-Date).AddDays(-1)
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match 'TargetImage:.*lsass\.exe' -and
                   $_.Message -match 'GrantedAccess:\s*0x1(0|4)10' } |
    Select-Object TimeCreated, MachineName,
                  @{Name='SourceImage'; Expression={
                      ($_.Message -split "`n" | Where-Object { $_ -match 'SourceImage' }) -replace '.*: '
                  }}

# Event 22 — DNS queries from processes that should not be resolving names
Get-WinEvent -FilterHashtable @{
    LogName = 'ForwardedEvents'
    ProviderName = 'Microsoft-Windows-Sysmon'
    Id = 22
    StartTime = (Get-Date).AddHours(-1)
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match 'Image:.*\\(certutil|bitsadmin|powershell|regsvr32)\.exe' } |
    Select-Object TimeCreated, MachineName,
                  @{Name='Query'; Expression={
                      ($_.Message -split "`n" | Where-Object { $_ -match 'QueryName' }) -replace '.*: '
                  }}

These are the kinds of queries that produce one or two hits per fleet per day and almost always warrant attention when they fire.

Frequently Asked Questions

Do I still need native Windows auditing if I have Sysmon?

Yes. Sysmon does not replace the Security log — it sits next to it. Authentication events (4624, 4625), account management (4720, 4728), AD object changes (5136), and audit policy changes (1102, 4719) all live in the Security channel and have no Sysmon equivalent. Sysmon adds process, network, image, and DNS telemetry; the Security log keeps everything else. Run both, forward both.

Will Sysmon affect endpoint performance?

On modern hardware, the user-visible impact is minimal — Sysmon hooks the events in kernel mode and writes to a dedicated channel, so most cost is in disk I/O on the event log itself. The two configuration choices that drive measurable CPU and disk use are event ID 7 (image load — every DLL load on every process) and overly broad rules on event ID 13 (registry value set). Both can be tuned with exclude rules in the config.

How is Sysmon different from Microsoft Defender for Endpoint?

Defender for Endpoint is a commercial EDR with its own telemetry pipeline, behavioural detections, and response capability. Sysmon is a free telemetry source that writes to the Windows event log; the analytics happen wherever you ship the log. Most environments running Defender for Endpoint do not also need Sysmon, since Defender collects similar telemetry through its agent. Sysmon is the right answer when the SIEM is something other than Defender XDR — Sentinel without P2, Splunk, Elastic, or a homegrown collector.

How should I update the Sysmon configuration across the fleet?

Treat the config like any other production artefact — version-control the XML, copy it to a known share or container, and run sysmon.exe -c on every endpoint on a schedule. The command is idempotent: applying the same config twice is a no-op. The Group Policy scheduled task pattern in Step 3 handles this without additional infrastructure.

Is Sysmon event ID 7 (image load) worth the volume?

Selectively, yes — but not for every process. Enabling event 7 globally adds hundreds of events per second per endpoint. The useful pattern is to include event 7 only for the small set of processes that matter for credential-access and persistence: lsass.exe, winlogon.exe, services.exe, and any Office or browser binary that hosts macros or extensions. Both SwiftOnSecurity and sysmon-modular ship include-by-default rules along these lines.

Conclusion

Sysmon is rare among free security tools in that the deployment effort is small and the detection lift is large. The hard parts are picking a configuration baseline and getting the events centralised — both are solved problems with mature open-source projects. Once those two pieces are in place, the event IDs above expose roughly the same telemetry an expensive EDR collects, in a format any SIEM can ingest.

Combined with native audit policy and Windows Event Forwarding, Sysmon gives a Windows environment detection coverage that is genuinely useful — not the box-checking kind, but the kind that catches things.

Related Posts

0 comments:

Post a Comment