Which Windows event IDs and logs would you pull first during an intrusion investigation?
Short answer
The Security log is primary: 4624 successful logon (with logon type), 4625 failed logon, 4634/4647 logoff, 4672 special privileges assigned, 4720 account created, 4688 process creation (with command line if enabled), and 4768/4769 Kerberos. Add 7045 service install (System log), 4698 scheduled task created, and PowerShell script-block logging (4104). Logon type and command-line auditing are what make these logs useful.
In an investigation, knowing which artifacts answer which question saves precious time. This question checks that you can move quickly from "something happened" to the specific logs that reconstruct attacker activity, rather than scrolling logs at random.
Authentication and accounts (Security log)
- 4624 — successful logon. The Logon Type field is gold: type 3 (network), 10 (RemoteInteractive/RDP), 2 (interactive), 5 (service). RDP and unexpected network logons to sensitive hosts deserve scrutiny.
- 4625 — failed logon; cluster these to spot brute force vs spray.
- 4634 / 4647 — logoff; 4672 — special privileges assigned at logon (admin/elevated session).
- 4720 / 4722 / 4728 / 4732 — account created, enabled, added to a privileged group — classic persistence and privilege escalation signals.
- 4768 / 4769 — Kerberos TGT/service-ticket requests, useful for Kerberoasting and Golden Ticket hunting.
Execution and persistence
- 4688 — process creation. With command-line auditing enabled, this captures the full command line, which is essential for catching encoded PowerShell and LOLBins.
- 7045 (System log) — a new service was installed; 4697 is the Security-log equivalent.
- 4698 — scheduled task created.
- PowerShell 4104 — script-block logging records deobfuscated script content; 4103 module logging adds pipeline detail.
Why this matters
The defaults are limited: many of these (command-line in 4688, PowerShell script blocks) must be explicitly enabled, and Sysmon adds far richer process, network, and CreateRemoteThread telemetry. A strong answer names the key IDs, explains that logon type and command-line auditing are what make them actionable, and notes that good IR depends on configuring logging before the incident.
Likely follow-ups
- What does the 'logon type' field on 4624 tell you, and which types are suspicious?
- Why must process-creation command-line auditing be enabled to get full value from 4688?
- How does Sysmon improve on the default Windows logs?