Windows Security Event IDs worth recognizing on sight
Windows generates a lot of security events, and most of them don't matter for day-to-day triage. This is a curated set — not exhaustive, sourced from Microsoft's own auditing documentation — of the ones that come up constantly in real investigations, organized by what they're actually for.
Logon activity
- 4624 — An account was successfully logged on. The baseline event for tracking who logged on, when, from where, and via which logon type (interactive, network, RDP, service, and others — the Logon Type field distinguishes these). Volume is high on domain controllers, low on a single workstation.
- 4625 — An account failed to log on. Failed-logon volume and pattern (many accounts, one source; one account, many sources) is the standard signal for both brute-force and password-spray attempts.
- 4648 — A logon was attempted using explicit credentials. Fires when a process
explicitly supplies different credentials than the one it's running as — common with
RunAs, scheduled tasks, and legitimately common in admin workflows, but also how lateral movement using stolen credentials often shows up. - 4672 — Special privileges assigned to new logon. Fires when an account with administrator-equivalent rights logs on. Correlating this with 4624 tells you not just that someone logged on, but that they logged on with elevated privileges — a meaningfully different signal.
Process and service activity
- 4688 — A new process has been created. Fires on every process start when process creation auditing is enabled, and with command-line auditing also turned on, includes the full command line — one of the highest-value events for reconstructing what actually ran during an incident, and high-volume enough that most environments need real filtering logic before it's usable at scale.
- 4697 — A service was installed on the system. Malware and legitimate persistence mechanisms both frequently install a service to survive reboot; an unexpected 4697 is worth a look regardless of which one it turns out to be.
Account and group management
- 4720 — A user account was created. Straightforward, but worth watching for creation outside expected change windows or naming conventions — attacker-created accounts are a common persistence mechanism.
- 4738 — A user account was changed. Fires on modification to an existing account (password reset outside self-service, attribute changes, and more) — broad, so it's usually paired with other context rather than alerted on alone.
- 4732 — A member was added to a security-enabled local group. Especially worth watching for additions to the local Administrators group — a common privilege-escalation and persistence step.
Kerberos authentication
- 4768 — A Kerberos authentication ticket (TGT) was requested. The starting point of Kerberos authentication in an Active Directory environment — every interactive domain logon generates one.
- 4769 — A Kerberos service ticket was requested. Requested when accessing a specific service. A high volume of 4769 events requesting tickets for many different services in a short window, especially for accounts with Service Principal Names, is the classic signature investigators look for when checking for Kerberoasting.
Anti-forensics
- 1102 — The audit log was cleared. One of the most direct "someone is covering their tracks" signals in the entire Windows event catalog — legitimate log-clearing happens, but it should be rare, deliberate, and traceable to a known maintenance action, not something that shows up unexplained.
Why the raw event alone is rarely the whole story
Almost every event above answers "what happened" but not "was it fine." A 4624 with a recognized account from an expected source is routine; the same event ID for the same account from an unfamiliar country at 3 AM is a different story entirely — the event ID tells you what category of thing to look at, not whether to be alarmed. That's the reason SIEM correlation rules exist rather than alerting on raw event IDs directly: the signal is almost always in the pattern and context, not the bare fact that an event fired at all.
Sources: Microsoft Learn, Audit Logon (4624, 4625, 4648); Event 4672; event descriptions for 4688, 4697, 4720, 4732, 4738, 4768, 4769, and 1102 cross-checked against their official Microsoft Learn event-reference pages.