Tool Guide

Windows Event Log Forensics: What Incident Response Reads First

Windows event log forensics is the first triage layer in incident response on compromised Windows hosts. The Security log, Sysmon log, PowerShell operational log plus a handful of other channels carry the events that reveal attacker behavior. Knowing which specific event IDs to read first separates effective triage from log-tail noise. This guide covers the canonical event IDs for credential abuse, lateral movement, persistence, defense evasion plus exfiltration detection. The Sherlock Universal Events Viewer reads EVTX plus remote channels to surface these events for incident response triage.

Incident response triage priorities

When a Windows host is suspected of compromise, the incident responder has limited time to assess scope before either containment action or escalation. The Windows event log carries the highest density of forensic evidence per minute of investigation. Knowing which event IDs to read first determines whether the triage produces actionable findings in 15 minutes or wastes the responder's time in irrelevant log noise.

The triage priorities follow the attacker kill chain: initial access surface, credential operations, lateral movement, persistence, defense evasion plus exfiltration. Each kill chain stage maps to specific event IDs across the Windows event log channels. Skilled incident responders read these specific event IDs first to build the timeline.

Authentication events: who logged in when

The Security log captures authentication events that frame attacker activity on the host. The canonical events:

4624 Successful logon: any successful authentication event. Logon Type field distinguishes interactive (Type 2), network (Type 3), batch (Type 4), service (Type 5), unlock (Type 7), network cleartext (Type 8), new credentials (Type 9), remote interactive (Type 10) plus cached interactive (Type 11). Network logons (Type 3) plus remote interactive (Type 10, RDP) are particular interest for lateral movement detection.

4625 Failed logon: any failed authentication. Sub-status code (e.g., 0xC0000064 user does not exist, 0xC000006A bad password, 0xC0000234 user account locked) indicates the failure mode. Bursts of 4625 events from a single source suggest credential brute force or password spray.

4634 Logon session ended: session termination plus session duration. Useful for matching active session windows to other activity.

4648 Explicit credential logon: a process invoked logon with explicit credentials (e.g., runas, scheduled task with stored credentials, service account starting). This event is the canonical credential-passing signal for lateral movement.

4672 Special privileges assigned: a privileged logon session was created. Always paired with a 4624. Special privileges include administrative rights. Frequent 4672 events from unexpected accounts indicate privilege abuse.

4768 Kerberos TGT requested: initial Kerberos ticket request. Account name plus pre-authentication type are forensically relevant.

4769 Kerberos service ticket requested: service ticket request. The Service Name field shows what service the requesting account is targeting. Kerberoasting attacks generate distinctive 4769 patterns.

4770 Kerberos service ticket renewed: ticket renewal. Repeated renewals of the same ticket may indicate persistence.

4771 Kerberos pre-authentication failed: Kerberos authentication failure. Often the Kerberos-side equivalent of 4625. AS-REP roasting attacks generate 4771 events with no pre-authentication.

Process events: what executed

Process creation events are the highest-value evidence for understanding what the attacker did on the host. Two channels carry these events: Security log 4688 (if process command-line auditing is enabled, which it usually is not by default) plus Sysmon Event ID 1 (if Sysmon is deployed).

Security log 4688 Process created: a new process was created. The event includes the new process name, the parent process name plus the command line if auditing is configured for command-line capture (which it usually is not by default). 4688 events without command lines are markedly less useful for IR triage.

Sysmon Event ID 1 Process create: Sysmon's process creation event. Sysmon captures the command line, parent process, image hash, signature status plus user context. Sysmon is the canonical source for process forensic evidence when deployed.

Sysmon Event ID 3 Network connection: outbound network connections initiated by the host with source plus destination IP plus port. Connections to attacker command and control infrastructure surface here.

Sysmon Event ID 7 Image loaded: DLLs plus other modules loaded into processes. DLL sideloading attacks surface as unexpected modules loaded into legitimate processes.

Sysmon Event ID 10 Process accessed: a process opened a handle to another process. Credential dumping (LSASS access by tools like Mimikatz) surfaces as Sysmon 10 events targeting lsass.exe.

Sysmon Event ID 11 File created: file creation events with full path. New executables in user-writable directories, new files in startup folders plus new scheduled task XML files surface here.

Sysmon Event ID 13 Registry value set: registry value modification with key plus value name. Persistence registry locations (Run keys, services keys, image file execution options) generate Sysmon 13 events when attackers establish persistence.

PowerShell events: the attacker's tool of choice

PowerShell is the most commonly abused administrative tool in attacker tradecraft. The PowerShell Operational log captures activity that other channels do not.

PowerShell 4103 Module logging: if module logging is enabled, every PowerShell pipeline execution is captured with the parameters. This is high-value forensic evidence but requires configuration to enable.

PowerShell 4104 Script block logging: if script block logging is enabled, PowerShell script blocks are recorded before execution. Encoded commands, obfuscated payloads plus malicious script content surface here. Script block logging is the single highest-value PowerShell forensic source.

PowerShell 4105 Script block starting plus 4106 Script block completing: start plus end markers for script block execution. Useful for measuring execution duration.

PowerShell 400 Engine started plus 403 Engine stopped: classic PowerShell channel events. Engine lifecycle events that frame the more detailed script block events.

Defense evasion events: what was changed

Attackers commonly disable or evade defensive controls. Several event categories capture this activity.

Security log 1102 Audit log cleared: the Security log itself was cleared. This event survives in the new log even when the prior log was cleared. Sudden 1102 events on a host outside change windows are a strong compromise indicator.

Security log 4719 Audit policy changed: audit policy configuration was modified. Disabling audit categories to avoid generating detection evidence surfaces here.

Microsoft-Windows-Windows Defender Operational 5001 Real-time protection disabled: Defender real-time scanning was disabled. Common attacker action to allow malware execution.

Microsoft-Windows-Windows Defender Operational 5007 Configuration changed: Defender configuration was modified. Common to add exclusions for attacker tool paths.

Microsoft-Windows-Windows Defender Operational 5012 Service stopped plus 1116 Threat detected plus 1117 Threat acted upon: Defender service operations plus detections. Detection events that did not result in containment indicate Defender was bypassed.

Sysmon 4 Sysmon service state changed: Sysmon was started or stopped. Attackers who detect Sysmon presence may stop the service to avoid generating evidence.

Lateral movement signatures

Lateral movement is the post-compromise propagation across hosts. Several event patterns surface lateral movement.

4624 Type 3 network logon from unusual source: network logons from hosts that do not normally authenticate to this host indicate lateral movement.

4624 Type 10 RDP logon plus 4624 Type 7 unlock: RDP sessions from unusual sources. Pair with 4778 Session reconnected plus 4779 Session disconnected for full session timeline.

5145 Detailed file share: SMB share access detail. Useful for detecting SMB-based lateral movement plus enumeration.

Sysmon 1 Process create with svchost.exe parent unusual: svchost.exe spawning unexpected processes indicates DCOM or WMI-based lateral movement.

WMI-Activity Operational 5857 ConsumerToFilterBinding: WMI persistence subscription created. WMI-based attacker persistence surfaces here.

The Universal Events Viewer triage workflow

The Sherlock Universal Events Viewer reads EVTX files from forensic disk images plus remote channels from live hosts. The triage workflow:

Acquire the EVTX files: for forensic acquisition the EVTX files at %SystemRoot%\System32\winevt\Logs are extracted from the forensic image. The Sherlock Disk Imager produces the image; the Universal Events Viewer reads the EVTX files from it.

Open the canonical channels: Security.evtx, Microsoft-Windows-Sysmon%4Operational.evtx (if Sysmon deployed), Microsoft-Windows-PowerShell%4Operational.evtx, Microsoft-Windows-Windows Defender%4Operational.evtx.

Build the timeline: filter for the canonical event IDs listed above. Construct a timeline of authentication events, process creations, registry modifications, defense evasion events plus lateral movement signatures.

Pattern match against attacker tradecraft: the timeline reveals which attacker techniques were exercised. Map findings to MITRE ATT&CK techniques for reporting plus communication with the broader security team.

Cross-reference with disk artifacts: file creation events from Sysmon ID 11 cross-reference with the disk forensic image. New executables in unusual paths plus their hash values surface here.

Identify scope of compromise: the lateral movement events identify other potentially compromised hosts. The IR response expands to include those hosts plus their EVTX files in the analysis.

What this means for incident response readiness

The mistake organizations make is treating Windows event logs as administrative overhead rather than as the highest-density forensic evidence source on the host. The event log is the difference between incident response that produces actionable findings in hours versus days.

The honest practitioner posture is to invest in event log readiness before the incident. Enable command-line auditing (Security 4688 with command line), enable PowerShell script block logging (PowerShell 4104), deploy Sysmon with a vetted configuration plus configure log centralization so events are captured even when the host log is cleared. The events that matter most for IR triage need to be generated in the first place. Defenders who skip this investment cannot extract the value when an incident occurs.

The Sherlock Forensics services practice handles ransomware response, breach investigation plus court-defensible forensic examination. The forensic toolchain includes the Sherlock Disk Imager for acquisition with chain of custody, the Sherlock Universal Events Viewer for event log timeline reconstruction, the Sherlock PST Viewer for mailbox forensics during breach analysis plus the supporting forensic examination services.

Talk to our team about incident response, IR retainer terms or proactive incident readiness assessment.

Windows event logs are the highest-density forensic evidence source on compromised hosts. Get the Sherlock Universal Events Viewer for IR triage reading. Talk to our team about incident response engagement.