Windows Event Log Forensics for Incident Response

Windows event logs are the most underused forensic artifact in corporate incident response and the most reliable. Security.evtx, System.evtx and Application.evtx hold authentication events, service creations, privilege escalations and log clear events that document compromise. This guide covers the .evtx forensic workflow for SOC analysts and IR responders including the Event IDs that matter (4624, 4625, 7045, 1102), the MITRE ATT&CK alignment and the defensible examination workflow. Sherlock Forensics Universal Events Viewer Forensic Edition at $97 lifetime produces court-ready PDF reports with SHA-256 chain of custody.

Windows event logs are the most underused forensic artifact in corporate incident response. They are also the most reliable. Every Windows workstation, every Windows server, every domain controller generates a detailed record of authentication events, process creations, network connections, scheduled tasks, group policy changes and system errors. The data is there. The challenge is reading it.

This guide is for the SOC analyst, IR responder or compliance officer who needs to extract evidence from .evtx files in a defensible workflow.

The Three Event Log Files That Matter Most

A typical Windows workstation has dozens of event log channels. For most investigations, three are doing the work:

Security log (Security.evtx). Logon and logoff events, authentication failures, account lockouts, privilege use, audit policy changes, special privileges assigned. Event IDs 4624 (successful logon), 4625 (failed logon), 4634 (logoff), 4648 (explicit credential logon), 4672 (special privileges assigned), 4720 (account created), 4732 (member added to a security group).

System log (System.evtx). Service starts and stops, system reboots, driver installations, scheduled task creations. Event IDs 7045 (new service installed), 7036 (service state change), 7034 (service crashed), 6005/6006 (event log started/stopped, useful for detecting log tampering).

Application log (Application.evtx). Application-level events including PowerShell execution (when PowerShell logging is enabled). Event IDs 600 / 800 / 4103 / 4104 (PowerShell execution detail).

Beyond the basic three, channel-specific logs that often matter in IR:

  • Microsoft-Windows-Sysmon/Operational.evtx if Sysmon is installed, process creation with command line, network connections, file creation, registry modifications. Event IDs 1 (process create), 3 (network connect), 11 (file create), 13 (registry value set).
  • Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx, Remote Desktop session connect, disconnect, logoff. Event IDs 21 / 22 / 23 / 24 / 25.
  • Microsoft-Windows-PowerShell/Operational.evtx, PowerShell module loading and command invocation.

A complete forensic acquisition of a Windows system includes all event log channels from C:\Windows\System32\winevt\Logs\. The investigator filters down to the relevant channels at examination time.

What "Have I Been Hacked" Looks Like in Event Logs

When a Windows system is compromised, the event logs almost always show signatures even if the attacker did not actively cover tracks. Common patterns:

Authentication anomalies. Multiple Event 4625 (failed logon) followed by an Event 4624 (successful logon) for the same account suggests password guessing or credential stuffing. Failed logons from unusual source IPs (RDP from a country the user does not travel to) are notable. Authentication outside normal business hours from the same user account is notable.

Privilege escalation events. Event 4672 (special privileges assigned to a new logon) outside the normal pattern for an account suggests a privileged token was minted that should not have been. Event 4732 / 4756 (member added to a security group) for sensitive groups like Administrators, Domain Admins or Backup Operators outside change-management windows is high-confidence.

New service installation. Event 7045 (service installed) is rare under normal operation. An unexpected 7045 with a non-Microsoft service path is one of the highest-signal IR indicators. Many persistent malware families install themselves as Windows services.

Scheduled task creation. Event ID 4698 (task created) outside change-management is similar, task scheduler is a common persistence mechanism.

Process executions from unusual paths. With Sysmon, Event 1 (process create) showing cmd.exe or powershell.exe spawned from a parent process other than explorer.exe (a user's interactive shell) is investigation-worthy. wmic.exe, rundll32.exe, regsvr32.exe and mshta.exe are commonly abused by attackers.

Event log clear events. Event 1102 (audit log cleared) is the rarest single event in IR, adversaries clear logs specifically to hinder investigation. The clear event itself is logged, but everything before the clear may be lost.

A defensible IR examination surfaces these patterns from the event log data and produces a coherent timeline that a non-technical reader (executive, board, regulator, court) can follow.

The Forensic Examination Workflow

A defensible event log examination:

  1. Acquire the .evtx files in a forensically sound manner. Image the source workstation or server, mount the image read-only, copy the event log files to the examination workstation. Hash each .evtx at acquisition.
  2. Preserve the source files unmodified. SHA-256 of each .evtx before any analysis. Verify the hash is unchanged after analysis.
  3. Parse the event logs in a tool that does not modify the source files. Sherlock Forensics Universal Events Viewer Forensic Edition opens .evtx files read-only, parses the events and presents them in a searchable interface.
  4. Apply triage filters appropriate to the suspected event class. Sherlock includes 16 one-click triage buttons for common IR patterns: failed logons, new services, scheduled tasks, log clears, account changes, privilege escalations and other high-signal categories.
  5. Build the timeline. Cross-reference events across the Security, System, Sysmon and PowerShell logs to reconstruct what happened in what order. The "Have I Been Hacked" five-phase analysis in Sherlock guides this reconstruction.
  6. Hash each extracted artifact at the per-event level. The forensic report ties source .evtx hash to per-event hash through the verification table.
  7. Generate the court-ready PDF report. Branded forensic PDF with cover page, source .evtx metadata, timeline narrative, per-event details, hash verification table, examiner attestation, chain-of-custody footer.

The Sherlock Universal Events Viewer Forensic Edition produces steps 3-7 in a single workflow. Steps 1-2 are administrative acquisition discipline.

The "Have I Been Hacked" Five-Phase Analysis

The Sherlock product includes a structured five-phase analysis pattern that walks an investigator through a standard IR workflow:

Phase 1: Initial Access. Look for the first sign of compromise. Failed logon spike followed by success. Inbound RDP from an unusual source. Phishing-related process creation (Office document spawning PowerShell). The "patient zero" event is here.

Phase 2: Execution. What ran after initial access. Process creation events (Sysmon Event 1), PowerShell script blocks (4104), service creation (7045). Identifies the attacker's tooling.

Phase 3: Persistence. How the attacker maintained access. New services, scheduled tasks, registry run keys, WMI subscriptions. Determines whether the system is still compromised at examination time.

Phase 4: Privilege Escalation and Lateral Movement. Privilege use events (4672), explicit credential logons (4648), Kerberos ticket requests, remote service installations on other systems. Determines blast radius.

Phase 5: Defense Evasion and Impact. Log clear events (1102), antivirus disable events, suspicious file deletions, ransomware encryption signatures. Determines what the attacker did to hide tracks and what damage was done.

The five-phase pattern aligns with MITRE ATT&CK Tactics, Initial Access (TA0001), Execution (TA0002), Persistence (TA0003), Privilege Escalation (TA0004), Defense Evasion (TA0005), Lateral Movement (TA0008), Impact (TA0040). The Sherlock workflow guides the investigator through these categories systematically.

Chain of Custody for Event Log Evidence

Event log evidence in court or regulatory production requires the same chain of custody discipline as email evidence:

  1. Source .evtx hash at acquisition. SHA-256 with timestamp, examiner, source path.
  2. Read-only examination. Hash verification before and after analysis.
  3. Per-event hash at extraction. Each individual event hashed independently and stored in the signed JSON sidecar.
  4. Forensic PDF report with full chain documentation.
  5. Production export to CSV, JSON or Markdown depending on the downstream consumer (SIEM ingestion, review platform import, executive report).

Sherlock Forensics Universal Events Viewer Forensic Edition produces all of these in a single workflow at the $97 lifetime price.

Why Mid-Market Buyers Choose Sherlock

The competitive landscape for Windows event log forensic tools:

Free tools. EvtxECmd, Chainsaw, Hayabusa, LogParser. Excellent technical capability. Command-line workflows. Steep learning curve. No GUI, no report generation, no chain of custody documentation.

Enterprise SIEM. Splunk, Elastic, Microsoft Sentinel. Powerful at scale but expensive ($10,000+ annually for meaningful deployments) and built for ongoing operations rather than ad-hoc forensic examination.

Enterprise forensic suites. Magnet Axiom, Cellebrite Enterprise, X-Ways Forensics. Comprehensive but priced for enterprise procurement ($5,000-$20,000+ annually). Event log examination is one feature among many.

Sherlock Forensics Universal Events Viewer Forensic Edition at $97 lifetime sits between the free CLI tools and the enterprise platforms. GUI workflow, plain-English narrative generation, 16 one-click triage buttons, "Have I Been Hacked" five-phase analysis, forensic PDF reports with chain of custody. For the IR consultant, MSP security team, internal SOC analyst or compliance officer running event log examinations regularly, the per-case cost approaches zero while the per-case time saved on manual log parsing compounds.

When Sherlock Is Not the Right Choice

  • High-volume continuous monitoring. Sherlock is a forensic examination tool, not a real-time SIEM. For ongoing operational monitoring, Splunk / Elastic / Sentinel are the right tools.
  • Free-tool-only workflows. If your practice is entirely built around EvtxECmd and Chainsaw and you do not need the GUI, narrative or report features, the free tools handle the job.
  • Enterprise-procurement contexts. Large organizations with five-figure forensic-tool budgets often prefer Magnet Axiom or Cellebrite for their broader capability surface. Sherlock is purpose-built for event log forensics specifically.

See Also