The Windows Event Log IDs Every IR Analyst Should Know

When an incident hits, Windows Event Logs are often your first — and sometimes only — window into what happened. They're not pretty to read, and they won't tell you everything. But if you know which event IDs to look for and what they mean in context, you can reconstruct an attacker's movements with surprising precision.

This is a reference post. Bookmark it, print it, stick it on your wall.

Authentication and Account Activity

These are your bread and butter for tracking lateral movement and privilege escalation.

4624 — Successful logon Every time someone logs into a Windows system, this fires. The critical field is Logon Type:

Type 3 logons across multiple machines in a short window = lateral movement. Type 10 from an unexpected IP = suspicious RDP.

4625 — Failed logon Failed authentication attempts. A burst of 4625s followed by a 4624 is a brute force success. Look at the source IP and the target account name.

4648 — Logon using explicit credentials Fires when a process logs on using different credentials than the currently logged-in user — for example, runas or Pass-the-Hash attacks using tools like Mimikatz. This one is gold for spotting credential abuse.

4768 / 4769 — Kerberos ticket requests On domain controllers, these fire for every TGT and service ticket request. A 4769 with encryption type 0x17 (RC4) for a highly privileged account is a classic Kerberoasting indicator.

4720 / 4726 — Account created / deleted Attackers creating and deleting accounts to cover their tracks. Watch for these on domain controllers especially.

4732 / 4756 — Member added to security group Adding accounts to privileged groups like Domain Admins or Remote Desktop Users. If you didn't do it, someone else did.

Process Execution

4688 — A new process has been created This is disabled by default on most Windows systems, but should be enabled in any serious environment. It logs every process creation with the parent process, the full command line (if command line auditing is enabled), and the user who launched it.

Look for:

• powershell.exe spawned from winword.exe or outlook.exe — macro execution
• cmd.exe spawned from unusual parents like web servers (IIS worker process spawning cmd = webshell)
• Encoded PowerShell: -enc or -EncodedCommand in the command line
• wscript.exe or cscript.exe executing .js or .vbs files from temp directories

4104 — PowerShell script block logging Logs the full content of PowerShell scripts as they execute — including scripts that use obfuscation, because Windows logs the deobfuscated version. If you have this enabled, it's one of the most valuable sources of evidence for PowerShell-based attacks.

Persistence and Services

7045 — A new service was installed Attackers commonly install malicious services for persistence. This event fires on the system where the service is installed and includes the service name, binary path, and account it runs as. A service binary path pointing to a temp directory or a suspiciously named executable should raise immediate flags.

4698 / 4702 — Scheduled task created / modified Scheduled tasks are a favourite persistence mechanism. These events include the full XML definition of the task — check the action (what it runs) and the trigger (when it runs).

Object Access and Defence Evasion

4663 — An attempt was made to access an object File and folder access auditing. Noisy, but essential if you need to establish what files an attacker accessed or exfiltrated. Usually needs to be configured per-folder through SACLs.

1102 — The audit log was cleared An attacker clearing the Security event log. If you see this, something happened before it that they didn't want you to find. Correlate with your SIEM or log forwarding to see if you captured events before the clear.

4719 — System audit policy was changed Attackers disabling auditing to reduce their footprint. If audit policy changes and you didn't make them, treat it as a hostile action.

A Practical Note on Retention

Default Windows event log sizes are woefully small — often just a few megabytes, which on a busy system can roll over in hours. On any system you care about, increase the Security log size to at least 1GB and forward logs to a SIEM or centralised log store.

If logs have already rolled by the time you're investigating, check whether your SIEM has them. If not, the absence of logs is itself evidence — and potentially evidence that they were deliberately cleared.

Putting It Together

No single event ID tells the full story. What you're looking for is a chain — a sequence of events that, taken together, describe an attacker's actions.

A classic lateral movement chain might look like:

1. 4625 × 50 (brute force attempts) on WORKSTATION-A
2. 4624 Type 3 from WORKSTATION-A to SERVER-B
3. 7045 new service installed on SERVER-B
4. 4688 cmd.exe spawned from new service on SERVER-B

Each event alone is explainable. Together, they're an incident.