Windows Event ID Lookup

A curated set, not a dump

Windows generates thousands of distinct event IDs and the overwhelming majority are noise. The 59 above are the ones that actually come up when you are investigating an incident, chasing an account lockout, or working out why a server rebooted at 3 a.m. Every entry has been checked against Microsoft's documented meaning rather than copied from a listicle.

The three that matter most, and are usually not enabled

4688 with command line auditing. Process creation on its own is moderately useful; process creation including the full command line is transformative. It is the difference between knowing PowerShell ran and knowing what it ran. Enable "Include command line in process creation events" in Group Policy — it is off by default.

4104 script block logging. Records the actual PowerShell that executed, after any runtime assembly. That means it defeats most obfuscation and base64-encoded commands, because it logs what was really run rather than what was typed. Also off by default.

1102. Nobody needs to enable this one, but somebody should be alerted on it. Clearing the Security log has essentially no legitimate operational reason on a server.

Reading a 4625 properly

A failed logon on its own tells you very little. The useful detail is in the sub-status code:

• 0xC0000064 — the username does not exist. In volume, this is enumeration.
• 0xC000006A — correct username, wrong password. In volume against one account, that is a brute-force attempt; across many accounts with the same password, that is password spraying.
• 0xC0000234 — the account is locked out.
• 0xC0000072 — the account is disabled. Somebody is trying credentials for a former employee.
• 0xC000006F / 0xC0000070 — outside permitted hours, or from a disallowed workstation.

The pattern across accounts and source addresses matters far more than any single event.

Chasing an account lockout

The complaint is always "my account keeps locking". The answer is almost always a stale credential somewhere, not an attacker. Find the 4740 on the domain controller and read the Caller Computer Name — that is the machine generating the bad attempts. Then on that machine look for a mapped drive with saved credentials, a scheduled task or service running as the user, a phone with an old Exchange password, or a saved RDP session.

Retention is the thing people get wrong

Default Security log size fills in hours on a busy domain controller, and then rolls. By the time an incident is noticed — typically weeks later — the evidence is gone. Two fixes: raise the log size substantially, and forward events off the box, so that clearing a local log does not destroy the record. Windows Event Forwarding is built in and free; any SIEM does it better.

Setting up audit policy, log retention and forwarding that actually holds evidence is part of managed IT, and reviewing whether yours would survive an investigation is part of a security audit.