Windows Event Tracing (ETW) is a kernel-level logging mechanism providing visibility into system activity at a level of detail that standard security event logs do not expose. It sits underneath a lot of modern EDR telemetry, which means understanding it helps explain both what you can detect and why certain attacks get missed by products relying only on userland monitoring.
ETW architecture
ETW is a publish-subscribe system built into the Windows kernel. Providers register themselves and emit structured events. Consumers subscribe to providers and receive a real-time stream of event data. The Windows kernel itself is a provider. So is the .NET runtime, PowerShell, WMI, DNS client, network stack, and hundreds of other components.
Every ETW provider has a GUID. The critical security-relevant ones are:
// Key ETW providers for security monitoring
Microsoft-Windows-Threat-Intelligence (ETWTI):
GUID: {F4E1897C-BB5D-5668-F1D8-040F4D8DD344}
// Covers: process injection, credential access, AMSI bypass
// Requires kernel driver to consume - what commercial EDR uses
Microsoft-Windows-Kernel-Process:
GUID: {22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716}
// Covers: process/thread/image load events at kernel level
Microsoft-Windows-Kernel-Network:
GUID: {7DD42A49-5329-4832-8DFD-43D979153A88}
// Covers: TCP/UDP operations with owning process, before userland APIs
Microsoft-Windows-DNS-Client:
GUID: {1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}
// Covers: all DNS queries with process attribution
Microsoft-Windows-PowerShell:
GUID: {A0C1853B-5C40-4B15-8766-3CF1C58F985A}
// Covers: script block logging, module logging, command historyStarting a capture session with Logman
Logman is the built-in command-line tool for managing ETW trace sessions. Starting a capture of kernel network events:
// Start a network trace session
logman create trace NetworkCapture -p "Microsoft-Windows-Kernel-Network" 0x10 \
-o C:\traces\net.etl -ets
logman start NetworkCapture -ets
// ... capture activity ...
logman stop NetworkCapture -ets
// Convert to readable XML format
tracerpt C:\traces\net.etl -o C:\traces\net.xml -of XML
// Or to CSV for easier analysis
tracerpt C:\traces\net.etl -o C:\traces\net.csv -of CSV// Capture PowerShell activity (useful for post-incident analysis)
logman create trace PSCapture \
-p "Microsoft-Windows-PowerShell" 0xffffffffffffffff \
-o C:\traces\ps.etl -ets
logman start PSCapture -ets
// Run the PowerShell activity you want to capture
logman stop PSCapture -ets
// Convert and parse
tracerpt C:\traces\ps.etl -o C:\traces\ps.xml -of XMLConsuming ETWTI for real-time detection
The Microsoft-Windows-Threat-Intelligence provider requires a kernel driver to consume because it delivers data through a callback mechanism rather than the standard ETW session model. This is why only EDR products with kernel drivers can monitor it. However, you can write a kernel driver specifically for consuming ETWTI events in your own lab environment.
// Verifying ETWTI coverage in your environment
// Check whether your EDR has a kernel driver loaded
Get-WmiObject Win32_SystemDriver | Where-Object {$_.State -eq "Running"} |
Select-Object Name, PathName | Format-List
// If no kernel driver exists for your security product, ETWTI coverage is absent
// That means direct syscall attacks, process hollowing variants, and
// some credential access techniques will not generate alerts
// Test your coverage: run a known-detectable credential access tool
// in a test environment and verify whether your EDR fires
// Tools like Atomic Red Team have test cases mapped to ATT&CK techniquesETW tampering detection
Because modern EDR relies on ETW, attackers have started researching how to interfere with ETW providers to blind security tools. The most common technique patches the EtwEventWrite function in memory within the current process to prevent events from being written. Sysmon Event ID 25 (ProcessTampering) on Windows 10 21H1 and later catches this.
// Sysmon configuration to catch ETW tampering
// Event ID 25 fires when a process's loaded module is patched in memory
// Example Sysmon Event ID 25 entry indicating AMSI/ETW patch:
// EventID: 25
// Process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
// Type: Image is replaced
// Hashes: SHA256=...
// Sigma rule for ETW tampering
title: ETW or AMSI Patching Detected
logsource:
product: windows
category: process_tampering
detection:
selection:
EventID: 25
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
- '\cmd.exe'
- '\wscript.exe'
- '\cscript.exe'
condition: selection
level: criticalBuilding an ETW-based monitoring pipeline
For a home lab or small environment without commercial EDR, SilkETW is an open source tool that consumes ETW providers and outputs JSON logs that can be shipped to Elastic or Splunk.
// SilkETW setup for PowerShell monitoring
// https://github.com/mandiant/SilkETW
SilkETW.exe -t user -pn Microsoft-Windows-PowerShell -ot file -p C:\logs\ps_etw.json
// The output JSON includes full script block content, module names,
// command invocations, and timing data - similar to 4104 events
// but delivered through ETW rather than the Windows event log
// Parse with jq for quick analysis
cat C:\logs\ps_etw.json | python3 -c "
import sys, json
for line in sys.stdin:
try:
evt = json.loads(line)
if 'ScriptBlockText' in str(evt):
print(json.dumps(evt, indent=2))
except:
pass
"Why this matters for threat hunting
Most threat hunting guides focus on Windows event logs and Sysmon because those are the most accessible data sources. ETW sits underneath both of them. Understanding it means you can explain to stakeholders why certain attacks do not generate alerts (the EDR has no kernel driver so ETWTI is unavailable), evaluate which EDR products actually provide the coverage they claim, and build custom monitoring for gaps that commercial products leave. It also means you can spot when an attacker is deliberately interfering with your telemetry, which is itself a high-confidence indicator of a sophisticated intrusion.