Windows Forensics 104: Event Logs: The World’s Most Boring Novel (That Could Save Your Job)

Series: Windows Forensics | Author: Tech Corsair | Published: techcorsair.co.uk

Nobody reads event logs. Let's just get that out in the open.

In the same way that nobody reads the safety card on an aeroplane, nobody reads the terms and conditions on software updates, and nobody reads the minutes from last week's meeting, nobody -- nobody -- proactively reads Windows event logs for fun. They are the literary equivalent of watching paint dry, except the paint is in XML format and occasionally contains critical evidence of a nation-state breach.

But here's the thing about event logs: when something goes catastrophically wrong, they transform from "the dullest data source on the system" to "the most riveting reading material in the building." The CISO who never glanced at a log in their life will suddenly develop an intense interest in Event ID 4624 subtypes at 2 AM on a Tuesday. Funny how that works.

Windows event logs are, when properly configured, an extraordinary forensic resource. They record logins, logoffs, privilege escalation, process creation, service installation, scheduled task activity, and -- if you've been thorough with your audit policies -- practically everything else. The challenge is knowing which events matter, ensuring the right logging is enabled before you need it, and then parsing through the deluge without losing the will to live.

Let's make this as painless as possible.

Where the Logs Live

Windows event logs are stored as .evtx files in:

C:\Windows\System32\winevt\Logs\

The key log files for forensic analysis:

Default log sizes are, to put it diplomatically, insufficient. The Security log defaults to 20MB, which on a busy domain controller fills up faster than a pub car park on a Friday evening. Best practice is to increase these significantly -- 1GB or more for Security logs in enterprise environments.

The Event IDs That Matter

There are thousands of Windows event IDs. Most of them are about as relevant to a forensic investigation as the ship's lunch menu is to the Titanic inquiry. Here are the ones that actually matter.

Authentication Events (Security Log)

Event ID 4624 -- Successful Logon

The single most important event in Windows forensics. Every successful authentication generates a 4624, and the Logon Type field tells you how the user authenticated:

Event ID:     4624
Logon Type:   10
Account Name: admin_backup
Source IP:     192.168.1.105
Workstation:   WORKSTATION07
Logon Time:    2024-03-15T02:45:22.000Z

A Logon Type 10 (RDP) at 2:45 AM from an internal workstation using a backup admin account? That's either a very dedicated sysadmin or a very dedicated attacker. Experience in the security community suggests betting on the latter.

Event ID 4625 -- Failed Logon

Failed authentication attempts. A handful is normal -- people mistype passwords. Several hundred from the same source in rapid succession is a brute-force attack. The Status and Sub Status codes reveal why the logon failed:

# Quick PowerShell to count failed logons by account (on a live system)
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625} |
  Group-Object {$_.Properties[5].Value} |
  Sort-Object Count -Descending |
  Select-Object Count, Name -First 20

Event ID 4648 -- Explicit Credential Logon

This event fires when someone uses alternate credentials -- runas, mapping a network drive with different creds, or tools like PsExec that authenticate as a different user. Attackers performing lateral movement frequently trigger 4648 events because they're using compromised credentials to access remote systems.

Event ID:       4648
Subject Account: jdoe
Credentials Used: domain\admin_svc
Target Server:   DC01.corp.local

A regular user explicitly authenticating as a service account to a domain controller? That's the forensic equivalent of finding someone else's security badge in your pocket.

Event ID 4672 -- Special Privileges Assigned

Generated when an account with administrative privileges logs on. On its own, it's noise -- admins log in all the time. Cross-referenced with unexpected 4624 events, it confirms whether a suspicious logon had elevated privileges.

Process and Service Events

Event ID 4688 -- Process Creation

If you enable only one additional audit policy, make it this one. Event ID 4688 records every process creation on the system, including the process name, parent process, and -- if Include command line in process creation events is enabled -- the full command line.

Without command-line logging:

Process: C:\Windows\System32\cmd.exe
Parent:  C:\Windows\System32\svchost.exe

With command-line logging:

Process:      C:\Windows\System32\cmd.exe
Parent:       C:\Windows\System32\svchost.exe
Command Line: cmd.exe /c whoami && ipconfig /all && net user /domain

The difference is between "cmd.exe ran" (mildly interesting) and "someone ran reconnaissance commands through a service host" (incident declared). Always enable command-line logging. Always.

# Group Policy path to enable command-line logging
Computer Configuration > Administrative Templates > System > Audit Process Creation
  > "Include command line in process creation events" = Enabled

Event ID 7045 -- New Service Installed

A new service being installed on a system. This is a favourite persistence mechanism for attackers and generates a surprisingly clear audit trail:

Event ID:      7045
Service Name:  WindowsUpdateHelper
Service File:  C:\Windows\Temp\svc_helper.exe
Service Type:  user mode service
Start Type:    auto start
Account:       LocalSystem

A service called "WindowsUpdateHelper" running from C:\Windows\Temp under LocalSystem? That's not Windows Update. That's malware with aspirations of respectability.

Event ID 4698 -- Scheduled Task Created

Another common persistence mechanism. This event records the full XML definition of the task, including triggers, actions, and the account it runs under.

Event ID:      4698
Task Name:     \Microsoft\Windows\UpdateCheck
Action:        C:\ProgramData\update.exe
Trigger:       Daily at 03:00
Run As:        SYSTEM

Legitimate scheduled tasks don't typically live in C:\ProgramData. Legitimate scheduled tasks also don't typically try to disguise themselves under Microsoft's name. Both at once? That's cheeky, that is.

Log Tampering Events

Event ID 1102 -- Audit Log Cleared

This is the event that says "someone tried to destroy the evidence." When the Security log is cleared, Windows helpfully records one final event noting who cleared it. It's the forensic equivalent of writing "I definitely did not steal anything" on a wall in permanent marker.

Event ID:      1102
Subject:       CORP\compromised_admin
Time:          2024-03-15T03:15:00.000Z

If someone clears the Security log at 3 AM, the investigation has just gotten significantly more interesting. The absence of evidence is not the evidence of absence -- but the evidence of deletion is evidence of consciousness of guilt.

Event ID 104 -- System Log Cleared

Same concept, System log. Recorded in the System log itself.

Audit Policy: You Have to Turn It On First

Here's a truth that causes physical pain to incident responders worldwide: most of these events are not logged by default. Windows ships with minimal audit policy configuration. It's like buying a security camera system and leaving the lens cap on.

Essential Audit Policies

Enable these via Group Policy (Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration):

And separately:

# Enable command-line process auditing (critical)
Computer Configuration > Administrative Templates > System > Audit Process Creation
  > Include command line in process creation events = Enabled

Without these policies enabled, you're performing forensics with one hand tied behind your back and the other holding a cup of tea. The tea is nice, but it won't help.

PowerShell Logging: The Gift That Keeps on Giving

PowerShell is the Swiss Army knife of both system administrators and attackers. Fortunately, Microsoft provides three levels of PowerShell logging that turn it into one of the most transparent execution environments available.

Script Block Logging (Event ID 4104)

Records the full text of PowerShell scripts and commands as they're executed, including decoded versions of obfuscated scripts. This is extraordinarily powerful -- an attacker can Base64-encode their commands all they like; Script Block Logging captures the decoded version.

Event ID: 4104
Path:     Microsoft-Windows-PowerShell/Operational

ScriptBlock Text:
  Invoke-Mimikatz -DumpCreds

The attacker encoded, obfuscated, and triple-wrapped their command. PowerShell logged the decoded version anyway. Lovely.

Module Logging (Event ID 4103)

Records pipeline execution details -- what modules were loaded and what functions were called.

Transcription Logging

Writes a full text transcript of every PowerShell session to a designated directory. Less useful for real-time detection but excellent for forensic review.

Enabling PowerShell Logging

Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell
  > Turn on Module Logging = Enabled (specify * for all modules)
  > Turn on PowerShell Script Block Logging = Enabled
  > Turn on PowerShell Transcription = Enabled (set output directory)

Tools for Event Log Analysis

# EvtxECmd - Parse Security log to CSV with maps
EvtxECmd.exe -f "C:\Evidence\Security.evtx" --csv "C:\Output" --csvf security.csv

# Chainsaw - Hunt for Sigma rule matches
chainsaw hunt "C:\Evidence\Logs\" -s sigma/rules/ --mapping mappings/sigma-event-logs-all.yml

# Hayabusa - Generate timeline from all EVTX files
hayabusa csv-timeline -d "C:\Evidence\Logs\" -o timeline.csv

Quick Reference: Critical Event IDs

For those who want a printable cheat sheet (and honestly, who wouldn't -- stick it on the wall next to the incident response plan that nobody's read either):

A Brief Sermon on Log Retention

Logs are only useful if they exist when you need them. A 20MB Security log that rolls over every few hours is forensically useless for any investigation that started more than "earlier today."

Recommendations from the security community:

• Increase log sizes -- 1GB minimum for Security logs on critical systems
• Forward logs to a SIEM -- centralised storage with longer retention
• Protect log integrity -- attackers clear logs; SIEM copies survive
• Back up logs regularly -- archive to write-once storage if possible
• Monitor for Event ID 1102 -- alert on log clearing immediately

The best forensic investigation in the world means nothing if the logs were overwritten last Thursday. Plan accordingly.

What's Next in the Series

This is part of the Windows Forensics series on techcorsair.co.uk:

• WF-101: The Registry -- Where Windows keeps its diary. Every hive, every secret.
• WF-102: Execution Artifacts -- Prefetch, Shimcache, Amcache, and proving someone was here.
• WF-104: Event Logs -- You are here. The world's most boring novel.
• WF-105: USB Devices & Persistence -- Who plugged what where, and why won't this malware leave?

With event logs in your toolkit, you can reconstruct authentication patterns, process execution chains, and administrative actions across a timeline. Next up, we're getting physical -- USB device forensics -- and then investigating the digital equivalent of squatters: persistence mechanisms that refuse to leave no matter how many times you change the locks.

Tech Corsair -- Reading event logs so you can pretend you always did.