Sysmon Event IDs Explained: The Ones That Matter

Sysmon writes dozens of event types, and a beginner who opens the log sees a wall of numbers. The trick is to learn a small set of event IDs very well and know what attacker behaviour each one reveals. This guide walks through the Sysmon event IDs that matter most, with example queries and the ATT&CK techniques they help you detect.

This is Part 12 of 30 in the Blue Team Learning Path. Part 11 showed how to install and tune Sysmon. Now we learn to read what it produces.

Key takeaways

• Event 1 (process creation) is the most useful Sysmon event. Learn its fields first.
• Events 3, 11, 13 and 22 add network, file, registry and DNS context to the same process.
• Events 8 and 10 are strong signals for injection and credential theft, but need tuning.
• Always pivot using the ProcessGuid field, which ties events from one process together.

How Sysmon event IDs are organised

According to the Microsoft Sysmon documentation, events 1 through 29 each describe one kind of activity, and event 255 reports an error. They all sit in the Microsoft-Windows-Sysmon/Operational log. A useful way to group them is by what the attacker is doing:

• Execution: 1 (process creation), 5 (process terminated), 7 (image loaded).
• Network: 3 (network connection), 22 (DNS query).
• Files: 2 (file creation time changed), 11 (file create), 15 (file stream hash), 23 and 26 (file delete).
• Registry: 12 (object create and delete), 13 (value set), 14 (key and value rename).
• Memory and processes: 8 (CreateRemoteThread), 10 (process access), 25 (process tampering).
• Named pipes and WMI: 17 and 18 (pipes), 19, 20 and 21 (WMI).
• Sysmon itself: 4 (service state changed), 16 (configuration change), 255 (error).

Event 1: process creation

This event records every process that starts, if your config allows it. The fields that matter most are:

• Image: the program that ran.
• CommandLine: the arguments. This is where encoded PowerShell, download commands and odd switches show up.
• ParentImage and ParentCommandLine: who started it. A document reader starting a shell is a classic alert.
• User: the account that ran it.
• Hashes: the file hash, ready to look up.
• ProcessGuid: a unique ID for this process instance, used to link other events.

Example: show process creation events where PowerShell ran with an encoded command switch.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} -MaxEvents 500 |
  Where-Object { $_.Message -match 'powershell' -and $_.Message -match ' -enc' } |
  Select-Object TimeCreated, Message -First 5

This maps to command and scripting interpreter abuse, technique T1059.001 on the ATT&CK site. Parsing the XML fields instead of matching the message text is more reliable, and our Get-WinEvent guide shows how.

Event 3: network connection

Event 3 ties a connection to a process, with source and destination address, port and the program name. Windows’ own logs rarely tell you which process made a connection, so this is a major upgrade. Use it to answer: why is a document reader, a script engine or a system utility connecting to the internet? Combine it with event 1 through the ProcessGuid to see the full command line of the process that made the connection. It pairs well with packet analysis from Part 9: the capture shows the traffic, Sysmon shows the process behind it. Event 3 is noisy, so most configurations log only selected processes or exclude known services.

Event 22: DNS query

Event 22 records the domain a process asked for. It is a cheap way to see which program contacted a suspicious domain, even if the connection later failed. Watch for rare domains, very long random-looking names and scripting engines performing lookups.

Events 11, 13 and 12 to 14: files and registry

Event 11 logs file creation, which shows dropped payloads and scripts. Events 12, 13 and 14 cover registry changes. A very common persistence trick is adding a program to a Run key so it starts at logon, which is technique T1547.001 on the ATT&CK site. Event 13 (value set) on the Run key paths reveals it. Because these events are frequent, write narrow rules for specific keys and folders: the Run keys, the Startup folder and temporary directories.

Event 7: image loaded

Event 7 shows DLLs loaded by processes. It is very noisy, so most teams leave it off or filter it heavily. When enabled, it helps spot unsigned or unusual DLLs loaded into trusted programs, and DLL search-order abuse.

Events 8 and 10: injection and credential theft

Event 8 (CreateRemoteThread) records one process starting a thread in another. That is a classic sign of process injection, technique T1055 on the ATT&CK site. Event 10 (process access) records one process opening another, and it is how you detect processes reading the memory of the Windows security process lsass.exe, the target of credential dumping (T1003.001, LSASS Memory). Both fire legitimately from security tools and system components, so start by alerting only on access to lsass.exe from unexpected programs, then tune the exclusions one by one.

Events 19, 20 and 21: WMI persistence

These events record WMI event filters, consumers and the bindings between them. Attackers use WMI event subscriptions for stealthy persistence, technique T1546.003. Because legitimate use is rare in most environments, these events are high-value even on a small budget. Log them all and review every hit.

Events 17 and 18: named pipes

Named pipes are used for local and remote communication, and many attack frameworks create pipes with recognisable names. Logging pipe creation and connection lets you hunt for those artifacts, which sit in the middle of the Pyramid of Pain from Part 7. Expect to tune, since Windows and many programs create pipes constantly.

Events 4, 16, 25 and 255: when Sysmon itself changes

Do not ignore the housekeeping events. Event 4 reports that the Sysmon service started or stopped. Event 16 reports a configuration change. Event 25 reports process tampering, a sign that a process image was changed in memory. Event 255 is an error. An attacker who disables or reconfigures Sysmon leaves these traces, so alert on any unexpected stop or configuration change.

Pivoting with ProcessGuid

The ProcessGuid field is the most useful thing in Sysmon. Take one suspicious process creation event and note its GUID. Then search every other Sysmon event for the same value:

$g = '{PASTE-GUID-HERE}'
Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' |
  Where-Object { $_.Message -like "*$g*" } |
  Select-Object TimeCreated, Id | Sort-Object TimeCreated

The result is a timeline for one process: when it started, which files it created, which hosts it contacted and what registry keys it touched. That is the skeleton of an incident report.

Starter detection ideas by event ID

Use this list as a menu for your lab. Each idea needs testing and tuning against your own baseline before you trust it.

• Event 1: Office or PDF programs starting a command shell, script host or PowerShell. Encoded or hidden-window PowerShell. Common system tools launched from user folders.
• Event 3: script engines and system utilities making outbound connections to the internet.
• Event 22: a process that normally never uses the network resolving a rare domain.
• Event 13: new values under the Run keys written by unexpected processes.
• Event 10: any process other than your security tools opening lsass.exe.
• Event 8: remote thread creation from user-writable locations.
• Events 19 to 21: any new WMI subscription.
• Events 4 and 16: Sysmon stopped or reconfigured outside a change window.

Notice how most ideas describe behaviour rather than a file name. That is deliberate, and it is how you climb the pyramid we discussed earlier.

Parsing event fields properly

Matching words in the message text works for quick checks, but it is fragile. For anything you will reuse, read the XML fields. Each Sysmon event carries named data items such as Image, CommandLine and DestinationIp. Convert the event to XML, then read the item you need by name. This lets you compare a field exactly, count by value and feed clean data to a SIEM. In Part 13 you will do the same thing with Splunk field extraction, and in Part 14 with Wazuh decoders.

Also remember volume. A busy workstation can produce thousands of events per hour. Before enabling a new event type in production, test it on a lab machine from your home lab, count events per hour and decide whether you can afford to store them.

Practice: generate and find each event

1. Open a command prompt from Explorer and run a harmless command. Find event 1 and note the parent process.
2. Browse to a website. Find events 3 and 22 for the browser.
3. Create a text file on the desktop. Find event 11.
4. Add a harmless test value under your own user Run key, then delete it. Find event 13.
5. Run sysmon64 -c with your config again. Find event 16.

After this ten-minute exercise you will recognise the layout of each event, which makes real alerts far less intimidating.

Common pitfalls

• Alerting on everything. Event 10 and event 7 will bury you if you do not scope them.
• Trusting message text. Field-level parsing is more reliable than string matching.
• Forgetting ProcessGuid. Process IDs get reused, GUIDs do not.
• Ignoring event 16 and event 4. Someone tampering with Sysmon is a high-value signal.
• Treating an ATT&CK ID as a guarantee. An event only shows telemetry, not that an attack technique happened.
• Not syncing clocks. Mixed time zones make timelines wrong.

Frequently asked questions