Windows Event ID

Why it matters

Most of what happens on a Windows estate is recorded — the problem is volume, not absence. The Event Log emits millions of entries, and each is stamped with an Event ID that says what kind of thing happened. Detection engineering is, to a large degree, knowing which of those numbers correspond to attacker behaviour and building alerts around them. Without that map, the log is noise; with it, an intrusion leaves a legible trail.

It is the raw material under nearly every SOC alert on Windows. A brute-force shows up as a burst of 4625 (failed logon) followed by a 4624 (success); suspicious tooling shows up as 4688 (process creation) with a telling command line; fileless attacks surface in 4104 (PowerShell script-block logging). Those numbers are the anchors a Sigma rule keys on, so the detection travels to any SIEM.

Channels, key IDs and Sysmon

Events live in channels — Security, System, Application, and dedicated operational logs like Microsoft-Windows-PowerShell/Operational. The ones worth memorising:

• 4624 / 4625 — successful / failed logon. The logon type field is the tell: type 3 is network, type 10 is RemoteInteractive (RDP), type 2 is at the keyboard.
• 4688 — a new process started (enable command-line auditing and you get the full command). 4104 — PowerShell script-block logging, which captures the actual script even when it is obfuscated or -enc-encoded.
• 4672 (special privileges assigned), 4720 (user account created), 7045 (a service installed) — classic persistence and privilege signals.

Native auditing has gaps, and that is where Sysmon (a free Sysinternals driver) comes in: it adds a richer, separate channel with events the base OS does not give you well — process creation with hashes (Event ID 1), network connections (3), image loads (7), and more — all driven by an XML config you tune. Sysmon is not a different concept, it is the same event-log model extended with the fields detection engineers actually want.

Common misreadings

• Default auditing misses a lot. Command-line in 4688, PowerShell 4104 and most Sysmon events are off until you enable them — "we have the logs" is only true if the audit policy was set before the incident.
• The same ID is mostly benign. 4624 and 4688 fire constantly in normal use; the signal is in the fields (logon type, parent process, command line) and the pattern, not the number alone.
• Event IDs are namespaced by channel. Sysmon Event ID 1 is not Security Event ID 1 — always pair the ID with its log source in a rule.

Related terms

• Sigma — A Sigma rule is a detection written once, in a small YAML format, that describes what to look for in which kind of log — and is then converted into the query language of whatever SIEM you happen to run.
• IOA — An IOA describes what an attacker is doing rather than what they left behind — a sequence of actions such as "a document opens a shell that downloads and executes a file" — so it detects the technique regardless of which hash, IP or domain is used this time.
• LOLBin — A LOLBin (Living Off the Land Binary) is a legitimate, pre-installed system tool — certutil, mshta, rundll32 — that an attacker repurposes to download, execute or hide malicious activity, so nothing "new" ever touches disk.
• MITRE ATT&CK — MITRE ATT&CK is a public, curated catalogue of the behaviours real attackers use, organised so defenders can say "we saw T1059.001" instead of "some PowerShell thing".