Sysmon Event IDs: All 30 Explained, and How to Turn Them On

Sysmon (System Monitor) is a free Microsoft Sysinternals service and driver that writes process, network, file, registry and DNS activity to the Windows event log. Version 15.22 defines 30 event IDs: 1 through 29, plus 255 for its own errors. Which of those you actually see depends on the configuration file Sysmon was installed with.

Microsoft's Sysmon page describes every event. This guide adds three things per ID that matter when you decide what to collect: the configuration tag that controls it, whether the SwiftOnSecurity configuration keeps it on, and the closest event in the native Security log for hosts without Sysmon. We counted the event headings on Microsoft's page and the rules in that configuration file on October 26, 2026. If you want the one-line version for Security, System and Sysmon together, the Windows event IDs cheat sheet has it.

What is Sysmon used for?

Sysmon fills the gaps that Windows auditing leaves. Microsoft describes it as a service plus a device driver that stays resident across reboots and logs process creation with the full command line of both the process and its parent, file hashes, network connections, driver and DLL loads, and raw disk reads. It runs as a protected process and starts logging early in boot.

Two things it does not do, in Microsoft's words: it "does not provide analysis of the events it generates, nor does it attempt to hide itself from attackers." You still need a SIEM, or an analyst in Event Viewer, to turn the events into detections, and an attacker on the host can see that it is there.

In a SOC, Sysmon earns its place in three jobs:

• Process trees. Every event carries a ProcessGuid that stays unique even when Windows reuses process IDs, so you can chain a parent, its children and everything they did. Event 1's command line and parent command line are how you spot living-off-the-land abuse of built-in binaries.
• Attribution. A firewall log says a host talked to an address. Events 3 and 22 say which executable did it.
• Persistence. Registry Run keys (12 to 14), WMI subscriptions (19 to 21) and files dropped into startup folders (11) are the classic persistence spots, and Sysmon logs all three.

Two versions exist in 2026. The standalone download from Sysinternals is the one most guides cover; its page now lists Windows 11 and Windows Server 2019 or later as supported. Built-in Sysmon is, per Microsoft's overview, "an optional Windows feature on Windows 11 and Windows Server 2025", configured with the same sysmon -i, -c and -u commands. Microsoft lists two differences that will bite you. First, "standalone Sysmon and built-in Sysmon can't be enabled on the same device at the same time", so the standalone version must be uninstalled first. Second, built-in Sysmon localizes the rendered message text while the XML event data stays the same in every language. A parser that reads message text instead of XML will break on non-English hosts.

Where Sysmon writes its events

Events go to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational, which tools address as Microsoft-Windows-Sysmon/Operational. Microsoft notes that "event timestamps are in UTC": the UtcTime field inside the event is UTC, while Event Viewer's list shows the record time in your local time zone. When a Sysmon timeline and a Security log timeline disagree by exactly your UTC offset, that is why.

To pull the latest events from PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 20 |
  Select-Object TimeCreated, Id, Message

If you are new to channels, .evtx files and exporting a log from a host, start with how to read Windows event logs; everything there applies to the Sysmon channel too.

All 30 Sysmon event IDs

Read the columns this way. Config tag is the element inside EventFiltering that controls the event, from Microsoft's filter table. SwiftOnSecurity config is what sysmonconfig-export.xml (source version 74, dated 2021-07-08) does with it; the rule counts come from parsing the file with comments stripped. Closest Security log event is our mapping, not Microsoft's. None of them is a drop-in replacement, and most only appear if you enable a specific audit subcategory or put a SACL on the object.

The Security event names come from Microsoft's audit reference pages for 4688, 5156, 4657, 4663 and 5145. WMI does keep its own WMI-Activity log outside the Security channel, but nothing in the Security log covers 19 to 21.

The IDs that change an investigation

These are the IDs you pivot on when you need to answer "what ran, and what did it do" on a Windows host.

Event ID 1: process creation

Process-tree work starts here. Beyond what the native 4688 records, it gives you the hashes set in HashAlgorithms, the parent's full command line, OriginalFileName for renamed binaries, and the ProcessGuid you pivot on. Microsoft's own example install hashes with SHA1 and does no network monitoring; SwiftOnSecurity's config sets md5,sha256,IMPHASH. Check the Hashes field on one event before you write a hash-based rule, because a field that only carries SHA1 will silently fail a SHA256 match.

Event ID 3: network connection

Microsoft says this event "is disabled by default". SwiftOnSecurity turns it on in what its own comment calls "a very conservative approach to network logging, limited to only extremely high-signal events": a list of processes (PowerShell, rundll32.exe, regsvr32.exe among them) and admin ports such as 22, 23 and 3389. A connection from a process outside that list never reaches your SIEM, so "no Event 3" does not mean "no connection".

Event ID 10: process access

The credential-theft event. When a tool opens lsass.exe to read its memory, Event 10 records the source, the target and the GrantedAccess mask. Microsoft warns it "can generate significant amounts of logging" when diagnostic tools repeatedly open processes, and recommends filters that remove expected access. That is the reason SwiftOnSecurity ships it empty. If you add one thing on top of that config, make it a targeted Event 10 on LSASS (the config example further down shows how).

Events 17 and 18: named pipes

Pipes are how a lot of post-exploitation tooling talks between processes. SwiftOnSecurity's include list targets PsExec clones (paexec, remcom, csexec), credential dumpers (\lsadump, \cachedump) and pipe names it labels as Cobalt Strike defaults, such as names starting with \postex_. Those defaults are exactly what the Cobalt Strike beacon investigation playbook tells you to look for.

Event ID 22: DNS query

Event 22 logs every lookup a process makes, "whether the result is successful or fails, cached or not," on Windows 8.1 and later. It is the event that puts a binary name next to a domain, which is the first thing you need when you investigate DNS tunneling. It is also the reason SwiftOnSecurity's header warns that DNS monitoring "is extremely noisy" and suggests beginners remove the section. The config ships with 209 exclusions for it.

Events 23 and 26: file deletion

Both log a deleted file. Event 23 also copies the file into ArchiveDirectory (C:\Sysmon by default), and Microsoft warns that directory "might grow to an unreasonable size", pointing to 26 as the log-only alternative. Use 23 only with tight rules, for example deleted executables or scripts from user-writable paths, and 26 for broad coverage.

Event ID 25 and events 27 to 29: the newer ones

Event 25 fires when Sysmon detects process image tampering such as hollowing or herpaderping. Events 27 and 28 are the only ones where Sysmon blocks something instead of just recording it: 27 blocks creation of executable files and 28 blocks file shredding. Event 29 logs new executables without blocking them. Every one of them arrived after the configs most people copied were written, which is the problem in the next section.

What SwiftOnSecurity's config turns on and off

SwiftOnSecurity/sysmon-config has 5,708 stars on GitHub and is still the config many home lab guides point you to. GitHub's API shows its last commit on the default branch on October 17, 2021. The file declares schemaversion="4.50" and requires "Sysmon version 13 or higher". For comparison, the sample config on Microsoft's current page uses schemaversion="4.82". What that means in practice, counted from the file:

• Off on purpose: 7, 9 and 10 have an include filter with no rules. The file says so itself: "Using "include" with no rules means nothing in this section will be logged."
• On without filters: 19 to 21 use an empty exclude, which logs every WMI filter, consumer and binding.
• The noisy one: 22, with 209 exclusions and a header note to drop it if you are starting out.
• Mislabelled: the section headed "SYSMON EVENT ID 23 : FILE DELETE" contains a commented-out ClipboardChange block, not a FileDelete one. There is no working rule for 23 anywhere in the file.
• Commented out: 24 (clipboard) and 25 (process tampering).
• Missing: no tag for 26, 27, 28 or 29.

The config was careful work for Sysmon 13, and most of its 138 process exclusions and 114 registry includes still make sense. Installed on Sysmon 15.22, though, it has no rules for process access, tampering or file deletion, and what the driver does with the untagged IDs is something to check with sysmon -c.

The maintained alternative is olafhartong/sysmon-modular, last committed on October 14, 2026. Its README credits SwiftOnSecurity's config as the foundation it was built on, and its release builds profiles for Sysmon 15.21 and three older versions. The default "Balanced" profile we downloaded declares schemaversion="4.91" and differs on these IDs:

Whichever you pick, the README's own warning applies: "Every configuration is a starting point." Test it in a lab first. The cybersecurity home lab guide builds one with Sysmon and a SIEM and gives you attacks to check it against.

The empty-filter trap

When Sysmon "isn't logging X", check these four filtering rules from Microsoft's docs before anything else:

1. onmatch="include" with no rules logs nothing. That is how SwiftOnSecurity turns events off.
2. onmatch="exclude" with no rules logs everything. That is how it turns 19 to 21 fully on.
3. Exclude beats include. When a tag has both, "exclude matches take precedence," so a broad exclusion can silently cancel your new include rule.
4. Don't rely on the default AND/OR. Microsoft's page says rules on different fields "behave as AND conditions", and a few paragraphs later that "within a rule, filter conditions have OR behavior." If a match needs two conditions at once (this image and this command line), say so explicitly with a Rule or RuleGroup element set to groupRelation="and", the way sysmon-modular does throughout its config.

There is a fifth trap in exclusions themselves. SwiftOnSecurity's DNS section warns: "If you exclude microsoft.com, someone could register malware-microsoft.com and it wouldn't be logged." Use end with and a leading dot (.microsoft.com) or is, never contains, when you exclude domains or paths.

When a config does not mention a tag at all, as with 26 to 29 in SwiftOnSecurity's file, don't assume what Sysmon does with that event. Run sysmon -c with no file to dump the configuration the driver is actually using, and check.

How to turn a Sysmon event ID on or off

Every change goes through the configuration file and one command. This fragment turns on Event 10 for LSASS only and adds two safe DNS exclusions. Run sysmon -s to print the schema your binary supports and match the schemaversion value to it; 4.82 is the value in Microsoft's own sample.

<Sysmon schemaversion="4.82">
  <HashAlgorithms>sha256</HashAlgorithms>
  <EventFiltering>
    <RuleGroup name="" groupRelation="or">
      <ProcessAccess onmatch="include">
        <TargetImage condition="end with">\lsass.exe</TargetImage>
      </ProcessAccess>
    </RuleGroup>
    <RuleGroup name="" groupRelation="or">
      <DnsQuery onmatch="exclude">
        <QueryName condition="end with">.windowsupdate.com</QueryName>
        <QueryName condition="end with">.microsoft.com</QueryName>
      </DnsQuery>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Legitimate software will hit this include too, starting with your own security agents. Add exclude rules for the SourceImage values you actually see in your environment, not ones copied from someone else's.

The commands, from Microsoft's usage section:

Neither install nor uninstall needs a reboot. A configuration change is logged as Event 16. Alert on it, because an unscheduled config change can mean someone is switching your logging off.

Sysmon vs the Security log

If a host has no Sysmon, the table above is your fallback map, with three gaps.

Process creation. 4688 records the new process and its creator, but Microsoft's 4688 reference says "by default Process Command Line field is empty" until you enable the "Include command line in process creation events" policy. Even then it has no hashes and no parent command line.

What only Sysmon sees. DNS queries per process, named pipes on the local machine, process tampering, raw disk reads, remote threads and DLL loads have no Security log event at all. Script content is a separate gap that Sysmon doesn't fill either: Event 1 shows powershell.exe -EncodedCommand and a base64 blob, while the decoded script lives in PowerShell's own Event 4104.

What depends on SACLs. File and registry coverage in the Security log (4656, 4657, 4660, 4663) only exists for objects whose SACL asks for it. Sysmon's 11 to 14 apply rules by path across the whole machine instead.

Where you can, collect both: the Security log for authentication, account changes and log clearing, Sysmon for execution, network attribution and persistence. A Sigma rule, for example, declares a logsource such as category: process_creation, and your backend decides whether that means Sysmon Event 1 or Security 4688 (more in how Sigma rules work).

Reading one Event 22 end to end

Here is what a suspicious DNS event looks like in XML, with the field names Sysmon uses for Event ID 22 (as listed in the OSSEM data dictionary). The domain uses the reserved .example top-level domain and the address is from a documentation range.

<!-- Simulated example generated by SOCSimulator Research -->
<Event>
  <System>
    <Provider Name="Microsoft-Windows-Sysmon" />
    <EventID>22</EventID>
    <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
    <Computer>WS01.corp.example</Computer>
  </System>
  <EventData>
    <Data Name="RuleName">-</Data>
    <Data Name="UtcTime">2026-10-26 09:14:07.512</Data>
    <Data Name="ProcessGuid">{6f1d2a8c-e3b1-671c-4c02-000000003a00}</Data>
    <Data Name="ProcessId">7316</Data>
    <Data Name="QueryName">cdn-sync.update-check.example</Data>
    <Data Name="QueryStatus">0</Data>
    <Data Name="QueryResults">::ffff:203.0.113.45;</Data>
    <Data Name="Image">C:\Windows\System32\rundll32.exe</Data>
    <Data Name="User">CORP\l.ortega</Data>
  </EventData>
</Event>

How to work it:

1. The process is the finding. rundll32.exe loads DLLs; it rarely needs to resolve a domain nobody in your environment has seen. A lookup from chrome.exe to the same name would be a different, weaker lead.
2. Pivot on ProcessGuid, not ProcessId. Pull Event 1 with the same GUID to get the command line (which DLL, which export) and the parent. If the parent is an Office application or a script host, you now have an execution chain.
3. Check whether the lookup became a connection. QueryResults gives you 203.0.113.45. SwiftOnSecurity's Event 3 rules include rundll32.exe, so on that config you should find an Event 3 to that address from the same GUID. With a different config, its absence proves nothing.
4. Widen to the fleet. Search Event 22 for the same QueryName across all hosts, and for any rundll32.exe DNS activity in the last 30 days.

The same pivot as a PowerShell query on one host:

$guid = '{6f1d2a8c-e3b1-671c-4c02-000000003a00}'
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -FilterXPath "*[System[(EventID=1 or EventID=3 or EventID=22)]] and *[EventData[Data[@Name='ProcessGuid']='$guid']]" |
  Select-Object TimeCreated, Id, Message

The chain (process, DNS, connection, then the parent) works the same whether the data sits in Event Viewer or a SIEM. If you want to run it against a live alert queue, the Cobalt Strike beacon detection operation in SOCSimulator starts from that kind of foothold.