Sysmon Guide: Configuration and Detection Use Cases

Native Windows logging tells you a process started; it rarely tells you what that process touched, loaded, connected to or injected into, which is exactly what investigators need. Microsoft Sysinternals System Monitor (Sysmon) fills that gap with a driver and service that record process, network, file, registry, WMI and DNS activity to the Windows event log, controlled by an XML configuration. Its value depends almost entirely on that configuration, on getting the events to a SIEM, and on noticing when an attacker turns it off. This guide covers the event IDs, configuration and filtering, community baselines, deployment, log volume, forwarding, tamper protection and detection use cases mapped to MITRE ATT&CK, with a short section on Sysmon for Linux. It is written for detection engineers, SOC analysts and endpoint teams.

Key takeaways

• Sysmon records, it does not detect. Microsoft states that Sysmon "does not provide analysis of the events it generates, nor does it attempt to hide itself from attackers"; detections live in your SIEM.
• The configuration is the product. Include and exclude rules decide whether you get useful telemetry or a flood; start from a maintained community baseline and tune it.
• Two delivery routes now exist. Standalone Sysinternals Sysmon (v15.22 at the time of writing) and built-in Sysmon, an optional feature on Windows 11 and Windows Server 2025 serviced through Windows Update. They cannot run together.
• Volume is set by a few event types. Network connections (3), image loads (7) and process access (10) generate the most events and need the tightest filters.
• Plan for tampering. ATT&CK v20 T1685 names Sysmon as a target; watch events 4, 16 and 255 and alert when a host goes silent.

What Sysmon adds to native logging and EDR

Sysmon installs a service and a kernel driver, writes to the Microsoft-Windows-Sysmon/Operational channel (Applications and Services Logs, Microsoft, Windows, Sysmon, Operational) with UTC timestamps, and generates events from early in the boot process. Each process gets a ProcessGuid that Microsoft describes as "a unique value for this process across a domain", which makes it far easier to join a process to its network connections, file writes and child processes than Windows process IDs, which are reused.

Running Sysmon alongside EDR is common: Olaf Hartong's sysmon-modular even ships an "MDE-augment" profile intended "to complement Microsoft Defender for Endpoint with less overlap". The independent event stream matters most when the EDR agent is the thing an attacker targets.

Sysmon event ID reference

Event names follow Microsoft's Sysinternals page. Events 4 and 16 cannot be filtered.

Configuration and filtering

The configuration is an XML file applied with sysmon -accepteula -i config.xml at install and sysmon -c config.xml afterwards; neither needs a reboot. sysmon -s prints the schema, and the schemaversion attribute is independent of the binary version so older files still parse. Key top-level settings:

• HashAlgorithms: MD5, SHA1, SHA256, IMPHASH or *. Pick what your threat intelligence uses; IMPHASH helps cluster related malware.
• CheckRevocation and DnsLookup: signature revocation checks and reverse DNS, both on by default. Reverse lookups generate traffic from every host; consider turning DnsLookup off and enriching in the SIEM.
• ArchiveDirectory and CopyOnDelete settings: control where event 23 keeps deleted files.
• DriverName: changes the driver name, which makes simple name-based tampering slightly harder.

Filtering rules, from the Microsoft schema documentation:

• onmatch="include": only matching events are logged. An empty include block logs nothing for that event; an empty exclude block logs everything.
• onmatch="exclude": everything is logged except matches. When both exist for an event, "exclude matches take precedence".
• Combining conditions: conditions on the same field are ORed, conditions on different fields are ANDed. A RuleGroup with groupRelation="and" or "or" makes the logic explicit.
• Operators: is, is any, is not, contains, contains any, contains all, excludes, begin with, end with, not begin with, not end with, less than, more than and image, all case-insensitive.
• Rule names: a name attribute on a rule is written into the event's RuleName field, so naming rules after ATT&CK technique IDs tags events at source.

An illustrative fragment that logs only access to LSASS and tags it (schema per Microsoft's Sysmon documentation):

<RuleGroup name="lsass" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage name="T1003.001" condition="end with">\lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

Write exclusions as narrowly as possible. An exclusion on Image ending with a filename, rather than the full path, lets an attacker hide by naming a tool after an excluded program.

Community baseline configurations

SwiftOnSecurity's README describes sysmon-modular as able to "act as a superset of sysmon-config". Choose the single file if you want something a small team can read end to end; choose modular if you maintain several profiles (workstation, server, domain controller) and want changes reviewed module by module. Either way, keep your fork in version control and record which upstream commit it came from.

Deployment and updates at scale

• Choose the delivery route: built-in Sysmon is disabled by default and enabled with Enable-WindowsOptionalFeature -Online -FeatureName Sysmon, then configured with sysmon -i. Microsoft delivers its improvements through Windows quality updates and security fixes in the monthly security release. Standalone Sysmon is updated by redeploying the Sysinternals binary. Microsoft states the two "can't be enabled on the same device at the same time" and standalone must be uninstalled first.
• Distribute with the tools you already trust: Configuration Manager, Intune Win32 apps or remediation scripts, Group Policy startup scripts, or your server configuration management. The script should install if missing, compare the installed config (dumped with sysmon -c) to the approved version, and update if different.
• Version the configuration: include a version string in a comment and a named rule, and report it per host so you can prove fleet adoption.
• Different profiles by role: domain controllers, servers, developer workstations and standard endpoints have different noise. Avoid one configuration everywhere.
• Localisation: built-in Sysmon localises the rendered message but not the XML event data, so parse the XML fields, not message text.

Performance and log volume

Microsoft warns that monitoring all image loads "will generate a significant amount of logging" and that process access monitoring "should only be done so with filters that remove expected accesses". sysmon-modular warns its Research profile "can consume substantial CPU, memory and logging capacity". Practical controls:

• Measure before rollout: record events per host per day by event ID on representative pilot machines, and size SIEM licences and the Sysmon channel's maximum log size from that.
• Exclude your own tooling: antivirus, EDR, backup and management agents generate repetitive file, registry and process access events.
• Filter at source, then in the pipeline: filter in Sysmon what you will never need; drop or summarise the rest in the pipeline. See the Security Data Pipeline Guide.
• Use high-volume events selectively: enable 7 only for specific DLLs or processes, and keep 3 for servers and unusual processes rather than every browser connection.

Forwarding to a SIEM

Windows Event Forwarding (WEF) sends selected events to a Windows Event Collector (WEC) using WinRM. Microsoft recommends source-initiated (push) subscriptions configured by Group Policy for scale, and plans for about 3,000 events per second on average per collector. Add the Sysmon channel to the subscription query with <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>. For the Security channel, clients need the Network Service account in the Event Log Readers group. The alternative is a SIEM or log shipper agent on each host, which avoids collector infrastructure but adds another agent to manage. Whichever route you choose, forward to storage the endpoint cannot alter and retain long enough for investigations. See the SIEM Guide and the Log Management and Retention Guide.

Tampering and protecting Sysmon

ATT&CK v20 technique T1685 Disable or Modify Tools (tactic TA0112 Defense Impairment) names Sysmon as a target, and T1685.001 covers disabling or modifying the Windows event log. An administrator can uninstall Sysmon, unload its minifilter driver, change the configuration stored under the driver's service key in the registry, or clear and disable the channel. The Sysmon service runs as a protected process, which blocks many user-mode interactions, but not an attacker with full administrative rights.

• Alert on Sysmon's own events: event 4 (service stopped), 16 (configuration changed outside your deployment process) and 255 (errors).
• Alert on silence: ATT&CK's detection guidance highlights the "abnormal absence of expected telemetry". Build a heartbeat rule for hosts that stop sending Sysmon events while still sending others.
• Watch the tools: process creation for sysmon -u, fltmc unload and wevtutil cl or sl /e:false against the Sysmon channel, and registry writes to the Sysmon driver parameters.
• Forward fast: events already in the SIEM survive a later log clear. See the EDR Evasion and Defence Guide for tamper protection in the wider endpoint stack.

Detection use cases mapped to ATT&CK

Each detection below joins Sysmon fields in the SIEM. Behaviour descriptions follow the ATT&CK technique pages; tune thresholds to your environment.

Where identity fits: event 1 records the user behind every process. Service accounts and other non-human identities should have predictable process trees, so a service account launching cmd.exe, PowerShell or remote tools is a strong signal of a stolen or misused credential. See the Service Account Security Guide. For building, testing and maintaining these rules, see the Detection Engineering Guide.

Sysmon for Linux

Sysmon for Linux monitors "process lifetime, network connections" and file system writes, using eBPF through the SysinternalsEBPF library, and writes events to syslog. It uses the same XML configuration approach and is installed from Microsoft's Linux package repositories. The bundled sysmonLogView tool in /opt/sysmon filters and formats output, for example sudo tail -f /var/log/syslog | sudo /opt/sysmon/sysmonLogView. It complements, not replaces, auditd and EDR on Linux servers.

Rolling out Sysmon

1. Define the questions: list the ATT&CK techniques you need to detect and the investigations you run, and map them to event IDs.
2. Pick a baseline and fork it: import SwiftOnSecurity or a sysmon-modular Balanced profile into version control.
3. Pilot: deploy to a ring of representative machines per role (including developers and servers), measure CPU, events per day and SIEM cost for two weeks, and tune exclusions.
4. Forward and validate: confirm events arrive parsed in the SIEM, then test detections with safe simulations. See the Breach and Attack Simulation (BAS) Guide.
5. Expand in rings: domain controllers and critical servers, then servers, then endpoints, checking volume at each step.
6. Rollback: keep the previous config and reapply it with sysmon -c, or uninstall with sysmon -u; neither needs a reboot.

Detection and measurement

• Coverage: percentage of Windows endpoints and servers that sent Sysmon events in the last 24 hours, by role.
• Config compliance: percentage of hosts running the approved configuration version.
• Volume: events per host per day by event ID, against the budget set in the pilot.
• Detection coverage: number of prioritised ATT&CK techniques with a tested Sysmon-based rule, and the pass rate of simulations.
• Silent hosts: count and time to investigate hosts that stop sending Sysmon telemetry.

Framework mapping

Common failure patterns

• Default or untuned config: installing with no config or a verbose research profile, then turning Sysmon off when the SIEM bill arrives.
• Logs stay on the host: events are never forwarded, so they are cleared or rolled over before anyone looks.
• Broad filename exclusions: excluding by image name lets attackers rename tools to match.
• Configuration drift: nobody knows which config version each host runs, and old hosts miss new rules.
• No tamper alerting: events 4 and 16 are collected but never alerted on, and silent hosts go unnoticed.
• Telemetry without detections: data lands in the SIEM but no rules or hunts use it.

Practitioner checklist

• Decide between standalone and built-in Sysmon per platform and never run both.
• Fork SwiftOnSecurity or sysmon-modular into version control and keep role-specific profiles.
• Pilot, measure events per host per day and tune exclusions with full paths.
• Name rules after ATT&CK technique IDs so RuleName tags events at source.
• Forward the Sysmon channel through WEF or an agent to storage endpoints cannot alter.
• Alert on events 4, 16 and 255 and on hosts that stop sending Sysmon events.
• Report config version per host and remediate drift.
• Build and test detections for LSASS access, injection, persistence and lateral movement.
• Deploy Sysmon for Linux where Linux servers lack equivalent telemetry.

Standards and references

• Microsoft Learn: Sysmon (Sysinternals)
• Microsoft Learn: Built-in Sysmon overview
• Microsoft Learn: Enable and configure Sysmon in Windows
• Microsoft Learn: Use Windows Event Forwarding to help with intrusion detection
• MITRE ATT&CK: T1685 Disable or Modify Tools
• Microsoft: Sysmon for Linux
• SwiftOnSecurity: sysmon-config
• Olaf Hartong: sysmon-modular

Related NHI Mgmt Group resources: Detection Engineering Guide · Windows Event Log Guide · SIEM Guide · Credential Dumping Guide · Living off the Land Guide