RESOURCE · CHEAT SHEET

The Windows event IDs you actually look at.

Windows logs thousands of event types and you will never read most of them. These are the ones that answer a question you are likely to be asking at the time.

August 3, 202611 min readDaniel A. & Óscar S.

This site already has a Linux triage cheat sheet, and the Windows half was missing, which is backwards: Windows is where most organisations' endpoints and accounts live, and it is where the SIEM from Lab 03 gets most of its interesting material. What follows is the short list, grouped by the question you are usually trying to answer.

Four logs, not one

Before the IDs, know where they live, because an ID means nothing without its log. Numbers repeat across logs and mean different things.

Log	What it carries
Security	Authentication, account and policy changes, process creation. The main one.
System	Service installs and driver loads. Event 7045 lives here, not in Security.
PowerShell/Operational	Script blocks and module activity. Separate channel, separate switch.
Sysmon/Operational	Only if you installed Sysmon. Its own numbering, starting at 1.

Sign-ins and accounts

ID	Meaning, and what to read next to it
4624	Successful sign-in. Useless without the logon type: 2 is at the keyboard, 3 is over the network, 5 is a service, 10 is RDP.
4625	Failed sign-in. The status and sub-status separate a wrong password from a disabled or non-existent account, which is the difference between a typo and enumeration.
4672	Special privileges assigned at sign-in. In practice: this session is administrator-equivalent. Pairs with the 4624 just before it.
4740	Account locked out. Tells you where the lockout came from, which is usually a stale credential on some other machine rather than an attack.
4720 / 4726	Account created / deleted. A creation you cannot tie to a request is worth a phone call.
4732 / 4728	Member added to a local / global security group. This is how "a user" quietly becomes "an admin".
4768 / 4769	Kerberos ticket requests, on domain controllers. Where account activity across the domain becomes visible in one place.

The pattern worth internalising is 4625 repeatedly, then 4624: a run of failures followed by a success, same account, same source. That sequence is the one that matters, and neither half means much alone.

Execution and persistence

ID	Meaning
4688	A process started. The single most useful event on the list, if command line auditing is on. See the next section.
7045 (System)	A service was installed. Rare on a workstation, and a long-standing favourite for persistence and for running as SYSTEM.
4697	Service installed, as recorded in the Security log. Same event, different channel and different retention.
4698 / 4702	Scheduled task created / updated. The other classic persistence spot, and the one `T1053.005` exercises.
4104 (PowerShell)	Script block logging: the actual code that ran, after deobfuscation. Off by default and worth turning on.
Sysmon 1, 3, 11, 13	Process created with hashes and parent, outbound network connection, file created, registry value set.

Someone tidying up

ID	Meaning
1102	The Security log was cleared. Almost never legitimate on a workstation. If you alert on one thing, alert on this.
104 (System)	Another log was cleared. Same reasoning, different channel.
4719	Audit policy changed. Turning logging off is quieter than deleting logs and leaves a much smaller trace.

The three switches that are off by default

This is where most home labs and a surprising number of production estates quietly lose. The events above exist, but three of the most valuable fields do not appear until you ask for them:

Command line in process creation. Without it, 4688 tells you powershell.exe ran and not what it ran.
PowerShell script block logging. Without it, event 4104 is not there at all, and obfuscated one-liners stay opaque.
Audit policy for the categories you care about. Several of the account and object events are not audited out of the box on a workstation.

None of this is exotic configuration, and all of it is the difference between a log you can investigate with and one that merely exists. If you want to find out which of these your own setup is missing, Lab 06 is the exercise: run a documented technique on purpose and check whether the event arrived, then whether anything alerted on it. Those are two different failures and they need two different fixes.

A triage order that holds up

When a machine looks wrong and you have the log in front of you, this sequence answers the most questions per minute spent:

1102 and 4719 first. If either fired, treat everything after it as incomplete rather than clean.
4624 and 4672 around the time in question. Who signed in, from where, by what method, and did it come with admin rights.
4688 in that window. What ran, from what parent. A shell spawned by a document handler is worth stopping on.
7045 and 4698. Did anything arrange to come back after a reboot.
4720, 4732, 4728. Did the account picture change.

Write down what you checked and what was absent, not only what you found. An empty result at step 3 because the events were never collected is a completely different conclusion from an empty result because nothing ran, and six months later you will not remember which one it was.

Scope. This is a defensive reference: reading the logs of machines you administer, or of a lab you built. Event IDs vary a little by Windows version and by role, so treat the numbers as a starting point and confirm against Microsoft's own documentation for the build you are actually looking at.

Frequently asked questions

What is the difference between logon type 3 and logon type 10 in event 4624?

Logon type 3 is a network logon, the ordinary way one machine reaches a file share or a service on another. Logon type 10 is RemoteInteractive, which in practice means RDP: someone has a desktop session on that machine. Type 2 is a person at the keyboard and type 5 is a service starting. The type is the field that turns a generic successful sign-in into something you can reason about, which is why reading 4624 without it tells you almost nothing.

Why does event 4688 not show me the command line?

Because that part is off by default. Process creation logging gives you the executable, but the arguments only appear once you enable the policy called Include command line in process creation events. Without it you can see that powershell.exe ran and not what it ran, which is the difference between a log entry and a usable one.

Do I need Sysmon if I already collect the Security log?

Not to start, but it fills real gaps. Sysmon adds process creation with hashes and parent process detail, outbound network connections tied to the process that made them, and registry and file writes. The built-in Security log covers authentication and account changes well and is much thinner on what a process actually did after it started.

Which single event should I alert on first?

1102, the audit log being cleared. It is rare in normal operation, it is cheap to alert on, and there is almost no benign reason for it on a workstation. It also has a useful property that most events lack: it tells you someone wanted the record gone, which is information even when everything else was missed.