The Windows Event IDs every SOC should watch

Windows generates hundreds of event types and almost nobody reads them all. The good news: you don't have to. A handful of IDs tell, in order, the story of nearly any intrusion — from the first password attempt to the log clearing that covers the tracks. These are the ones that truly matter, grouped by what they reveal.

1. Authentication: an attack's first noise

• 4625 (failed logon): the king for detecting brute force and password spraying. A spike of 4625 with a single password across many accounts is textbook spraying.
• 4624 (successful logon): check the Logon Type (3 = network, 10 = RDP) and source IP. A logon after many 4625s = brute force that worked.
• 4740 (account lockout) and 4771 (Kerberos pre-auth failed): the echo of those attacks on the DC.

2. Privileges and execution

• 4672 (special privileges): flags every administrative logon. Watch for usage outside the norm.
• 4688 (process creation): with command-line auditing on, it's pure gold — it catches LOLBins (certutil, mshta), obfuscated PowerShell and anomalous parent-child chains (Word spawning cmd).

3. Escalation and lateral movement

• 4728 / 4732 (added to a privileged group): adding someone to Domain Admins or local Administrators is textbook escalation. Alert immediately.
• 4769 (Kerberos service ticket): the central event to hunt Kerberoasting (many requests with RC4 encryption).
• 5140 / 4648: access to admin shares and use of explicit credentials — footprints of lateral movement.

4. Persistence

• 7045 (service installed): one of the most reliable signals of persistence and remote execution (PsExec creates a temporary service).
• 4698 (scheduled task created): a classic persistence mechanism; be suspicious of tasks launching encoded PowerShell.

5. Anti-forensics: when they try to erase the trail

• 1102 (audit log cleared): barring planned maintenance, an almost unmistakable sign of evidence destruction. Top-priority alert.
• 4719 (audit policy changed): turning off audit categories to stop generating incriminating events is quiet evasion.

6. PowerShell and Sysmon: real visibility

• 4104 (script block logging): records the script block already de-obfuscated. The best visibility into malicious PowerShell.
• Sysmon 1 (process, with hashes and command line), 3 (network connection, ideal for C2) and 10 (LSASS access = credential dumping).

Turn the signal into detection

Watching the right event is half of it; the other half is writing the rule. With Sigma you write it once and convert it to KQL, SPL, Elastic or Wazuh. An example for point 3 (added to a privileged group):

title: Addition to a privileged domain group
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4728
    TargetUserName: 'Domain Admins'
  condition: selection
level: high

Before hunting: make sure you're logging

Many of these events are off by default: command-line auditing (4688), script block logging (4104) and Sysmon must be enabled. A detection on an event you don't log is a detection that never fires. Review your audit policy before writing rules.

Checklist

• ✅ Enable what's off by default: 4688 with command line, 4104, Sysmon.
• ✅ Auth: 4625 spike → suspicious 4624; 4740/4771 on the DC.
• ✅ Escalation: alert immediately on 4728/4732 over privileged groups.
• ✅ Persistence: 7045 and 4698 with odd binaries/scripts.
• ✅ Anti-forensics: 1102 and 4719 → top priority.
• ✅ Turn the signal into a Sigma rule and measure it before pushing.

It's not about reading everything, but about watching what tells the story. With these IDs, an intruder leaves footprints at every phase — you just have to be looking.

Sergio Belmonte Morales
Cybersecurity Analyst · SOC · Sentinel/KQL specialist