five windows event ids that tell the whole incident

your event log already wrote the incident report for you

most people think a breach is some mysterious thing that requires a forensic wizard and a dark room. sometimes it does. but a huge amount of the story is sitting right there in windows event viewer, in plain event ids, waiting for someone to actually read them in order. you don't need to guess what happened. you need to know which ids matter and what order they show up in.

4625 and 4624, the failed logons that finally worked

4625 is a failed logon. one or two of these is nothing, someone typo'd their password. a wall of them, especially against the same account or a handful of admin-sounding accounts, all in a tight time window, is a brute-force or password-spray attempt. now the part that actually matters for you as a defender: check what comes right after that wall of 4625s.

4624 is a successful logon. if you see hundreds of 4625s and then a 4624 for the same account, that's not "oh good, they finally gave up." that's the attacker finding the right password. that single 4624 at the end of a failure spree is one of the loudest signals in the entire log.

what to do about it: enable account lockout policies so that wall of 4625s never gets a chance to end in success, and set alerting (even a basic script or your siem) to flag any account with more than a handful of 4625s followed by a 4624 within a short window.

4688, the exact commands the attacker ran

4688 is process creation. this is the id that turns "something bad happened" into "here is literally the command line they typed." if process creation auditing with command-line logging is turned on, 4688 will show you powershell getting launched with weird encoded arguments, net.exe being used to poke at accounts, or living-off-the-land binaries doing things they normally don't do.

the catch is that 4688 with command-line detail is not on by default. you have to enable it. if you're not logging this, you're missing the single most useful id on this whole list.

auditpol /set /subcategory:"process creation" /success:enable

and turn on command line auditing via group policy under administrative templates, so the actual arguments get recorded, not just the fact that a process ran.

4720, the new account nobody asked for

4720 fires when a new user account gets created. attackers love creating a fresh local admin account because it doesn't trip the same alarms as using a compromised existing account, and it gives them a way back in even if the original foothold gets cleaned up. this is the classic backdoor move.

the fix here is boring but effective: know your baseline. if you're not regularly reviewing who your local and domain accounts are, a rogue 4720 just blends into the noise. set up alerting on 4720 events, especially outside of your normal onboarding process or IT change windows.

1102, when they try to erase their own footprints

1102 means the security log was cleared. think about that for a second. an attacker doesn't clear the log because they're tidy. they clear it because they know the log has them dead to rights and they're hoping you never look. if you ever see a 1102 event that you didn't personally generate for maintenance reasons, treat it as a five-alarm fire. it is functionally a confession.

the defense move: forward your logs off the local machine in real time to a central collector or siem. if the log gets cleared locally, you still have the copy that left before the attacker got there. local-only logging means a single 1102 event can erase the whole story.

the takeaway

put these five together and you get an actual timeline: a pile of 4625s, one winning 4624, a string of 4688s showing what tools got run, a 4720 planting a backdoor account, and a 1102 trying to make it all disappear. that's not a hypothetical, that's a breach narrative written entirely in event ids. go turn on command-line auditing, forward your logs somewhere the attacker can't reach, and set a couple of basic alerts on 4625/4624 combos, 4720, and 1102. your logs are already telling the story. make sure you're the one who gets to read it.