Windows Event Logging & Audit Policy

Why Windows Event Logging Is the Backbone of Detection

Windows Event Logs are the raw material for every endpoint investigation in a Windows environment. They capture authentication, process creation, network connections, object access, and policy changes. Without these logs, a SOC is blind to what happens on endpoints.

• The Windows Security Event Log (Security.evtx) is the single most important log file on any Windows system. Every authentication attempt, process launch, and privilege change generates a record here if audit policy is configured correctly.
• Windows Event Forwarding (WEF) allows centralized collection. Forwarding these logs to a SIEM enables cross-host correlation — connecting an authentication from one host to a process creation on another.
• Event IDs survive OS upgrades. Event ID 4624 (logon) has the same meaning on Windows 10, Windows 11, Windows Server 2016, 2019, and 2022. This stability makes detection rules reusable.

MITRE ATT&CK maps log tampering to T1562.002 (Disable or Modify Tools — Impair Defenses). Attackers who disable or clear Event Logs are trying to cover tracks. Detecting log gaps is a detection in itself.

The 15 Event IDs Every Analyst Must Know

You do not need to memorize every Event ID. These 15 cover 90% of Windows-based investigations:

Event 4688 — The Most Important Event

Event 4688 (process creation) is the single highest-value security event because it captures what actually ran on the endpoint. With command-line logging enabled, it includes the full command string.

What to look for in 4688:

• Encoded PowerShell: powershell.exe -EncodedCommand <base64> — malware delivery and execution
• LOLBin execution: rundll32.exe, regsvr32.exe, mshta.exe, cscript.exe, wscript.exe, certutil.exe, bitsadmin.exe
• Unusual parent-child relationships: winword.exe spawning powershell.exe = macro malware
• Processes launched from suspicious paths: %TEMP%, %APPDATA%, %PUBLIC%, \Users\*\AppData\Local\Temp\
• Service control: sc.exe create, sc.exe config — service creation or modification
• WMI execution: wmic.exe process call create — lateral movement via WMI

Without command-line logging, 4688 events show only “powershell.exe” — you cannot distinguish a legitimate admin from an attacker running encoded commands.

Configuring Advanced Audit Policy

Default Windows audit policy is minimal. You must configure Advanced Audit Policy to get the Event IDs listed above.

The Two Audit Policy Systems

Windows has two audit policy systems:

Rule: If you configure both Legacy and Advanced audit policy, Legacy settings take precedence. Best practice: configure Advanced Audit Policy only and clear Legacy policy.

Essential Audit Policy Configuration via GPO

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access

Enabling Command Line Logging in 4688 Events

This is not enabled by default and is the single highest-value log setting:

Via GPO:

Computer Configuration > Administrative Templates > System > Audit Process Creation
> "Include command line in process creation events" → Enabled

Via Registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit]
"ProcessCreationIncludeCmdLine_Enabled"=dword:00000001

Verification via auditpol.exe

# Export current audit policy
auditpol /get /category:* /r > audit-policy.csv

# Check specific subcategory
auditpol /get /subcategory:"Process Creation"

# Set audit policy for process creation
auditpol /set /subcategory:"Process Creation" /success:enable

# Set command line logging via registry
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1

SPL query — detect audit policy changes (Event 4719):

index=windows EventCode=4719
| search AuditPolicyChanges="*Security*" OR AuditPolicyChanges="*System*" OR AuditPolicyChanges="*DetailedTracking*"
| eval alert = if(AuditPolicyChanges LIKE "%disable%", "HIGH — Audit policy disabled by " . Account_Name . " on " . ComputerName, "INFO — Audit policy modified by " . Account_Name . " on " . ComputerName)
| table _time, ComputerName, Account_Name, AuditPolicyChanges, alert
| sort - _time

Verifying Logging Is Enabled

Quick Health Check for Windows Security Log

# Check Event Log status
Get-WinEvent -ListLog "Security" | Select LogName, RecordCount, IsEnabled, LogMode, LogIsFull

# Check if command line logging is enabled
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" -Name "ProcessCreationIncludeCmdLine_Enabled" -ErrorAction SilentlyContinue

# Check audit policy subcategories
auditpol /get /category:"Detailed Tracking"
auditpol /get /category:"Logon"
auditpol /get /category:"Account Logon"

What a healthy system looks like:

Log Size and Retention Configuration

# Set Security log to 1 GB (1024 MB)
wevtutil sl Security /ms:1073741824

# Set retention to overwrite oldest events (circular)
wevtutil sl Security /rt:true

# Set automatic backup when full
wevtutil sl Security /ab:true

What to Do When Logs Are Missing

Scenario 1: No Event IDs Appearing

Scenario 2: Logs Present but Incomplete

SPL query — detect log gaps (hosts with no events in the last hour):

index=windows
| stats latest(_time) as last_event by ComputerName
| eval last_event_ago = (now() - last_event) / 3600
| where last_event_ago > 1
| eval alert = "HIGH — No Windows Events from " . ComputerName . " for " . round(last_event_ago, 1) . " hours — possible logging gap"
| table ComputerName, last_event, alert

Scenario 3: Audit Policies Changed or Disabled

Attackers frequently disable logging before executing their objective. Event ID 4719 fires when audit policies change.

SPL query — history of audit policy changes:

index=windows EventCode=4719
| table _time, ComputerName, Account_Name, AuditPolicyChanges, DomainName, SubjectUserName
| sort - _time

If you see a 4719 followed by a gap in events from that host, assume the attacker disabled logging and the logs that would have captured their activity are missing.

Scenario 4: Logs Cleared

Event ID 1102 (Security log cleared) in the System log confirms intentional log clearing.

index=windows source="System" EventCode=1102
| table _time, ComputerName, Account_Name
| sort - _time

If you find 1102 events, correlate with surrounding activity from other log sources (firewall, proxy, Sysmon on other hosts) to reconstruct what happened.

Windows Event Forwarding (WEF) Architecture

WEF enables centralized collection of Windows Event Logs. Without WEF or a SIEM forwarder, you must RDP to every host to check logs — impractical at scale.

WEF Collector Configuration

Source Computers → WinRM → WEF Collector (HTTP/HTTPS) → Forwarded Events log → SIEM Forwarder

Recommended WEF Subscriptions

Correlation — Connecting Event IDs Across Hosts

The real power of Event Logs comes from connecting events across hosts:

Related

• EDR Basics — detection and response for T1059, T1003, T1055, T1204, T1562 techniques
• Log Sources Overview — covers the log sources overview concepts
• Digital Forensics & Live Response — detection and response for T1562.001 techniques

Sources

• Microsoft Windows Security Log Encyclopedia
• Advanced Audit Policy Configuration
• Windows Event Forwarding Guide
• MITRE ATT&CK T1562 — Impair Defenses
• SwiftOnSecurity — Audit Policy Recommendations