Windows Event Log Detection Coverage: The 20 IDs That Cover 80% of Threats
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most organizations think they have Windows logging because the Security log is enabled and being shipped to a SIEM. That belief survives precisely until the first incident, when responders open the events and find logons without process context, services installed without a parent, and PowerShell activity reduced to a 4104 event with no script block content. The Security log being on is not the same as auditing being configured. The default audit policy in Windows ships with Process Creation, Detailed File Share, and Kerberos Service Ticket Operations disabled, and the registry switch that adds command lines to 4688 is off by default. Collecting noise from the wrong subsystems while missing the events that matter is the dominant Windows logging failure mode in enterprise environments.
This guide is opinionated. There are roughly 400 audit subcategories across Windows, and a handful of vendor lists run to several hundred event IDs. In practice, twenty Security log IDs plus a curated Sysmon configuration give you coverage of the attack patterns that actually appear in incidents: credential abuse, persistence, lateral movement, defense evasion, and remote execution. The rest is operational background that fills storage and obscures signal. We walk through which IDs to collect, the policy changes that unlock the fields detection engineers need, where Sysmon adds genuine value rather than duplicating native telemetry, and how to size collection by host class so you do not overrun your SIEM ingest budget.
Why Default Auditing Misses the Attacks That Matter
The Windows default audit policy is a compromise between visibility and noise from a 2008-era threat model. It logs logon events, account management, and policy changes, but it does not log Process Creation, does not capture command lines in 4688, does not record PowerShell script blocks, and does not audit detailed Kerberos operations. Adversary tradecraft over the last fifteen years has shifted to in-memory execution, living-off-the-land binaries, and credential theft, all of which require those exact missing fields. The first remediation is to switch from the basic audit policy under Local Security Policy > Local Policies > Audit Policy to the Advanced Audit Policy under Security Settings > Advanced Audit Policy Configuration. The two policy systems conflict, and a stray basic policy setting will override advanced policy unless you also enable the Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings to override audit policy category settings option. Failing to enable this single GPO setting is the most common reason advanced auditing appears configured in Group Policy but does not produce events on endpoints. Verify on a target host with auditpol /get /category:* before you trust your policy is taking effect.
The 20 Event IDs That Drive Real Detection Coverage
Authentication and credentials: 4624 successful logon (filter by LogonType to separate interactive, network, and service), 4625 failed logon, 4648 logon with explicit credentials (catches runas and lateral movement with stolen creds), 4776 NTLM authentication attempt logged on the authenticating server, 4768 Kerberos TGT request, 4769 Kerberos service ticket request (the source for Kerberoasting detection via ticket encryption type 0x17), 4771 Kerberos pre-authentication failure (AS-REP roasting and password spray). Process and code execution: 4688 process creation, which is only useful with command-line auditing enabled, and 4104 PowerShell script block logging which captures the deobfuscated content of every script block executed. Persistence: 4697 service install via SCM, 7045 service install from the System log, 4698 scheduled task created, 4702 scheduled task updated. Account and group changes: 4720 user account created, 4722 account enabled, 4728 member added to global group, 4732 member added to local group (the canonical signal for local admin escalation), 4756 member added to universal group. Defense evasion: 1102 audit log cleared (an irreversible attacker tell). That is twenty IDs. They map cleanly to ATT&CK techniques across Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, and Lateral Movement.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Unlocking Command Lines and PowerShell Visibility
Event 4688 without command lines is nearly worthless for detection. You see that cmd.exe ran, but not what cmd.exe ran. Enable command-line auditing via GPO at Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events, which sets HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled to 1. Pair this with enabling the Audit Process Creation subcategory itself under Detailed Tracking in advanced audit policy. PowerShell has three logging mechanisms and they are not equivalent. Module logging records pipeline execution but only for explicitly listed modules and produces verbose noisy output. Transcription writes full session transcripts to disk, useful for forensics but not for real-time detection because the files are not events. Script Block logging, event ID 4104 in the Microsoft-Windows-PowerShell/Operational channel, captures the actual content of every script block PowerShell compiles, including content that was obfuscated, base64-encoded, or constructed dynamically at runtime; PowerShell deobfuscates the block before logging it. Script Block logging is the single highest-value PowerShell setting. Enable it at Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging, and do not enable Invocation Logging unless you want a flood of low-value events.
Where Sysmon Adds Value That Native Audit Cannot
Sysmon is not a replacement for Windows auditing; it is a complement that fills specific gaps. Native 4688 gives you process creation, but Sysmon EventID 1 adds an MD5/SHA256 hash of the executable, the original file name from the PE resource (which catches renamed binaries), and the parent process command line. EventID 3 network connect attributes every outbound TCP/UDP connection to a process, which native logging does not provide at all without enabling Filtering Platform Connection auditing that produces an unworkable volume. EventID 8 CreateRemoteThread catches process injection patterns like Cobalt Strike beacon spawning or classic DLL injection. EventID 11 file create with masked filters lets you alert on staging directory writes (Users\Public, ProgramData, Temp paths) and is the foundation for ransomware staging detection. EventID 22 DNS query attributes DNS resolutions to the process making them, which is invaluable for DNS-based C2 and beaconing analysis since enterprise DNS server logs do not have process attribution. Sysmon EventID 13 registry value set with a tuned filter catches autoruns persistence in Run/RunOnce keys without the noise of every registry write on the system. Run Sysmon with a publicly maintained config like SwiftOnSecurity's or Olaf Hartong's modular sysmon-modular as a starting point, and tune from there rather than building from scratch.
Collection Architecture: WEF vs Agent, and Sizing Per Host Class
Windows Event Forwarding is native, free, and uses Kerberos-authenticated WinRM. It supports source-initiated push, which scales better than collector-pull because endpoints can subscribe at boot rather than requiring the collector to enumerate sources. WEF latency is acceptable for most use cases at 1 to 5 minutes per batch, but it falls behind under heavy load and the WEC server itself becomes a single point of collection that needs sizing. Agent-based collection with Winlogbeat, NXLog, or a commercial EDR agent provides sub-second latency, more flexible filtering at the source, and the ability to ship to non-Windows collectors over TLS, but adds a software dependency to manage. Sizing rules of thumb: workstations generate 50 to 200 events per second under normal user activity with the recommended audit policy and Sysmon enabled, member servers 100 to 500 EPS depending on role, domain controllers 1,000 to 5,000 EPS driven by Kerberos and LDAP volume, and busy file servers can exceed that. Plan SIEM ingest at the high end of those ranges, allocate at least 50% headroom for incident bursts when an attacker triggers extensive enumeration or scan activity, and verify your collection pipeline tolerates a 10x burst without dropping events during the exact period you most need them.
The bottom line
Twenty event IDs, command-line auditing turned on, PowerShell Script Block logging enabled, and a tuned Sysmon configuration will outperform a default-policy SIEM ingesting fifty thousand events per second of meaningless noise. The work is not in finding exotic logging sources; it is in configuring the ones Windows already provides and verifying the policy is actually taking effect at the endpoint with auditpol.
Measure success not by EPS or storage consumed but by whether your detection content has the fields it needs to fire. If your Kerberoasting rule cannot query encryption type because you do not audit 4769, no amount of ingest will help. Fix the source first, then build the rules.
Frequently asked questions
Should I use the basic audit policy or the advanced audit policy?
Always use the advanced audit policy. The basic policy is coarse and conflicts with advanced subcategory settings unless you also enable the GPO option to force subcategory settings to override category settings. Without that override, advanced policy may appear configured but not produce events.
Does Sysmon replace Windows native auditing?
No. Sysmon complements native auditing. Authentication events (4624, 4625, 4768, 4769) and account management events only exist in the Security log. Sysmon adds process hashing, network connection attribution, DNS query attribution, and remote thread creation that native logging either does not provide or produces at unworkable volume.
Is PowerShell Module logging or Script Block logging more important?
Script Block logging (4104) is far more valuable for detection. It captures the deobfuscated content of every script block PowerShell compiles, including code that was originally base64-encoded or obfuscated. Module logging produces verbose pipeline records that are noisy and rarely used in detection content.
What is the single most common Windows logging mistake?
Enabling Process Creation auditing but not enabling the command-line inclusion registry setting. Without ProcessCreationIncludeCmdLine_Enabled set to 1, event 4688 records the executable path but not the command line arguments, which gutts detection coverage for living-off-the-land techniques.
How do I detect log clearing by an attacker?
Event ID 1102 in the Security log fires when the Security log is cleared, and 104 in the System log fires when other logs are cleared. These events are themselves logged before the clear takes effect, so they are reliable. Alert on both with high priority; legitimate log clearing in production is rare and almost always operator error or attacker activity.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.