ETW — Event Tracing for Windows

Every Windows event log, every Sysmon event, every PowerShell ScriptBlock log — all of them are built on top of ETW. Event Tracing for Windows is not just another artifact; it is the infrastructure that produces artifacts. Understanding ETW directly gives investigators access to telemetry that never reaches the event log, including kernel-level process and thread events, DNS client resolution data, and the Microsoft Threat Intelligence provider that powers Windows Defender’s real-time detection.

What Is ETW?

Event Tracing for Windows (ETW) is a high-performance, low-overhead kernel-level tracing facility built into Windows since Windows 2000. It operates on a Provider → Session → Consumer model. Providers are components (kernel subsystems, drivers, applications) that generate events. Sessions are kernel objects that collect events from one or more providers and route them to a buffer. Consumers read events from sessions, either in real-time or from persisted .etl (Event Trace Log) files.

The Windows Event Log service itself is an ETW consumer — it reads events from ETW sessions and writes them to .evtx files. But many ETW providers emit events that are never consumed by the Event Log service. These “unlogged” events are only visible through direct ETW tracing. For forensic investigators, this means ETW provides access to telemetry that is invisible in standard event logs, including detailed kernel process/thread activity, network stack events, DNS resolution details, and memory allocation patterns.

Windows ships with over 1,100 registered ETW providers. Each provider is identified by a GUID and has a manifest describing its event schema. Providers can emit events at different levels (verbose, informational, warning, error, critical) and can be filtered by keyword bitmasks. This granularity means an investigator can enable exactly the telemetry needed for a specific investigation without overwhelming the system.

Location & Format

ETL File Format

ETL files use a binary format with a header containing the session configuration, followed by buffers of serialized events. Each event contains a common header (timestamp, process ID, thread ID, provider GUID, event ID, level, keyword) followed by provider-specific payload data. The format is not self-describing — you need the provider manifest (typically embedded in a DLL) to decode the payload fields. Tools like tracerpt, xperf, and SilkETW handle manifest resolution automatically.

Providers / Sessions / Consumers Model

Understanding the ETW architecture is essential for both collection and analysis:

• Providers emit events when enabled by a session. A provider does nothing until a session subscribes to it. Providers are identified by GUID and name (e.g., Microsoft-Windows-Kernel-Process {22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716}).
• Sessions (also called trace sessions or controllers) are kernel objects that buffer events from subscribed providers. A session can write events to an .etl file, deliver them in real-time to a consumer, or both. Sessions are created with logman, xperf, or the StartTrace API.
• Consumers read events from sessions. The Windows Event Log service is a consumer. tracerpt.exe is a consumer. SilkETW is a consumer. Custom C# or Python code using the TraceEvent library is a consumer. Real-time consumers process events as they arrive; file-based consumers process stored .etl files.

Key Forensic ETW Providers

What ETW Reveals

• Process injection techniques — The Threat Intelligence provider captures NtAllocateVirtualMemory, NtProtectVirtualMemory, and NtMapViewOfSection calls across process boundaries, revealing injection without needing Sysmon.
• DNS queries per process — The DNS Client provider maps every DNS query to the originating process ID, providing per-process DNS visibility without Sysmon Event ID 22.
• .NET in-memory execution — The DotNETRuntime provider captures assembly loading events, including assemblies loaded via reflection (e.g., Assembly.Load(byte[])), which is the primary mechanism for fileless .NET malware.
• Kernel-level file operations — The Kernel-File provider captures all file I/O at the NTFS level, including operations that bypass user-mode APIs and are invisible to most monitoring tools.
• Network connections below the event log — The Kernel-Network provider captures TCP/UDP events that may not generate event log entries, particularly for short-lived connections.
• AMSI inspection content — The AMSI provider captures the actual content submitted for scanning, including deobfuscated PowerShell scripts and decoded macro payloads.

Forensic Use Cases

1. Process Injection Detection Without Sysmon

On a system without Sysmon, the Threat Intelligence ETW provider (if an AutoLogger session was active) captures cross-process memory operations. An .etl file showing NtAllocateVirtualMemory called by Process A targeting Process B’s address space, followed by NtWriteVirtualMemory and NtCreateThreadEx, proves process injection occurred — with timestamps, PIDs, and call stacks.

2. DNS Exfiltration Attribution

The DNS Client ETW provider maps DNS queries to process IDs. When a process in C:\ProgramData generates hundreds of DNS queries to subdomains of a single parent domain, the ETW trace attributes every query to that PID. This provides the same per-process DNS attribution as Sysmon Event ID 22 but is available natively without Sysmon installation.

3. Fileless .NET Malware Detection

The DotNETRuntime provider captures assembly load events including the assembly name and whether it was loaded from disk or from a byte array in memory. A powershell.exe process loading an assembly named SharpHound or Rubeus via reflection (no file path, loaded from byte array) is a clear indicator of in-memory .NET tool execution.

4. AMSI Bypass Detection

The AMSI provider captures content submitted for scanning. If the AMSI content shows a PowerShell script attempting to patch amsi.dll in memory (the common AMSI bypass technique), the ETW trace captures the bypass attempt itself — including the script content that attempted the bypass — even if the bypass subsequently succeeds and prevents further AMSI logging.

5. Boot-Time Malware Analysis

AutoLogger sessions configured in the registry start tracing at boot time, before most user-mode services. The WDI\LogFiles\ directory contains boot traces that capture early process creation, driver loading, and service startup. Bootkits and early-stage persistence mechanisms that execute before the event log service starts may still be captured in these boot-time .etl traces.

Collection & Analysis Tools

:: List all registered ETW providers
logman query providers > C:\Evidence\etw_providers.txt

:: List all active trace sessions
logman query -ets > C:\Evidence\active_sessions.txt

:: Start a Kernel-Process trace (captures process/thread events)
logman create trace KernelProc -p "Microsoft-Windows-Kernel-Process" -o C:\Evidence\kernproc.etl -ets

:: Start a DNS Client trace
logman create trace DNSTrace -p "Microsoft-Windows-DNS-Client" -o C:\Evidence\dns.etl -ets

:: Stop a trace
logman stop DNSTrace -ets

:: Parse .etl to CSV
tracerpt C:\Evidence\dns.etl -o C:\Evidence\dns_events.csv -of CSV

Acquisition Methods

:: Collect all .etl files from standard locations
robocopy C:\Windows\System32\WDI C:\Evidence\ETW\WDI /S /COPYALL *.etl
robocopy C:\Windows\System32\LogFiles\WMI C:\Evidence\ETW\WMI /S /COPYALL *.etl

:: Using KAPE
kape.exe --tsource C: --tdest C:\Evidence --target WMITraceFiles

Retention & Persistence

Anti-Forensics & ETW Tampering

ETW is a known target for sophisticated adversaries. Techniques to blind ETW include:

MITRE ATT&CK Detection Mapping

Related Artifacts & Cross-References

References

1. Microsoft, “Event Tracing for Windows (ETW)” — https://learn.microsoft.com
2. FiEye/Mandiant, “SilkETW — Security-focused ETW Consumer” — https://github.com/mandiant/SilkETW
3. Pavel Yosifovich, “ETWExplorer” — https://github.com/zodiacon/EtwExplorer
4. Matt Graeber, “Subverting Sysmon” — https://specterops.io/blog/
5. Adam Chester, “Silencing ETW Providers” — https://blog.xpnsec.com
6. Microsoft, “KrabsETW” — https://github.com/microsoft/krabsetw
7. Microsoft, “TraceEvent Library” — https://github.com/microsoft/perfview