Windows Event Logs and Forensic Artifacts: Tracking and Tampering

Disclaimer

This article is written for educational purposes and for authorized security testing only. Run these techniques exclusively against systems you own or have explicit written permission to assess. Clearing or tampering with logs on systems you do not control is illegal in virtually every jurisdiction and may constitute evidence destruction. Use this knowledge to build better detections, not to evade legitimate forensic investigations.

Introduction / Overview

Every meaningful action on a Windows host leaves a trace. The Security event log (Security.evtx) is the single richest source of forensic evidence on a domain-joined machine: logons, privilege assignments, and process creation all flow through it. For an attacker, this log is a liability; for a defender, it is gold.

In this article you will learn:

• Which event IDs matter most during an intrusion (4624, 4672, 4688).
• Where logs physically live and how the EVTX format is structured.
• How attackers attempt log clearing and selective event removal.
• How Sysmon dramatically improves visibility beyond the default channels.
• Concrete blue-team detections for tampering.

This pairs naturally with post-exploitation tradecraft discussed in Lateral Movement with PsExec and WMI and the credential theft covered in Mimikatz and LSASS Dumping.

How It Works / Background

Windows event logs are stored as .evtx files (binary XML) under:

C:\Windows\System32\winevt\Logs\

The three default channels you care about most are Security.evtx, System.evtx, and Application.evtx. The logging subsystem is driven by the Event Log service (EventLog), which is hosted inside an svchost.exe instance.

Key Security event IDs for intrusion analysis:

A normal administrative logon produces a tight pair: a 4624 (with LogonType 2 or 10) immediately followed by a 4672 for the same Logon ID. Correlating the TargetLogonId field across these events lets you reconstruct an entire session.

4688 (process creation) only records the full command line if Audit Process Creation and the ProcessCreationIncludeCmdLine_Enabled policy are both enabled — by default, command lines are not logged, which is a major visibility gap.

Prerequisites / Lab Setup

You need a Windows 10/11 or Windows Server VM where you have local admin. Enable the relevant audit policies first.

# Enable detailed process tracking (4688)
auditpol /set /subcategory:"Process Creation" /success:enable

# Enable logon auditing (4624 / 4625 / 4672)
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable

Turn on command-line capture for 4688 via Group Policy or the registry:

# Computer Config > Admin Templates > System > Audit Process Creation
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" `
  /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Install Sysmon (Sysinternals) with a community config such as SwiftOnSecurity or Olaf Hartong's sysmon-modular:

# Download Sysmon from Sysinternals, then:
.\Sysmon64.exe -accepteula -i sysmonconfig.xml

Sysmon writes to its own channel: Microsoft-Windows-Sysmon/Operational, giving you Event ID 1 (process create with hashes + command line), 3 (network connect), 11 (file create), and 13 (registry value set) — far richer than the default Security log.

Attack Walkthrough / PoC

Assume we have already escalated to a local administrator (see Windows Token Impersonation for how). Our goal is to understand what artifacts our activity generated, then to study clearing techniques as a defender would.

Step 1 — Generate and inspect artifacts

Run a benign command to create a 4688 event, then query it back:

whoami /priv

# Pull the last process-creation events
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5 |
  Format-List TimeCreated, Message

Inspect logon events and correlate the 4624/4672 pair by Logon ID:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4672} -MaxEvents 20 |
  Where-Object { $_.Message -match 'Logon ID' } |
  Format-Table TimeCreated, Id -AutoSize

Step 2 — Wholesale log clearing

The crudest anti-forensic move is clearing an entire channel. This is loud — it generates Event 1102 (Security log cleared) or 104 (other logs):

# Clears the entire Security log (generates 1102)
wevtutil cl Security

# Equivalent via PowerShell
Clear-EventLog -LogName Security

This maps to MITRE ATT&CK T1070.001 (Indicator Removal: Clear Windows Event Logs). Because the clear action itself is logged, mature SOCs alert on 1102/104 instantly.

Step 3 — Targeted removal and service tampering

More careful adversaries avoid the 1102 tell. Common approaches seen in the wild:

• Killing the threads of the EventLog service rather than stopping it, so the service appears "running" but stops writing. Tools like Phant0m enumerate the threads inside the svchost.exe hosting EventLog and suspend/kill them.
• Patching EtwEventWrite in-process to neuter ETW-based providers (the foundation Sysmon and many EDRs rely on).

# Identify the svchost PID hosting the EventLog service (recon for thread killing)
Get-CimInstance Win32_Service -Filter "Name='EventLog'" |
  Select-Object Name, ProcessId, State

Note: surgically deleting a single record from an existing .evtx file without corrupting the file is non-trivial because of the file's checksums and chunk structure. Most "log scrubbers" rebuild the file or operate before the event is flushed. Defenders should treat any unexplained gap in the monotonically increasing Record ID sequence as suspicious.

Mermaid Diagram

Text summary: attacker activity flows through ETW into both the Security log and Sysmon; clearing the log produces a 1102 event, while thread-killing creates a silent gap detectable by log heartbeats.

Detection & Defense (Blue Team)

Defending the logs is as important as collecting them. Treat the following with equal priority to any offensive technique above.

1. Forward logs off-host immediately. The most robust defense against local tampering is Windows Event Forwarding (WEF) to a central collector, or an agent shipping to a SIEM. Once an event is forwarded, clearing the local copy achieves nothing.

# Configure a source machine to forward to a collector
wecutil qc                      # on the collector
winrm quickconfig               # on the source
# Then define a subscription targeting Security + Sysmon/Operational

2. Alert on the tampering events themselves. Build high-priority detections for:

• Event ID 1102 (Security log cleared) and 104 (System/other log cleared).
• Event ID 4719 (system audit policy changed) — attackers disabling auditing via auditpol.
• Sysmon Event ID 1 where the image is wevtutil.exe, PowerShell invoking Clear-EventLog, or auditpol /clear.

# Example splunk-style pseudo-query
index=wineventlog (EventCode=1102 OR EventCode=104 OR EventCode=4719)
| stats count by host, user, EventCode

3. Detect the "silent gap." A central collector that expects a steady stream of events from each host can fire on the absence of events (a heartbeat/dead-man's-switch). A host that suddenly goes quiet after a 4624 is a red flag — this catches Phant0m-style thread killing that never produces a 1102.

4. Protect ETW. Enable PPL (Protected Process Light) for the Event Log service where supported, monitor for EtwEventWrite patching via EDR userland hooks, and watch Sysmon Event ID 8 (CreateRemoteThread) and 10 (ProcessAccess) targeting svchost.exe.

5. Increase log retention and size. Default Security.evtx (20 MB) rolls over quickly under heavy auditing. Raise the maximum size so attacker activity is not aged out:

wevtutil sl Security /ms:1073741824   # 1 GB max size
wevtutil gl Security                   # verify settings

6. Baseline the Record ID sequence. Because each EVTX record carries a monotonically increasing EventRecordID, gaps indicate selective deletion. Periodically export and diff:

Get-WinEvent -LogName Security -MaxEvents 1000 |
  Select-Object RecordId, Id, TimeCreated |
  Sort-Object RecordId

Conclusion

The Security event log records the three signals that most reliably betray an intrusion: logons (4624), privilege grants (4672), and process creation (4688). Attackers know this, which is why log clearing — from the noisy wevtutil cl Security (Event 1102) to surgical EventLog thread killing — is a standard anti-forensic step. The asymmetry favors defenders who forward logs off-host, alert on tampering and silent gaps, and deploy Sysmon for visibility the default channels can't provide. Logs you can delete are logs the attacker can delete; ship them somewhere the attacker can't reach.

References

• MITRE ATT&CK — T1070.001 Indicator Removal: Clear Windows Event Logs: https://attack.mitre.org/techniques/T1070/001/
• MITRE ATT&CK — T1562.002 Impair Defenses: Disable Windows Event Logging: https://attack.mitre.org/techniques/T1562/002/
• Microsoft — Windows Security audit events / Event ID reference: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/
• Microsoft Sysinternals — Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
• Olaf Hartong — sysmon-modular config: https://github.com/olafhartong/sysmon-modular
• SwiftOnSecurity — sysmon-config: https://github.com/SwiftOnSecurity/sysmon-config
• HackTricks — Windows Local Privilege Escalation / Anti-Forensics: https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation