Sysmon Event IDs Every SOC Analyst Should Know
The Sysmon Event IDs that actually catch attackers. A practical cheat sheet for SOC analysts on process, network, DNS, and persistence events.
EpicDetect Team
10 min read

Sysmon Event IDs Every SOC Analyst Should Know
Windows logs a lot. Sysmon logs the stuff that actually catches attackers.
If you've already got the standard Windows Event IDs down, Sysmon is your next move — it's the free Microsoft tool that fills the gaps native logging leaves wide open. And it's everywhere in detection engineering.
Here are the Sysmon Event IDs you'll actually use. Bookmark it.
Wait, What Is Sysmon?
System Monitor (Sysmon) is a free Windows tool from Microsoft's Sysinternals suite. You install it, point it at a config, and it starts writing rich, detailed events to a dedicated log.
Native Windows logging tells you that a process ran. Sysmon tells you the process, its full command line, its parent, the hash of the binary, and what it connected to.
That extra context is the difference between "something happened" and "here's exactly what happened." It's why nearly every detection lab and SOC uses it.
The Process IDs (The Heart of Sysmon)
If you learn nothing else, learn these.
- Event ID 1 — Process Creation. The single most valuable Sysmon event. It gives you the full command line, the parent process, the user, and the hash. This is where you catch winword.exe spawning powershell.exe, encoded commands, and living-off-the-land abuse. Most of your detections start here.
- Event ID 5 — Process Terminated. Less exciting, but useful for building a timeline of how long something ran when you pair it with Event ID 1.
- Event ID 10 — Process Access. Fires when one process opens a handle to another. The classic use: catching tools reading lsass.exe memory (credential dumping). If you see a weird process with GrantedAccess to LSASS, your day just got interesting.
The Network ID (Who Called Home?)
- Event ID 3 — Network Connection. Logs TCP/UDP connections with the source and destination IPs, ports, and the process that made the connection. This is how you tie a suspicious process to a command-and-control callout. Native Windows logging won't give you this cleanly — Sysmon does.
The DNS ID (Underrated, Very Useful)
- Event ID 22 — DNS Query. Logs the process that made a DNS request and what it resolved. Malware has to resolve its C2 domain somehow, and this catches it — often before the actual connection even happens. Great for spotting DGA (domain generation algorithm) beaconing.
The Persistence IDs (Did They Dig In?)
Attackers who want to survive a reboot leave fingerprints here.
- Event ID 11 — File Created. Watch for files dropped in suspicious locations — %TEMP%, %APPDATA%, startup folders. A binary written to a startup folder is a persistence red flag.
- Event ID 12 / 13 / 14 — Registry Events. Creation, value set, and rename of registry keys. The big one is anything touching Run keys (HKLM\...\CurrentVersion\Run) — the most common persistence trick in the book.
- Event ID 7 — Image Loaded. Logs DLLs being loaded into processes. Noisy, but essential for catching DLL side-loading and injection. Filter aggressively or it'll bury you.
The Advanced IDs (Injection & Tampering)
- Event ID 8 — CreateRemoteThread. Fires when a process creates a thread in another process. This is a hallmark of process injection — a legitimate process being hijacked to run malicious code.
- Event ID 15 — FileCreateStreamHash. Catches Alternate Data Streams, including the "Mark of the Web." Useful for spotting files that came from the internet trying to hide.
- Event ID 23 / 26 — File Delete. Attackers clean up after themselves. These events catch deletions — including files that were archived by Sysmon before removal, so you can recover what they tried to erase.
Reading Sysmon Like an Analyst
Here's the thing: memorizing IDs isn't the skill. Connecting them is.
A real detection chains them together:
- Event ID 1 shows winword.exe spawned an encoded PowerShell command
- Event ID 22 shows that PowerShell resolved a sketchy domain
- Event ID 3 shows it connected out to a raw IP on 443
- Event ID 12 shows it wrote a Run key for persistence
That's not four alerts. That's one story — the exact kind of story a real investigation is built from, and where detection engineering earns its keep.
Quick Tips for Working With Sysmon
1. The config is everything. A default Sysmon install is noisy garbage. Start with a well-tuned config (the SwiftOnSecurity or Olaf Hartong configs are the community standards) and tune from there.
2. Filter Event ID 7 and 3 hard. Image loads and network connections are the noisiest events. Without filtering, they'll drown out the signal.
3. Learn the parent-child pairs. Office apps spawning shells, services.exe spawning weird children — the relationships matter more than any single event.
4. Pair Sysmon with your SIEM. Sysmon generates the data; your SIEM queries turn it into detections. They're two halves of the same skill.
TL;DR – The Sysmon IDs That Matter
Event ID 1 (process creation) is the workhorse — command lines, parents, hashes. ID 3 catches network callouts, ID 22 catches DNS, IDs 11-14 catch persistence, and IDs 8/10 catch injection and credential access. Learn to chain them into a single story, not read them as isolated alerts.
---
FAQs
Is Sysmon free?
Yes, completely. It's part of Microsoft's Sysinternals suite. The only "cost" is the time to deploy and tune a good config.
Do I need Sysmon if I already have EDR?
Good EDR covers a lot of the same ground, but Sysmon is still the standard for learning, home labs, and environments without commercial EDR. Understanding Sysmon events makes you better at reading EDR telemetry too.
What's the single most important Sysmon Event ID?
Event ID 1 (process creation), no contest. The command line, parent process, and hash it captures are the foundation of most endpoint detections.
Where can I practice reading Sysmon-style events?
Any environment that shows you process trees and command lines. Story-driven investigations like endpoint practice scenarios put these events in the context of a real case, which sticks far better than a reference list.
---
Final thought: Native Windows logs tell you the door opened. Sysmon tells you who walked through, what they carried, and where they went. Learn to read it.
How EpicDetect Can Help
Reading about Sysmon events only gets you so far. If you want to actually trace a process chain through a real incident — not multiple choice, an actual case — Adventures drops you into a story-driven SOC investigation where exactly this kind of endpoint evidence is how you crack the case. Season 0 is completely free, no credit card required.
Want the fuller skill tree too? Head to the EpicDetect Atlas for structured lessons on detection engineering and endpoint forensics.
New here? Sign up and start for free.
Tags
Related Articles

From Zero to SOC Analyst: The Complete 90-Day Roadmap (2025 Edition)
A proven step-by-step plan to land your first SOC analyst role in 90 days. Includes free resources, hands-on labs, certification guidance, and a realistic study schedule that actually works.

Detection Engineering 101: What It Is, Why It Matters, and How to Break In
SOC analysts respond to alerts. Detection engineers build them. Here's what detection engineering actually is and how to get into one of blue team's fastest-growing roles.

Endpoint Investigation Practice: How to Read a Process Tree Like an Analyst
Free endpoint investigation practice for beginners. Learn how to read a real process tree, spot persistence mechanisms, and think like an analyst.

You Passed Security+. Here's Why You Still Can't Get Hired (And What to Do)
Security+ gets you considered, not hired. Here is the gap between knowing security and doing it, and how to close it without a job or another cert.