The event IDs, log channels, and audit settings that actually solve cases

Executive Summary

Objective: Give incident responders and threat hunters a practitioner map of the Windows event log: which channels matter, which event IDs answer which forensic questions, what has to be enabled before an incident so the evidence exists, and how to pull and triage it fast.

Target audience: SOC analysts, DFIR practitioners, sysadmins who get handed a “what happened on this box?” ticket, and anyone tuning a SIEM for Windows telemetry.

Windows logs almost everything an attacker does, but only if you turned it on first. Out of the box, process command lines are not recorded, PowerShell script content is mostly invisible, and the Security log rolls over at 20 MB, which on a busy server can mean only a few hours of history. This post covers the event types in the order an investigation actually uses them: authentication, account changes, execution, persistence, lateral movement, and anti-forensics.

How Windows Event Logging Works

Modern Windows (Vista and later) writes events in the binary EVTX format. Each log channel is a separate file under C:\Windows\System32\winevt\Logs\. When you collect evidence, you collect these files, not screenshots of Event Viewer.

The Channels That Matter

Event Types: Levels and Keywords

When people say “event type” they usually mean one of two things: the level (how severe) or the audit keyword (did an audited action succeed or fail). The Security log uses keywords rather than levels, which is why every Security event shows level “Information” even when it records a failed logon.

Prerequisites: Make Sure the Evidence Exists

The most common finding in a Windows investigation is “that was not logged.” Fix it before the incident. Assumed knowledge: Group Policy basics and an elevated PowerShell prompt. Lab convention used below: 10.0.0.0/16 for internal hosts and 198.18.0.0/15 to represent public addresses.

Advanced Audit Policy Subcategories

# Enable the forensic baseline (run elevated)
$subs = @(
  "Credential Validation", "Kerberos Authentication Service",
  "Kerberos Service Ticket Operations", "Logon", "Logoff",
  "Special Logon", "User Account Management", "Security Group Management",
  "Process Creation", "Security System Extension",
  "Other Object Access Events", "Detailed File Share",
  "Audit Policy Change", "Security State Change"
)
foreach ($s in $subs) {
  auditpol /set /subcategory:"$s" /success:enable /failure:enable
}
auditpol /get /category:*

Command Lines in 4688

Without this setting, 4688 tells you powershell.exe ran but not what it ran. GPO path: Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events.

$k = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit"
New-Item -Path $k -Force | Out-Null
Set-ItemProperty -Path $k -Name ProcessCreationIncludeCmdLine_Enabled -Value 1

PowerShell Script Block Logging

$k = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
New-Item -Path $k -Force | Out-Null
Set-ItemProperty -Path $k -Name EnableScriptBlockLogging -Value 1

Log Retention

The Security log defaults to 20 MB. Raise it, and forward to a SIEM or Windows Event Forwarding collector so a local wipe does not erase the only copy.

wevtutil sl Security /ms:1073741824
wevtutil sl "Microsoft-Windows-PowerShell/Operational" /ms:268435456
wevtutil gl Security

Authentication Events

Authentication events answer “who got in, from where, and how.” They are the backbone of almost every timeline.

Logon Types

LogonType on 4624 and 4625 is the single most useful field in the Security log. It tells you how the account arrived.

Why Did the Logon Fail? 4625 Status Codes

Here is what a suspicious RDP logon looks like once the fields are pulled out. An external source address, type 10, and an immediate 4672 on the same Logon ID is a remote admin session that needs an owner.

Event ID:        4624
Logon Type:      10
Target User:     CORP\jdoe
Target LogonId:  0x3E7A11C
Workstation:     KALI
Source Address:  198.18.44.17
Logon Process:   User32
Auth Package:    Negotiate
Elevated Token:  Yes

Kerberos and NTLM Events

On a domain, the domain controller holds the authentication record even when the workstation log is gone. Always pull DC Security logs.

Account and Group Management

Attackers who get admin create backdoor accounts and add themselves to privileged groups. These events are high signal and low volume, which makes them ideal alerts.

Process Execution

Parent and child relationships carry most of the signal. winword.exe spawning powershell.exe, w3wp.exe spawning cmd.exe, or services.exe spawning a binary from C:\Users\Public\ are all worth an immediate look. Encoded commands (-enc, -EncodedCommand) and download cradles (IEX, DownloadString, certutil -urlcache) in CommandLine are classic indicators.

Persistence: Services, Scheduled Tasks, and WMI

Lateral Movement: RDP, SMB, and Remote Execution

Lateral movement leaves artifacts on both ends. The source host records outbound intent (4648, RDP client logs); the destination records the inbound logon.

A PsExec pivot, reconstructed on the destination, typically reads: 4624 type 3 from the source IP, then 4672, then 5140 for ADMIN$, then 5145 writing PSEXESVC.exe, then 7045 installing the service, then 4688 with PSEXESVC.exe as the parent.

PowerShell Events

Even without script block logging enabled, PowerShell 5 automatically records 4104 at Warning level when a script block contains known-suspicious content. Filter 4104 on Level 3 for a quick win on unhardened hosts. A 400 event showing EngineVersion=2.0 often means someone launched powershell -version 2 to dodge modern logging.

Defense Evasion and Anti-Forensics

The attempt to hide is itself evidence. These events should page someone.

Sysmon: The Force Multiplier

Sysmon (Sysinternals) fills the gaps in native logging: file hashes, network connections per process, DNS queries, and process injection. Deploy it with a maintained configuration such as the SwiftOnSecurity or Olaf Hartong modular configs rather than an empty one.

sysmon64.exe -accepteula -i sysmonconfig.xml
sysmon64.exe -c

Collection and Triage Workflow

Step 1: Preserve the Logs

Goal: Get a forensically clean copy before anything rolls over. Action: Export with wevtutil epl, which works on live, locked channels.

$out = "C:\IR\$env:COMPUTERNAME"
New-Item -ItemType Directory -Path $out -Force | Out-Null
$logs = @(
  "Security", "System", "Application", "Windows PowerShell",
  "Microsoft-Windows-PowerShell/Operational",
  "Microsoft-Windows-TaskScheduler/Operational",
  "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational",
  "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational",
  "Microsoft-Windows-WMI-Activity/Operational",
  "Microsoft-Windows-Windows Defender/Operational",
  "Microsoft-Windows-Sysmon/Operational"
)
foreach ($l in $logs) {
  $f = Join-Path $out (($l -replace '[/ ]', '_') + '.evtx')
  wevtutil epl "$l" "$f" 2>$null
}
Get-FileHash "$out\*.evtx" -Algorithm SHA256 | Export-Csv "$out\hashes.csv"

Verification: hashes.csv lists every exported file. Missing files usually mean the channel does not exist on that host (Sysmon not installed, for example).

Step 2: Hunt Live with Get-WinEvent

Goal: Answer a specific question fast. Action: Filter with a hashtable, then parse EventData from XML so you get named fields instead of message text.

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4625
  StartTime = (Get-Date).AddHours(-24)
} | ForEach-Object {
  $x = [xml]$_.ToXml()
  $d = @{}
  $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
  [pscustomobject]@{
    Time      = $_.TimeCreated
    User      = $d.TargetUserName
    LogonType = $d.LogonType
    SubStatus = $d.SubStatus
    SourceIP  = $d.IpAddress
  }
} | Group-Object SourceIP | Sort-Object Count -Descending

Verification: Output groups failures by source. A single IP with hundreds of 0xC000006A entries against one user is brute force; many users with 0xC0000064 is enumeration or spraying.

Step 3: Query Exported EVTX Files Offline

$xp = "*[System[EventID=4624]] and " +
      "*[EventData[Data[@Name='LogonType']='10']]"
Get-WinEvent -Path "C:\IR\HOST01\Security.evtx" -FilterXPath $xp |
  Select-Object TimeCreated, Message

Step 4: Timeline at Scale

For more than a handful of hosts, use purpose-built tools. Hayabusa and Chainsaw apply Sigma rules to EVTX directly; EvtxECmd normalizes everything to CSV for Timeline Explorer.

hayabusa csv-timeline -d C:\IR\HOST01 -o C:\IR\HOST01_timeline.csv
hayabusa logon-summary -d C:\IR\HOST01

chainsaw hunt C:\IR\HOST01 -s sigma\ --mapping mappings\sigma-event-logs-all.yml

EvtxECmd.exe -d C:\IR\HOST01 --csv C:\IR\out --csvf HOST01_evtx.csv

Investigation Playbooks

Brute Force Leading to Compromise

• Many 4625 events from one source IP, SubStatus 0xC000006A, against one account.
• A 4624 from the same IP for the same account, often type 3 or type 10.
• A 4672 on that Logon ID if the account is privileged.
• 4688 or Sysmon 1 events under that Logon ID showing what the attacker ran first.

RDP Lateral Movement

• Source host: RDPClient 1024 naming the target, and possibly 4648.
• Destination: 1149, then 4624 type 10, then LocalSessionManager 21 and 22.
• Session end: 24 or 4779, and 4634 or 4647 on the same Logon ID.
• Repeated 25 / 4778 reconnects show an operator returning to a parked session.

Malicious Service or Scheduled Task

• 7045 or 4697 with a suspicious ImagePath, or 4698 with a suspicious task action.
• The installing account on 4697 or 4698, then back to its 4624 to find the source.
• TaskScheduler 200 and 201 or 7036 to prove execution.
• 1102 or 104 shortly afterward means the operator tried to clean up.

Verification and Validation

Confirm your audit baseline actually produces events before you need them. Generate a few benign test events in a lab and query for them.

# Failed logon (enter a wrong password when prompted) -> 4625
runas /user:$env:USERDOMAIN\labuser cmd

# Scheduled task create and delete -> 4698, 4699, TaskScheduler 106, 141
schtasks /create /tn IR-Test /tr calc.exe /sc once /st 23:59
schtasks /delete /tn IR-Test /f

# Process creation with command line -> 4688
cmd /c "echo IR-Test"

# Confirm they landed
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625,4688,4698} `
  -MaxEvents 10 | Format-Table TimeCreated, Id, ProviderName -AutoSize

Expected success output: at least one row each for 4625, 4688, and 4698. Open a 4688 and confirm the Process Command Line field is populated. If it is blank, the command line policy has not applied yet; run gpupdate /force and retest.

Troubleshooting and Gotchas

4688 Exists but Command Line Is Empty

Cause: Process Creation auditing is on but the Include command line policy is not. Diagnose: check the registry value, then retest.

Get-ItemProperty `
  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" `
  -Name ProcessCreationIncludeCmdLine_Enabled

auditpol Shows Settings but Nothing Is Logged

Cause: Legacy (basic) audit policy in a GPO is overriding the advanced subcategories. Resolution: enable Security Options > Audit: Force audit policy subcategory settings to override audit policy category settings, which sets SCENoApplyLegacyAuditPolicy to 1. Confirm with gpresult /h report.html and auditpol /get /category:*.

The Security Log Only Covers a Few Hours

Cause: Default 20 MB size with overwrite-as-needed retention. Diagnose: wevtutil gl Security and check maxSize, then compare the oldest event time to the incident window. Resolution: raise the size, and forward events off-host. Also check the DC and any SIEM before assuming the evidence is gone.

Times Do Not Line Up Across Hosts

EVTX stores timestamps in UTC; Event Viewer displays them in the local time zone of the analyst’s machine. Normalize everything to UTC in your timeline, and look for 4616 events if a host’s clock looks deliberately wrong.

4625 Source Address Is a Dash

A - in IpAddress means a local logon or an NTLM network logon where only the WorkstationName was supplied. Pivot to 4776 on the domain controller, which records the workstation, and to the firewall or NetFlow for the actual IP.

Quick Reference: The 25 Event IDs to Know Cold

Enable the audit baseline, raise your log sizes, forward off-host, and learn the Logon ID pivot. Do those four things and the next “what happened on this box?” ticket becomes a timeline instead of a guess.