Chapter 13

Windows Event Logs

Windows Event Logs are the backbone of host-based forensic investigation. This chapter maps the most important Event IDs to the attacker actions they record — logons, lateral movement, process creation, service installation, privilege escalation — and shows how to extract and analyze them efficiently.

Scenario

An attacker compromised a workstation via phishing and spent four days moving through the network. The EDR was deployed after the attacker established their foothold. Your investigation needs to reconstruct what happened in the four days before EDR, using only Windows Event Logs. The Security log has logon events, process creation (if 4688 auditing was enabled), and account changes. The System log has service installations. The PowerShell logs have every script that ran. The combined event log timeline from a single host can reconstruct hours of attacker activity with timestamps, account names, process names, and command lines — if the logs weren't cleared and retention was configured correctly.

Critical Event IDs Reference

Event ID	Log	Meaning	Forensic value
4624	Security	Successful logon	Logon Type field is critical: Type 2=interactive, Type 3=network, Type 10=RemoteInteractive (RDP), Type 4=batch, Type 5=service
4625	Security	Failed logon	Brute force indicator; Status/SubStatus codes reveal why (wrong password vs. disabled account vs. bad username)
4648	Security	Logon using explicit credentials (runas)	Key lateral movement indicator — shows which account was used and the target host
4768	Security (DC)	Kerberos TGT requested	Shows which account authenticated to the domain — on DCs gives you domain-wide authentication picture
4769	Security (DC)	Kerberos service ticket requested	Shows which services the account tried to access — reveals lateral movement destination
4776	Security (DC)	NTLM credential validation	NTLM auth attempt — Pass-the-Hash uses NTLM; source workstation visible
4688	Security	Process created	Requires "Audit Process Creation" and command line auditing enabled. Shows every process with parent, command line, and account.
4698	Security	Scheduled task created	New task with task details — key persistence indicator
4702	Security	Scheduled task modified	Existing task changed — attacker may modify legitimate tasks rather than creating new ones
4720	Security	User account created	New account creation — persistence via new admin account
4732	Security	Member added to security-enabled local group	Adding accounts to Administrators/Remote Desktop Users groups
4672	Security	Special privileges assigned to logon	Fires when SeDebugPrivilege or other elevated privileges assigned — precedes credential dumping
7045	System	New service installed	Service installation — persistence mechanism; includes service binary path
4104	PowerShell/Operational	Script block executed	Full content of every PowerShell script block — most valuable PS log for forensics
4103	PowerShell/Operational	Module logging — pipeline execution	Individual PowerShell commands and parameters
5140	Security	Network share accessed	Which share was accessed, by whom, from which workstation
5145	Security	Network share object checked	File-level access on shares — which specific files were opened
4663	Security	Object access attempt	Requires SACL (file auditing). Shows which files were read/written/deleted — evidence of data access

Parsing Event Logs with EvtxECmd

Batchevtx-parse.bat

:: Parse all event logs with EvtxECmd (Eric Zimmermann)
:: Produces well-structured CSV with all fields properly extracted

:: Parse entire evtx directory
EvtxECmd.exe ^
  -d "D:\evidence\C\Windows\System32\winevt\Logs" ^
  --csv "D:\analysis\evtx" ^
  --csvf evtx-all.csv ^
  --inc 4624,4625,4648,4688,4698,4720,4732,4672,7045,4104,5140,4663

:: --inc: only extract these Event IDs (reduces output size dramatically)
:: Remove --inc to get all events

:: Parse a specific log file
EvtxECmd.exe ^
  -f "D:\evidence\C\Windows\System32\winevt\Logs\Security.evtx" ^
  --csv "D:\analysis\evtx" ^
  --csvf security.csv

PowerShellevent-log-forensics.ps1

# Query event logs from EvtxECmd CSV output
# Much faster than using Get-WinEvent on large log files

$evtx = Import-Csv "D:\analysis\evtx\evtx-all.csv"

# --- Logon analysis ---
# All Type 10 (RDP) logons
$evtx | Where-Object { $_.EventId -eq "4624" } | ForEach-Object {
    $data = $_.PayloadData1  # EvtxECmd puts parsed fields here
    # Look for "Logon Type: 10" in PayloadData
    if ($data -match "LogonType.*10" -or $data -match "Type:.*10") {
        $_
    }
} | Select-Object TimeCreated, PayloadData1, PayloadData2 |
  Format-Table -AutoSize

# --- Lateral movement: 4648 explicit credentials ---
$evtx | Where-Object { $_.EventId -eq "4648" } |
    Select-Object TimeCreated, PayloadData1, PayloadData2, PayloadData3 |
    Sort-Object TimeCreated |
    Format-Table -AutoSize

# --- New services (persistence) ---
$evtx | Where-Object { $_.EventId -eq "7045" } |
    Select-Object TimeCreated, PayloadData1 |
    Format-Table -AutoSize

# --- Scheduled task creation ---
$evtx | Where-Object { $_.EventId -eq "4698" } |
    Select-Object TimeCreated, PayloadData1, PayloadData2 |
    Format-Table -AutoSize

# --- PowerShell script block logs ---
$evtx | Where-Object { $_.EventId -eq "4104" } |
    Where-Object { $_.PayloadData1 -match "(?i)(download|invoke|iex|bypass|encoded|frombase64)" } |
    Select-Object TimeCreated, PayloadData1 |
    Format-Table -AutoSize

Log Retention and Clearing

  Event Log Retention: What's Preserved and What's Overwritten
  ═══════════════════════════════════════════════════════════════════

  Default Windows log sizes (often too small for investigations):
    Security:    1024 KB  — at heavy volume, fills in hours
    System:       512 KB
    Application:  512 KB
    PowerShell:    15 MB

  Recommended sizes for forensic retention:
    Security:   1 GB+  — 90+ days at normal enterprise volume
    System:     256 MB
    PowerShell:  1 GB  — script block logs are verbose

  How to check current log size and behavior:
    Get-WinEvent -ListLog Security | Select MaximumSizeInBytes, LogMode
    # LogMode: Circular (overwrite), Retain (stop logging when full),
    #          AutoBackup (archive when full)

  Log clearing indicator: Event ID 1102 (Security log cleared)
                          Event ID 104  (System log cleared)
  These events are themselves written to the respective log, creating
  an ironic self-documenting record of the clearing attempt.
  They show the account that cleared the log and the timestamp.

  If logs are cleared but SIEM received logs before clearing:
    SIEM logs are your primary evidence source — the SIEM copy survived.
    The clearing event in the SIEM is evidence of attacker anti-forensics.

Event Log Analysis Workflow

Investigation question	Event IDs to query
Who logged into this host and when?	4624 (success), 4625 (failure). Filter by Logon Type. Check 4648 for explicit credential use (lateral movement).
What processes ran? (with command lines)	4688 with command line auditing — check if it's enabled first (HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled)
Were any new services or tasks created?	7045 (service), 4698 (task created), 4702 (task modified). Look at service binary path and task action.
Did the attacker run PowerShell?	4104 (Script Block Log — most complete). Correlate with 4688 process creation to see how PowerShell was launched.
Were accounts created or modified?	4720 (account created), 4722 (enabled), 4738 (modified), 4732 (added to local group). All show actor account and target account.
Were logs cleared?	1102 (Security cleared), 104 (System cleared). Shows timestamp and actor account — if attacker used SYSTEM account, that's a privilege escalation indicator.

Why enabling 4688 with command line auditing is a prerequisite for forensic capability

Event 4688 (Process Created) without command line auditing tells you a process ran but not what arguments it was given. powershell.exe appearing in 4688 means nothing on its own — PowerShell runs for legitimate reasons constantly. powershell.exe -EncodedCommand JABhAD...== in the command line field is the evidence. Command line auditing for 4688 is a Group Policy setting: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Detailed Tracking → Audit Process Creation (enable), then Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events (enable). Without both settings enabled together, 4688 entries have empty command line fields. Check this is configured on every host you investigate — and if it's not, treat event log process evidence as incomplete.

Q & A

Q: The Security event log was cleared but you have SIEM logs going back 90 days. Are the SIEM logs sufficient for forensic investigation?

SIEM logs are often sufficient and in some ways better than raw EVTX files, because they're already parsed, indexed, and timestamped at ingestion. For most forensic questions — logon events, process creation, service installation — SIEM logs provide the same information as the raw EVTX files. Key considerations: (1) SIEM ingestion lag — some SIEM configurations have 5-30 second latency; the very last events before clearing may not have been forwarded yet. (2) SIEM field extraction fidelity — verify that the SIEM parser preserved all fields, especially command line data in 4688 events (these can be truncated). (3) SIEM coverage — confirm that process creation (4688), PowerShell (4104), and scheduled task events (4698) were being forwarded, not just Security logon events. SIEM architectures that only forward Security events miss System log events like 7045. Document in your report what the SIEM was configured to ingest and confirm your evidence set is complete.