Sysmon event IDs: what to collect for threat detection

Sysmon installs two components: a Windows service and a boot-start device driver. The driver loads at boot start, so it captures activity from early in the boot sequence, before most autostart persistence mechanisms fire. The service writes those events to a dedicated channel: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. The channel path you’ll use in queries and collector configurations is Microsoft-Windows-Sysmon/Operational, and Sysmon records all timestamps in UTC, per Microsoft’s Sysmon documentation.

An XML configuration file controls what Sysmon records. You define include and exclude rules per event type, and Sysmon applies them in the kernel, so filtering happens before events ever hit the log. The service runs as a protected process, so user-mode code — even running as administrator — can’t kill it or inject into it.

Sysmon runs on Windows 10 and later and Windows Server 2016 and later. As of this writing, the current release is Sysmon v15.21 (Microsoft, 17 June 2026). A separate Sysmon for Linux port exists on GitHub; this article focuses on the Windows version.

For the standalone version, download Sysmon from the Sysinternals site and install it from an elevated prompt:

Neither installation nor removal requires a reboot, and configuration updates apply to the running service. Installed without a configuration file, Sysmon logs a basic default set (process creations hashed with SHA1) and leaves network connections (event ID 3) and image loads (event ID 7) switched off, per the official documentation.

The configuration file is where the real work happens. Filter rules live under EventFiltering, one tag per event type, each with an onmatch attribute:

Three rules of thumb, all documented on the Sysmon page: include logs only matching events while exclude logs everything except matches; when both are defined for the same event type, exclude wins; and within a rule, conditions on the same field combine as OR while conditions on different fields combine as AND. You can override that behavior with a RuleGroup and an explicit groupRelation. The schemaversion is independent of the binary version. Print your current schema with sysmon -s.

Sysmon defines 30 event types. The table below summarizes all of them; the descriptions, default states, and volume warnings come from Microsoft’s Sysmon documentation.

There is no single correct list — it depends on your environment, your detection content, and your storage budget. What I can give you is a defensible starting point, anchored in two things you can verify yourself: Microsoft’s own documented defaults and volume warnings, and how directly each event maps to MITRE ATT&CK techniques. Here are my tiers:

Treat the tiers as a starting point to tune, not gospel. The sections below explain why each event earns its place, grouped by the attacker behavior it exposes.

Two principles keep Sysmon sustainable. First, filter at the source: Sysmon applies configuration rules in the kernel, so events you exclude never consume disk, bandwidth, or SIEM licensing. Second, for the noisy event types, write include rules for what you want rather than trying to exclude your way out of an open firehose.

Here’s what that looks like for the Tier 2 events:

Note the name attribute on the LSASS rule: Sysmon writes it to the event’s RuleName field, so your SIEM knows which rule fired, a documented feature that pays off downstream.

Don’t build a production configuration from scratch. Two community baselines have absorbed years of tuning: SwiftOnSecurity’s sysmon-config, a heavily commented single file, and Olaf Hartong’s sysmon-modular, a modular set whose rules are annotated with ATT&CK technique IDs. Start from one, diff it against your environment for a week, and put the result under version control.

For a quick look on a single machine, open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. PowerShell is faster:

That’s fine for spot checks. For detection, the events need to leave the host: an attacker with local admin can clear the channel, and no analyst can hunt across a fleet one Event Viewer at a time.

NXLog Agent collects the Sysmon channel through its im_msvistalog module, the same module it uses for any Windows Event Log. Here is a complete configuration that reads all Sysmon events and forwards them as JSON over TLS:

To collect only your Tier 1 events, push the filtering into the Windows Event Log API itself with an XPath query. Filtering at this layer happens before events reach the agent, so excluded events cost nothing downstream; the NXLog Sysmon integration guide covers collecting the channel in detail:

And when XPath isn’t expressive enough, the NXLog language can filter on any event field, as shown in the Windows Event Log integration guide:

Collection is only half the operational problem, though. The other half is that a Sysmon deployment is a configuration deployment: hundreds or thousands of endpoints, each needing the right Sysmon XML, the right agent configuration, and updates for both. Native Sysmon in Windows solved binary distribution; it did nothing for configuration and collection management.

That’s the gap NXLog Platform covers. You enroll your agents once, then manage them as a fleet from one place: push configuration changes centrally, monitor agent health, and route Sysmon data to NXLog Platform’s own storage or to your SIEM. When your detection team wants a new include rule shipped to every workstation, that’s a configuration change and a rollout, not a project. The NXLog Platform documentation covers agent enrollment and fleet management in detail.

A fair question: doesn’t Security event 4688 already log process creation? It does — with gaps that matter. According to Microsoft’s 4688 documentation, the Process Command Line field is empty by default and only populates after you turn on a separate Group Policy setting, documented in Command line process auditing. Even with it turned on, 4688 carries no file hashes, no parent command line, and only reusable process IDs for correlation.

Sysmon event ID 1 records all of that out of the box: full command line, parent command line, configurable hashes for threat-intelligence matching, and a ProcessGuid that survives PID reuse.

The gap runs the other way too. Sysmon records no authentication activity — logons, failed logons, and account changes stay in the Security log (events 4624, 4625, and friends, which we’ve covered in our Remote Desktop logs guide). The two sources are complements, not competitors: Sysmon for execution telemetry, Windows Event Log auditing for identity. Collect both.

Sysmon gives you the execution-level visibility that default Windows auditing lacks — as long as you approach it as a curated telemetry source rather than a switch you flip on.

Key takeaways:

Your endpoints already generate the evidence. Collect the right subset, protect the pipeline that carries it, and your SOC gets signal instead of noise.