Windows Security Event Log Hunting Guide

Sysmon gets all the attention in hunting circles, and for good reason, but plenty of environments still don’t have it deployed everywhere, and plenty of the most important hunt leads live in native Windows Security Event Logs regardless of whether Sysmon is present at all. Authentication events, account management, privilege use—this is where identity-based attacks leave their footprints, and identity is where most real intrusions eventually go.

I’ve worked incidents where Sysmon coverage was patchy but Security Event Log auditing was solid, and the authentication trail alone told most of the story. Don’t treat this as the backup data source. Treat it as its own primary hunting surface.

Event ID 4624 and 4625: logon success and failure, but the type field is everything

Everyone knows to look at failed logons (4625) for brute-force patterns—a spike of failures against one account from one source is obvious enough that most SOCs have a detection for it already. The more interesting hunting happens in successful logons (4624), specifically the Logon Type field. Type 3 (network logon) showing up against a workstation that should only ever see Type 2 (interactive) or Type 10 (RDP) is a pattern worth building a baseline around per host role.

Say you’ve got a workstation used exclusively by one person sitting at the desk. That host should show almost entirely Type 2 and occasional Type 7 (unlock) logons. A sudden Type 3 network logon from a service account that’s never touched that machine before, especially outside business hours, is a lateral movement indicator that’s easy to build a detection for once you know what Type 3 traffic actually looks like on hosts that shouldn’t see it.

Event ID 4672 and 4688: privilege assignment and process creation without Sysmon

If Sysmon isn’t deployed on a given host, 4688 (process creation, native Windows) is your fallback—but only if command-line auditing is actually enabled via Group Policy, which it isn’t by default. This is worth checking across your fleet specifically, because I’ve seen environments assume they have command-line visibility through 4688 and discover during an actual incident that the setting was never turned on for half their servers.

Event ID 4672, special privileges assigned to new logon, flags accounts logging on with administrative or sensitive privileges (SeDebugPrivilege, SeBackupPrivilege, and similar). A service account that suddenly logs on with SeDebugPrivilege—the privilege commonly abused for credential dumping via process memory access—when it’s never needed that privilege before is a strong investigation lead, and one that’s completely independent of whether Sysmon is installed on that box at all.

Event ID 4720, 4732, 4728: account and group changes tell a persistence story

New account creation (4720), and additions to security-enabled groups (4732 for local groups, 4728 for global groups) are where attackers build in redundant access—creating a backup account or adding an existing compromised account to Domain Admins so they don’t lose access if their initial foothold gets cleaned up. This activity is relatively rare in most environments outside of scheduled IT onboarding, which makes it a good candidate for a tightly scoped, low-noise detection rather than just a hunt query you run occasionally.

The analysis worth doing: correlate account creation events with the creating account’s normal behavior. An account creation event where the creating principal isn’t a member of your help desk or IT provisioning team, or where it happens outside documented change windows, deserves investigation regardless of what account got created. I’ve seen this catch attackers red-handed more than once—account creation is loud by nature, and attackers doing it manually through a GUI rather than a script often don’t realize how distinctive that event looks against a baseline of automated provisioning tools doing the same thing.

Kerberos events (4768, 4769, 4771) for golden and silver ticket hunting

This is the area where Security Event Log hunting gets genuinely advanced. Event ID 4769 (Kerberos service ticket request) is central to detecting Kerberoasting—a spike in ticket requests for accounts with Service Principal Names set, especially using weak encryption types (RC4 instead of AES), is a well-known pattern by now, but it’s still worth hunting manually rather than relying purely on a canned alert, because attackers have gotten better about throttling request volume to stay under naive threshold-based detections.

Golden ticket hunting is subtler and leans on anomalies in the krbtgt account’s ticket-granting-ticket usage combined with unusually long ticket lifetimes or tickets presented for accounts that don’t match normal authentication patterns. This isn’t a five-minute query—it usually means pulling 4768/4769 pairs over a longer window and looking for statistical outliers in ticket lifetime and encryption type, which is exactly the kind of investigation that benefits from analysis skills built through repetition, not a one-off Sigma rule.

Building a coherent identity-hunting practice from these logs

The events above aren’t really separate hunts—they’re chapters in the same identity-compromise story. Authentication anomaly, privilege escalation, persistence via account manipulation, ticket abuse for lateral movement. Treating Security Event Log hunting as its own coherent practice, rather than a grab bag of individual event IDs, is what turns this from log review into actual threat hunting.