Default Windows logging tells you a process started. Sysmon tells you the full command line, the parent process, the hash of the binary and who ran it. That is the difference between an event and a story. For teams without full EDR coverage, it is the highest-value free telemetry available on Windows.

The events that carry the weight

Event ID Event Typical use
1 Process creation Execution chains, LOLBin abuse
3 Network connection Beaconing, unusual egress by process
7 Image loaded DLL hijacking, credential theft tooling
8 CreateRemoteThread Process injection
10 Process access LSASS access, credential dumping
13 Registry value set Persistence via Run keys, services
22 DNS query C2 domains tied to the requesting process

Configuration philosophy

A Sysmon deployment lives or dies on its configuration. Two rules have served me well:

  1. Start from a maintained baseline (community configs exist for a reason), then tune to your environment instead of writing from scratch.
  2. Exclude known-good noise; don’t try to include known-evil. Attackers change tools; your monitoring agents and update services don’t.

First detections to build

  • Office applications spawning cmd.exe or powershell.exe (Event 1, parent/child mismatch)
  • rundll32.exe or regsvr32.exe making network connections (Events 1 + 3)
  • Non-system processes opening handles to lsass.exe (Event 10)
  • New Run-key values pointing into user-writable paths (Event 13)

Each pairs a Sysmon event with a behavioral expectation, which is exactly the mindset shift Sysmon enables: from indicators to behaviors.

This article was originally published on Medium.

SysmonWindowsendpoint monitoringdetection