Windows Event ID Reference
A searchable reference for the Windows Event IDs that matter to defenders and admins — logon, account, Kerberos, process, service, task, PowerShell, and Sysmon events, with logon-type and failure-code tables and a ready-to-copy Get-WinEvent query for each.
Search by event ID, title, or keyword, then filter by channel, category, and
criticality. Click any row to expand its detail — sub-code tables, the security
relevance, and a Get-WinEvent query you can copy.
| id | channel | category | title | criticality |
|---|
No events match those filters.
reading the Windows event logs
Where the events live
Windows scatters its logs across many channels. The ones that matter most for security work:
- Security — logon, account management, Kerberos, process creation, object access, audit-policy changes. Most of this only appears if the matching Advanced Audit Policy subcategory is enabled.
- System — service installs (7045), service state, clean and dirty shutdowns.
- Windows PowerShell (classic) and Microsoft-Windows-PowerShell/Operational — engine starts and, crucially, script block logging (4104), which captures the actual code run even when it never touches disk.
- Microsoft-Windows-Sysmon/Operational — if you deploy Sysmon, by far the richest process, network, and injection telemetry Windows can give you.
- Operational channels for Defender, Task Scheduler, Terminal Services (RDP), AppLocker, and the Firewall.
Turn the auditing on first
Most Security-log events are silent until you enable them. Configure Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration (via GPO for a domain). The high-value switches: Audit Process Creation (4688) — and separately enable "Include command line in process creation events" — plus Logon, Account Management, and Kerberos auditing. For PowerShell, enable Module Logging and Script Block Logging under Administrative Templates.
Reading a logon (4624 / 4625)
The Logon Type is the first thing to check: type 2 is at the
keyboard, type 3 is from the network, type 10 is RDP, and type 9 is
runas /netonly — a favourite for using stolen credentials without a
full logon. On a failure (4625), the Status / Sub Status code
says exactly why: a wrong password (0xC000006A) reads very
differently from a username that does not exist (0xC0000064), and a
flood of the latter is user enumeration.
Querying from PowerShell
Every entry here carries a ready Get-WinEvent query. The general
shape:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)}Add | Select-Object TimeCreated, Id, Message to skim results, or
.Properties to pull individual data fields. -FilterHashtable
filters inside the log engine, so it stays fast even on busy Security logs where
Where-Object would crawl.
Accuracy & scope
These entries are curated against Microsoft's auditing documentation, the Sysmon schema, and the PowerShell/Defender operational channels. IDs are unique per channel — the same number (for example 25) means different things in Sysmon versus Terminal Services, so always read the channel alongside the ID. This is a focused reference for the events defenders and admins actually hunt in, not an exhaustive catalogue of every ID Windows can emit.