← All posts

Event Log Hardening: The Forensic Trail Attackers Hope You Never Configure

Windows logs everything — if you tell it to. Most machines ship with default log settings that rotate away critical evidence in hours, not months. Here's how to configure event logs so incident responders actually have something to work with.

I've worked incident response cases where the entire investigation boiled down to one question: "Do the event logs go back far enough?" In roughly two-thirds of those cases, the answer was no. Not because the logs were deleted by the attacker — because Windows rolled them over automatically due to default size limits that haven't kept up with modern forensic needs.

The default Security event log on Windows 11 is 20 MB. On a machine with moderate activity, that's 3–7 days of history. The default Application and System logs are also 20 MB each. If an attacker establishes persistence on Monday and your SOC doesn't notice until Thursday, the initial compromise events may already be gone — not wiped, just overwritten by the operating system doing exactly what it was configured to do.

Event log hardening isn't glamorous. It won't stop an attack. But it determines whether you can reconstruct what happened afterward — and whether your compliance evidence holds up in an audit.

What Attackers Do to Your Logs

Sophisticated adversaries target event logs actively. The techniques, in order of sophistication:

Here's the uncomfortable truth: if you're relying on the endpoint's own logs as your only forensic source, a skilled attacker can erase their tracks completely. Log hardening is necessary, but it's only fully effective when combined with off-machine log forwarding.

The Six Event Logs That Actually Matter

Windows has over 300 event log channels. You don't need all of them. For security forensics and incident response, six are critical:

1. Security (Security.evtx)

The crown jewel. Contains logon events (4624/4625), privilege use (4672/4673), object access, policy changes, and account management. If you only harden one log, harden this one.

Key event IDs to never lose:

2. System (System.evtx)

Service installations, driver loads, time changes, and shutdowns. Event ID 7045 (new service installed) is one of the most reliable persistence indicators — and it lives here, not in Security.

3. PowerShell Operational (Microsoft-Windows-PowerShell/Operational)

If you've followed our PowerShell hardening guide, Script Block Logging (Event ID 4104) writes decoded command output here. This is where you'll find the actual commands an attacker ran — including deobfuscated payloads.

4. Sysmon (if installed)

Sysmon isn't a default Windows component, but if you've deployed it, its log (Microsoft-Windows-Sysmon/Operational) captures process creation with full command lines, network connections, file creation timestamps, and registry modifications. It's the single best forensic data source on Windows — and its default log size is 64 MB. Not enough.

5. Windows Defender Operational

Microsoft-Windows-Windows Defender/Operational — records every detection, quarantine action, scan result, and real-time protection event. If Defender detected something and auto-quarantined it, the evidence of what it found lives here. Default size: 16 MB.

6. Task Scheduler Operational

Microsoft-Windows-TaskScheduler/Operational — records task creation, modification, and execution. Scheduled tasks are the #2 persistence mechanism (after services). If an attacker creates a scheduled task at 2 AM and you don't check until 9 AM, this log tells you exactly when and what.

Proper Log Size Configuration

The default 20 MB per channel is a holdover from an era when disk space was expensive. On a modern machine with a 512 GB+ drive, there's no reason not to allocate meaningful retention:

# Recommended minimum sizes for forensic retention
# Security: 256 MB (30-90 days on typical workstation)
wevtutil sl Security /ms:268435456

# System: 128 MB
wevtutil sl System /ms:134217728

# PowerShell Operational: 128 MB
wevtutil sl Microsoft-Windows-PowerShell/Operational /ms:134217728

# Windows Defender Operational: 64 MB
wevtutil sl Microsoft-Windows-Windows-Defender/Operational /ms:67108864

# Task Scheduler Operational: 64 MB
wevtutil sl Microsoft-Windows-TaskScheduler/Operational /ms:67108864

# Sysmon (if deployed): 256 MB
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:268435456

Total additional disk usage: under 1 GB. That's 0.2% of a 512 GB SSD for the difference between "we can investigate this breach" and "the evidence rotated away three days ago."

Audit Policy: Generating the Right Events

Increasing log size only helps if you're generating the right events in the first place. Windows ships with minimal audit policies enabled. Most security-relevant event categories are either not audited or only audit failures (missing successful actions entirely).

Here's the audit policy configuration that balances forensic value with log volume:

# Enable critical audit categories
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
auditpol /set /subcategory:"Security State Change" /success:enable
auditpol /set /subcategory:"Security System Extension" /success:enable

# Verify current state
auditpol /get /category:*

The key additions over defaults: Process Creation with success gives you Event ID 4688 (new process created) — a poor man's Sysmon if you can't deploy Sysmon. Sensitive Privilege Use catches credential theft attempts. Security Group Management catches admin escalation in real time.

One more critical setting: enable command-line auditing in process creation events:

# Include full command line in Event ID 4688
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Without this, Event ID 4688 tells you that powershell.exe was launched — but not what it executed. With it, you get the full command line, including encoded arguments. This single registry key has saved more IR investigations than any other configuration I know.

What WinSentinel Checks

WinSentinel's Event Log Analysis module (Module #32) audits all of this automatically:

$ winsentinel --audit --modules eventlog

 Event Log Analysis
 ─────────────────────────────────────────────────────
 [CRITICAL] Security log size is 20 MB (default)
   → Estimated retention: ~4 days at current event volume
   → Minimum recommended: 256 MB for 30+ day retention
   → Fix: wevtutil sl Security /ms:268435456

 [CRITICAL] Process Creation auditing disabled
   → Event ID 4688 will not be generated
   → No visibility into process execution on this machine
   → Fix: auditpol /set /subcategory:"Process Creation" /success:enable

 [WARNING] Command-line auditing not enabled
   → Process creation events won't include command arguments
   → Fix: reg add "HKLM\...\Audit" /v ProcessCreationIncludeCmdLine_Enabled ...

 [WARNING] 3 failed logon attempts in last 24h from unknown source
   → Source: 192.168.1.47 (Event ID 4625)
   → Could indicate brute force attempt
   → Review: wevtutil qe Security /q:"*[System[EventID=4625]]"

 [WARNING] Audit log cleared 2 days ago (Event ID 1102)
   → Cleared by: DESKTOP-XK\admin at 2026-06-05 02:14:33
   → Possible anti-forensics activity
   → Investigate: who accessed this machine at that time?

 [INFO]    System log size: 20 MB (default — recommend 128 MB)
 [INFO]    PowerShell Operational log size: 15 MB (recommend 128 MB)

The module checks log sizes, audit policy configuration, recent suspicious events (failed logons, log clears, privilege escalation), and whether key forensic channels are properly enabled. It's a 5-second check that tells you whether your machine will be useful in an investigation.

Log Forwarding: The Off-Machine Safety Net

Local log hardening is necessary but not sufficient. An attacker with admin access can always tamper with local logs — no matter how large or well-configured they are. The defense-in-depth answer is forwarding critical events to a location the attacker can't reach from the compromised machine.

Options, from simplest to most robust:

For fleet environments, WinSentinel Pro's central node can aggregate event log health status across all endpoints — showing you which machines have inadequate log sizes, missing audit policies, or recent log-clearing activity. You fix the detection gap before it matters, not after the breach.

The 5-Minute Hardening Checklist

If you read nothing else in this post, do these five things:

Five commands. Under 5 minutes. The difference between "we know what the attacker did" and "we have no idea — the logs didn't go back far enough."

Getting Started

Run a log health check right now:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit --modules eventlog

WinSentinel checks log sizes, audit policies, recent suspicious events, and retention adequacy — all in a single command. The free tier gives you full event log analysis on every machine. No license, no cloud, no agents to deploy. Fix what it flags, and your machine becomes a reliable forensic witness instead of a blank tape that recorded over itself last Tuesday.

For organizations managing multiple endpoints, WinSentinel Pro rolls up event log health across the fleet — ensuring every machine meets your retention policy before an incident forces you to find out which ones don't.