What Are Sysmon Event IDs 1–29? Detection Guide & XML Config

A field reference for SOC analysts and detection engineers: every Sysmon event ID, what it records, and how to configure it for threat detection — with MITRE ATT&CK mappings.

Published: 2026-10-24  |  Last reviewed: 2026-10-24

Sysmon (System Monitor) defines 30 event types — IDs 1 through 29, plus ID 255 for internal errors. Not all of them are worth collecting. A handful do most of the detection work; several more require careful filtering to stay useful; a few are situational. This guide maps every event ID to what it records, its default state, its volume characteristics, and the MITRE ATT&CK techniques it exposes — plus a working XML configuration you can deploy today.

Sysmon is a free Windows system service and device driver from Microsoft Sysinternals. It runs as a protected process and writes detailed execution telemetry — process creation with full command lines, network connections tied to processes, registry changes, DNS queries — to Applications and Services Logs\Microsoft\Windows\Sysmon\Operational, a dedicated channel standard Windows auditing never touches. [1]

• Key Takeaways
• Sysmon has 30 event types (IDs 1–29 plus 255). ID 1, 6, 8, 12–14, 19–21, 22, and 25 are the high-value, manageable-volume set to collect everywhere.
• IDs 3, 7, 10, and 11 require include-only rules — Microsoft warns that IDs 7 and 10 generate significant volume unfiltered, and ships ID 3 and 7 off by default.
• Always alert on IDs 4, 16, and 255 — Sysmon going silent or its config changing unexpectedly is an incident signal.
• Event ID 29 (FileExecutableDetected), added in Sysmon 15, logs PE file creation in monitored paths. Pair it with ID 27 (FileBlockExecutable) for active blocking.
• As of early 2026, Sysmon is now a built-in optional Windows feature in Windows 11 and Windows Server 2025 — binary distribution is simpler, but configuration management remains your job. [2]
• Start from a community baseline — SwiftOnSecurity's sysmon-config or Olaf Hartong's sysmon-modular — and treat it as detection content under version control.

How does Sysmon actually work?

Sysmon installs two components: a boot-start device driver and a Windows service. The driver loads during the kernel boot phase — before autostart entries in Run keys or scheduled tasks — so it can capture early persistence mechanisms that fire before user-mode tools would see anything. The service runs as a protected process, meaning user-mode code, even running as SYSTEM or local administrator, cannot terminate it or inject into it through normal APIs. [1]

An XML configuration file governs every event type. Rules live under <EventFiltering>, one tag per event type, each with an onmatch attribute of either include or exclude. The filtering happens in the driver — events you exclude never reach the log channel, never consume SIEM licensing, and never hit your disk. That architecture makes careful Sysmon configuration genuinely economical: you only pay for what you ask for.

Without a config file, Sysmon logs a minimal default set: process creations hashed with SHA1, plus the service and configuration events that cannot be filtered away. Network connections (ID 3) and image loads (ID 7) are off by default precisely because they generate enormous volume unfiltered. That default is fine for a quick sanity check; it is not a detection deployment. [1]

One change worth noting: as of early 2026, Sysmon shipped as a built-in optional Windows feature for Windows 11 and Windows Server 2025. The binary updates through Windows Update instead of requiring manual redeployment. Event IDs, fields, and configuration files are unchanged — the telemetry is identical. The standalone and built-in versions cannot coexist, so remove the Sysinternals build before enabling the feature. [2]

Complete Sysmon event ID reference (IDs 1–29 and 255)

The table below covers all 30 Sysmon event types, their default states, volume characteristics, and primary ATT&CK data-source mappings. Default-state information and volume warnings come from Microsoft's Sysmon documentation. [1]

Table note: "Default Off" events require explicit configuration to enable. Volume characteristics vary by environment; production deployments should baseline each event type before committing to collection tiers.

Which Sysmon events catch which attacker behaviors?

The most useful way to think about Sysmon event IDs is by what they expose during each phase of an intrusion, not just by what they log in isolation.

Process execution and command-line abuse

Event ID 1 is the backbone of endpoint detection. Every Sysmon process creation event records the full command line, the parent process and the parent's command line, the executing user, and configurable file hashes. The ProcessGuid field remains unique even when Windows reuses process IDs, which makes cross-event correlation reliable even after a process exits. [1]

For comparison, the built-in Windows Security event 4688 covers process creation too — but the Process Command Line field is empty by default and only populates after a separate Group Policy setting is enabled. And even then, 4688 carries no file hashes and only reusable process IDs. The difference matters when you are hunting encoded PowerShell or LOLBIN abuse: detecting living-off-the-land techniques with EDR telemetry relies on exactly the kind of parent process and command-line context that ID 1 provides.

Credential access and code injection

Event ID 10 records one process opening a handle to another. Unfiltered, it is unusably noisy. Filtered to handles targeting lsass.exe, it becomes the canonical telemetry for credential dumping (T1003.001). Event ID 8 captures the remote thread creation that underlies most classic process injection techniques. Event ID 25 goes a step further and flags process image tampering — process hollowing and "herpaderping" — cases where a process's in-memory image no longer matches what is on disk. [3]

Persistence — registry and WMI

Events 12 through 14 cover the registry autostart battleground: key creation and deletion (12), value writes including the actual data for DWORD and QWORD values (13), and renames (14). ID 13 is the one that matters most — you see the payload being written, not just a key being touched.

Events 19, 20, and 21 cover WMI event subscription persistence in full. ID 19 logs the event filter, ID 20 logs the consumer, and ID 21 logs the binding that activates the subscription — the three-step sequence required to establish WMI-based persistence (T1546.003). These events generate near-zero baseline volume in a healthy environment. A new WMI subscription appearing out of nowhere should go straight to a ticket.

This kind of registry and WMI persistence detection pairs directly with an incident response plan — you want the visibility in place before you need it.

Network connections and DNS telemetry

Event ID 22 ties every DNS query to the process that issued it. Server-side DNS logs tell you what was queried; ID 22 tells you which process on which endpoint asked. It covers successful queries, failed resolutions, and cached results. For hunting DGA patterns or newly registered domains communicating with an implant, this is essential context. Event ID 3 does the equivalent for TCP/UDP connections. Both require filtering — unscoped, they are firehoses — but scoped to suspicious process names and external IP ranges, they deliver exactly what behavioral detection rules need.

Anti-forensics and defense evasion

Event ID 26 (FileDeleteDetected) covers anti-forensics with lower operational cost than ID 23. Event ID 23 archives deleted files to a local folder on disk, which Microsoft explicitly warns can grow to an unreasonable size — a storage trap that can quietly degrade endpoint performance. Unless you need the actual deleted file for malware analysis, ID 26 gives you the deletion record without the archive overhead.

Event ID 6 (DriverLoad) earns a Tier 1 slot despite low volume precisely because driver loads are both rare and high-consequence. Bring-your-own-vulnerable-driver (BYOVD) attacks — where an attacker loads a legitimate but exploitable kernel driver to gain ring-0 access — leave a signature here. Exclude Microsoft-signed drivers and what remains is a short list worth reviewing individually. Understanding how to triage severity in vulnerabilities applies here too: not all driver loads are equal, and signature-based filtering helps prioritize.

Watch Sysmon itself

Attackers who are aware of Sysmon go after Sysmon. Alert on event ID 4 (service stopped or started unexpectedly), event ID 16 (configuration changed), and event ID 255 (internal errors). None of these can be filtered, they generate almost no baseline volume, and any unplanned occurrence deserves immediate investigation. If your SIEM stops receiving Sysmon events from an endpoint, that silence is itself a signal.

What is Sysmon event ID 29, and when should you use it?

Event ID 29, FileExecutableDetected, was introduced in Sysmon 15 in 2023. It fires when a file with a portable executable (PE) signature is created in a path covered by your configuration. It logs but does not block — ID 27 (FileBlockExecutable) is the blocking counterpart. [3]

The practical use case is straightforward: scope ID 29 to user profile directories and common staging paths (C:\Users\, C:\ProgramData\, C:\Windows\Temp\), and you get an alert every time a PE drops in a location where executables generally have no business appearing. That covers a large swath of malware delivery — dropper stages, second-stage payloads, tools written to disk before execution.

Two caveats. First, the event only fires for paths your configuration explicitly covers, so an attacker who drops a payload to an unconfigured path stays invisible. Scope broadly, then exclude legitimate software install paths to reduce noise. Second, ID 29 logs the PE creation, not execution — you still need ID 1 to see it run. They work together, not as substitutes.

Production XML configuration

The Sysmon XML below implements the Tier 1 + Tier 2 collection strategy described in this guide. It is a starting point — your environment will need tuning, especially for the include-based Tier 2 rules. Before deploying to production, test against a representative sample of endpoints and measure per-event-ID volume for at least a week. Two community baselines incorporate years of tuning and are worth reviewing: SwiftOnSecurity's sysmon-config for a well-commented single-file deployment, and Olaf Hartong's sysmon-modular for modular rules annotated with ATT&CK technique IDs. [4]

<!-- Production Sysmon baseline config — UnpanicTech 2026-10-24 -->
<Sysmon schemaversion="4.90">

  <!-- Collect SHA256 + IMPHASH for threat intel matching -->
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>

  <!-- Archive directory for ID 23; monitor its size -->
  <ArchiveDirectory>C:\Sysmon</ArchiveDirectory>

  <EventFiltering>

    <!-- TIER 1 — Collect with light exclude rules -->

    <!-- ID 1: Process creation — exclude noisy but benign child processes -->
    <ProcessCreate onmatch="exclude">
      <Image condition="image">svchost.exe</Image>
    </ProcessCreate>

    <!-- ID 6: Driver loads — exclude Microsoft-signed -->
    <DriverLoad onmatch="exclude">
      <Signature condition="contains">microsoft</Signature>
      <Signature condition="contains">windows</Signature>
    </DriverLoad>

    <!-- IDs 8, 12, 13, 14 — collect everything -->
    <CreateRemoteThread onmatch="exclude" />
    <RegistryEvent onmatch="exclude" />

    <!-- IDs 19, 20, 21 — WMI persistence: collect everything -->
    <WmiEvent onmatch="exclude" />

    <!-- ID 22 — DNS queries -->
    <DnsQuery onmatch="exclude" />

    <!-- ID 25 — Process tampering: collect everything -->
    <ProcessTampering onmatch="exclude" />

    <!-- TIER 2 — Include-only rules (scope carefully) -->

    <!-- ID 3: Network connections — exclude browser churn -->
    <NetworkConnect onmatch="exclude">
      <Image condition="image">chrome.exe</Image>
      <Image condition="image">msedge.exe</Image>
      <Image condition="image">firefox.exe</Image>
    </NetworkConnect>

    <!-- ID 10: Process access — LSASS only to start -->
    <ProcessAccess onmatch="include">
      <TargetImage name="technique_id=T1003.001"
                   condition="image">lsass.exe</TargetImage>
    </ProcessAccess>

    <!-- ID 11: File creation — autostart and staging paths only -->
    <FileCreate onmatch="include">
      <TargetFilename condition="contains">\Start Menu\Programs\Startup</TargetFilename>
      <TargetFilename condition="contains">\AppData\Local\Temp</TargetFilename>
      <TargetFilename condition="end with">.ps1</TargetFilename>
      <TargetFilename condition="end with">.hta</TargetFilename>
    </FileCreate>

    <!-- ID 15: NTFS stream hash — mark-of-the-web -->
    <FileCreateStreamHash onmatch="exclude" />

    <!-- IDs 17, 18: Pipe events — exclude known-good -->
    <PipeEvent onmatch="exclude">
      <PipeName condition="begin with">\PIPE\svchost</PipeName>
    </PipeEvent>

    <!-- TIER 3 OPTIONAL -->

    <!-- ID 26: File delete detected (no archive) -->
    <FileDeleteDetected onmatch="exclude" />

    <!-- ID 29: Executable drops in user/temp paths -->
    <FileExecutableDetected onmatch="include">
      <TargetFilename condition="begin with">C:\Users\</TargetFilename>
      <TargetFilename condition="begin with">C:\ProgramData\</TargetFilename>
      <TargetFilename condition="begin with">C:\Windows\Temp\</TargetFilename>
    </FileExecutableDetected>

    <!-- Suppress -->
    <ProcessTerminate onmatch="include" />
    <ImageLoad      onmatch="include" />

  </EventFiltering>
</Sysmon>

Sysmon vs. Windows Security event log — what each covers

A question that comes up regularly: if you have Sysmon, do you still need the Windows Security event log? Yes. They cover different ground and neither replaces the other.

Sysmon gives you execution-level telemetry: what processes ran, what they loaded, what network connections they made, what registry keys they touched, and what files they created. The Security event log gives you identity and authentication telemetry: logon events (4624/4625), account management (4720, 4732), privilege use (4672), and object access auditing. An investigation without Sysmon leaves gaps in execution visibility. An investigation without Security log events leaves gaps in identity chain reconstruction. You need both, and they need to be centralized — an attacker with local admin on an endpoint can clear both channels locally. [1]

The SOC tooling question — whether you are running an EDR, XDR, or MDR — also shapes how much you lean on Sysmon. Mature EDR platforms collect much of this telemetry natively and may make some Sysmon event types redundant. Sysmon still has value in EDR-covered environments for cross-platform detection rules (Sigma, for example, targets Sysmon field names), for environments where EDR is partially deployed, and for situations where vendor-specific telemetry formats create SIEM integration friction.

Strategic implications

Sysmon is not a product you deploy and forget. It is detection infrastructure — and the same things that make it valuable also make it a target. An attacker who removes Sysmon or modifies its configuration silently has degraded your visibility without you knowing. Treating events 4, 16, and 255 as priority alerts, and building a fleet health dashboard that flags endpoints that stop sending Sysmon telemetry, are not optional hardening steps; they are fundamental to the system working as intended.

The built-in Windows 11 and Windows Server 2025 Sysmon integration changes the deployment calculus but does not change the operational one. Getting Sysmon on endpoints is easier; keeping it configured correctly, centralized, and monitored is still your job. A Sysmon deployment without centralized log forwarding, version-controlled configuration management, and a baseline of what normal looks like per event type is not a detection capability — it is a log file that nobody reads.

Start from a community baseline (sysmon-modular or SwiftOnSecurity's config), get the Tier 1 events flowing to your SIEM, instrument the tamper canaries, and baseline volume per event type before expanding to Tier 2. The temptation to enable everything immediately is real, but the result is a firehose that analysts learn to ignore. A smaller, well-curated collection that generates high-fidelity alerts is worth more than comprehensive coverage that buries signal in noise. Sysmon rewards careful configuration — and punishes careless deployment with exactly the kind of alert fatigue that lets real threats slip through.

Sources & References

1. Microsoft Sysinternals — Sysmon official documentation (Mark Russinovich and Thomas Garnier, updated June 2026)
2. Microsoft — Native Sysmon in Windows 11 and Windows Server 2025 overview
3. BleepingComputer — Microsoft Sysmon 15 adds FileExecutableDetected (Event ID 29)
4. Olaf Hartong — sysmon-modular: modular Sysmon config with MITRE ATT&CK annotations (GitHub)
5. SwiftOnSecurity — sysmon-config: production-ready single-file Sysmon baseline (GitHub)

© 2026 UnpanicTech. Published: 2026-10-24. Last reviewed: 2026-10-24.