Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Windows Event Logs are the single richest native evidence source on a compromised Windows host. Every logon, process launch, service install, scheduled task, and privilege use that the OS is configured to audit is recorded, timestamped, and (with a bit of correlation work) attributable to a specific logon session. For an incident responder, the Security, System, Application, and PowerShell Operational logs — plus Sysmon if it is deployed — are usually the first place to look when reconstructing what an attacker did on a box, in what order, and under which account.
The catch is that Windows logs nothing useful by default. Out of the box, process creation (4688) is not logged, command lines are not captured, and PowerShell script blocks are not recorded. Effective event log analysis is therefore half detection-engineering (making sure the right audit policies and Sysmon are in place *before* the incident) and half forensic reconstruction (querying, filtering, and correlating what was captured after the fact). Both halves matter equally in DFIR work.
Attack Prerequisites
This is a defensive/analytic capability rather than an attack, but its usefulness depends on the environment being instrumented correctly before the incident occurs:
- Advanced Audit Policy configured via
auditpol.exeor GPO — the legacy 9-category basic audit policy does not generate the granular subcategory events (e.g. Logon/Logoff, Process Creation) that IR relies on. - Command-line auditing enabled — the GPO ‘Include command line in process creation events’ (and the underlying
ProcessCreationIncludeCmdLine_Enabledregistry value underHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Audit) must be on, or 4688 events carry no command-line argument. - PowerShell Script Block / Module Logging enabled via GPO so
Microsoft-Windows-PowerShell/Operationalcaptures 4104/4103 events. - Sufficient log size and retention — default Security log sizing on many builds rolls over in hours under load; undersized logs are the most common reason evidence is simply gone by the time IR starts.
- Centralized forwarding (Windows Event Forwarding, a SIEM agent, or Sysmon-to-SIEM) so logs survive attacker log clearing on the source host.
How It Works
Modern Windows logs use the EVTX binary XML format, organized into *channels* (Security, System, Application, and hundreds of Applications-and-Services-Logs channels such as Microsoft-Windows-PowerShell/Operational or Microsoft-Windows-Sysmon/Operational) fed by *providers*. Each event has a numeric Event ID that is only unique within its provider, which is why analysts always cite both the channel and the ID — ‘Security 4688’ and ‘Sysmon 1’ are different events that both mean process creation. Each Security-log event tied to a session carries a Logon ID (a hex value like 0x3e7 for SYSTEM or a per-session hex value for interactive logons) that lets you pivot from a 4624 logon event to every subsequent 4688/4672/4648 event generated under that same session, which is the backbone of building an attacker timeline.
The Security log’s content is entirely governed by the Advanced Audit Policy subcategories (Logon/Logoff, Account Management, Object Access, Privilege Use, System, etc.) — a subcategory that is not set to Success/Failure auditing simply never fires, regardless of what happened on the box. This is different from Sysmon, which is a separate kernel-driver-backed provider that logs process creation with full command lines and parent-child relationships, network connections, file creation, and registry changes independent of the native audit policy, and is consequently one of the highest-value, lowest-noise sources when it is deployed with a curated config (e.g. based on SwiftOnSecurity’s or Olaf Hartong’s Sysmon configs).
Attackers who obtain local admin can clear logs outright — wevtutil cl Security or the Windows Event Viewer ‘Clear Log’ action — which itself generates Event ID 1102 (‘The audit log was cleared’), a strong, low-false-positive indicator of malicious activity that should always be alerted on. Clearing removes the *records* but not necessarily the fact that a clear occurred, since 1102 is usually the very next entry.
Practical Example / Configuration
A working IR triage set does not start from every Event ID that exists; it starts from a short, high-value list. The following table is a realistic starting triage list across the Security, System, and PowerShell/Sysmon channels:
- 4624 / 4625 (Security) — successful / failed logon; check Logon Type (2=interactive, 3=network, 10=RDP) and source IP.
- 4648 (Security) — logon using explicit credentials (
runas, lateral movement with alternate creds). - 4672 (Security) — special privileges assigned to new logon (admin-equivalent token).
- 4688 (Security) — process creation; requires command-line auditing to be useful.
- 4697 / 7045 (Security / System) — new service installed; 7045 is the System-log Service Control Manager version, present even without Security auditing enabled.
- 4698 (Security) — scheduled task created — a top persistence mechanism.
- 4720 / 4732 (Security) — user account created / added to a security-enabled group — privilege escalation and persistence.
- 4776 (Security) — domain controller validated credentials (NTLM) — useful for spray/brute-force detection.
- 1102 (Security) — audit log cleared — near-certain anti-forensics.
- 4104 (
Microsoft-Windows-PowerShell/Operational) — PowerShell script block logging, captures deobfuscated script content. - Sysmon 1 / 3 / 11 / 13 / 22 — process creation, network connection, file creation, registry value set, DNS query.
# Pull 4624/4625 logons for the last 24h, one line per hit
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625;
StartTime=(Get-Date).AddDays(-1)} |
Select TimeCreated, Id,
@{n='Account';e={$_.Properties[5].Value}},
@{n='LogonType';e={$_.Properties[8].Value}},
@{n='SourceIP';e={$_.Properties[18].Value}} |
Format-Table -AutoSize
# Pull 4688 process-creation with command line, filtered by parent process
Get-WinEvent -FilterXPath "*[System[EventID=4688]]" -LogName Security |
Where-Object { $_.Message -match 'powershell.exe' }
# Check whether the log was cleared
wevtutil qe Security /q:"*[System[(EventID=1102)]]" /f:text
Walkthrough / Exploitation
A typical triage pass starts by finding the anchor event, then pivoting outward using the Logon ID. Assume a suspicious 4688 for powershell.exe -enc ... is found; extract its Logon ID from the event XML:
$e = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} |
Where-Object {$_.Message -match '-enc'} | Select -First 1
[xml]$xml = $e.ToXml()
$logonId = ($xml.Event.EventData.Data |
Where-Object {$_.Name -eq 'SubjectLogonId'}).'#text'
Then pull every Security event carrying that same Logon ID to see the logon that started the session, every process it spawned, and any privilege escalation before or after:
Get-WinEvent -LogName Security |
Where-Object { $_.Message -match [regex]::Escape($logonId) } |
Sort-Object TimeCreated |
Select TimeCreated, Id, Message
For offline analysis of collected .evtx files (e.g. pulled during triage with KAPE or a manual collection), the same queries run against exported files, and wevtutil or EvtxECmd (Eric Zimmerman) parse them into CSV for loading into a timelining tool such as Timeline Explorer or plaso:
EvtxECmd.exe -f C:\triage\Security.evtx --csv C:\out --csvf security.csv
EvtxECmd.exe -d C:\triage\ --csv C:\out --csvf all_logs.csv
Note: Logon Type matters as much as the event ID: Type 3 (network) with NTLM and a 4624 immediately followed by 4634/4647 (logoff) in the same second is normal for SMB/admin-share access, while Type 10 (RemoteInteractive) from an unfamiliar source IP outside business hours is the classic RDP lateral-movement pattern.
Opsec / Analyst tip: Always work from a copy of the logs, never the live host’s originals, and hash the exported
.evtxfiles immediately for chain of custody. If 1102 appears, do not assume all evidence is lost — Sysmon (a separate provider), any centrally forwarded copy, and EDR telemetry frequently survive a local Security-log clear.
Detection and Defense
Good event log analysis is inseparable from good event log configuration; the following turn the Windows event subsystem from noise into evidence:
- Enable the full Advanced Audit Policy, not just the legacy basic policy, with
auditpol /set /category:* /success:enable /failure:enabletuned to your noise tolerance, and enable command-line auditing. - Deploy Sysmon with a curated, community-maintained config for process, network, file, and registry telemetry independent of native audit settings.
- Enable PowerShell Script Block, Module, and Transcription logging to capture 4104/4103 events with de-obfuscated content.
- Forward logs off-host via WEF or a SIEM/EDR agent so a local clear (1102) or
wevtutil cldoes not destroy the only copy. - Alert on 1102, 4719 (audit policy changed), and unexpected 4688 for
wevtutil.exe/Clear-EventLog, all strong anti-forensics indicators. - Increase Security log maximum size (
wevtutil sl Security /ms:<bytes>) so high-volume subcategories do not wrap out useful history in hours.
Real-World Impact
Event log analysis underpins the vast majority of Windows IR engagements: MITRE ATT&CK’s Discovery, Lateral Movement, and Persistence techniques almost all leave a native or Sysmon-visible trace, and log clearing (ATT&CK T1070.001, Indicator Removal on Host) is common enough among ransomware affiliates and APT intrusion sets that a bare 1102 event is treated as a near-automatic incident trigger by most SOCs. Conversely, under-instrumented environments — Security logs at default size, no command-line auditing, no Sysmon — are the recurring reason IR teams end up unable to answer ‘what did the attacker actually run.’
Conclusion
Windows Event Logs are free, native, and — when properly configured — extraordinarily detailed, but they are only as useful as the audit policy and retention settings in place before an incident starts. Responders who know the small set of high-value Event IDs, understand how to pivot on Logon ID, and can pull Sysmon and PowerShell logging into the same timeline consistently reconstruct attacker activity that would otherwise be invisible.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments