ES1.4 Event Tracing for Windows (ETW)

How ETW underpins your entire detection stack

ETW is a tracing framework built into the Windows kernel. Components throughout the operating system — the kernel, device drivers, system services, applications — register as ETW providers and emit structured events. These events flow through trace sessions (kernel-managed buffers) to consumers (the applications that process the events). The Windows Event Log service is an ETW consumer — every event you see in Event Viewer was generated by an ETW provider. MDE’s sensor is an ETW consumer — the process creation, network connection, file write, and registry modification events that appear in Advanced Hunting tables originate from ETW providers. Sysmon’s kernel driver registers its own ETW provider and also consumes events from other providers.

The security-critical ETW providers include: Microsoft-Windows-Kernel-Process (process creation and termination), Microsoft-Windows-Kernel-File (file system operations), Microsoft-Windows-Kernel-Network (network connections), Microsoft-Windows-Kernel-Registry (registry modifications), Microsoft-Windows-Security-Auditing (security events — logon, privilege use, object access), Microsoft-Windows-PowerShell (PowerShell script execution), and Microsoft-Antimalware-Engine (Defender AV scan results). When these providers are functioning normally, MDE and Sysmon have full visibility. When any of these providers are tampered with, the corresponding detection category goes dark.

ETW tampering: how attackers blind your EDR

The three primary ETW tampering techniques represent escalating levels of sophistication and impact:

User-mode ETW patching. The attacker patches the EtwEventWrite function in ntdll.dll within their own process. By overwriting the first bytes of the function with a return instruction (ret/0xC3), any ETW event the process attempts to generate returns immediately without writing the event. This blinds ETW-based monitoring for that specific process. Other processes are unaffected — their copies of ntdll.dll are not patched. MDE’s kernel callbacks still observe the process because kernel callbacks are independent of user-mode ETW. This technique evades user-mode ETW consumers but NOT kernel-mode visibility.

Trace session manipulation. An attacker with administrative privileges can stop ETW trace sessions using logman stop "EventLog-Security" or similar commands. This stops the Security event log from receiving events — effectively disabling security auditing. An attacker can also modify trace session parameters to reduce buffer sizes (causing event loss) or disable specific providers within a session. MDE’s sensor runs its own trace session that is protected by tamper protection — an attacker cannot easily stop MDE’s session. But other sessions (Event Log, custom security monitoring) are vulnerable.

Kernel callback removal. The most sophisticated technique. An attacker who can execute kernel code (typically through a vulnerable driver loaded via BYOVD) can locate and remove the kernel callback routines that MDE’s driver registered. Without these callbacks, MDE loses kernel-level process creation, thread creation, and handle operation visibility. This is the “nuclear option” for EDR evasion — it blinds the deepest visibility layer. Defense: HVCI (Hypervisor-Protected Code Integrity) prevents unsigned kernel code from executing, and the ASR rule for vulnerable drivers prevents known exploitable drivers from loading.

1
2
3
4
5
6
7
8
9

# List active ETW trace sessions
logman query -ets | Select-String "Session Name"

# List security-relevant ETW providers
logman query providers | Select-String "Microsoft-Windows-Security|Microsoft-Windows-Kernel|Microsoft-Windows-PowerShell|Microsoft-Antimalware"

# Check if MDE's ETW session is running
logman query "DiagTrack" -ets 2>$null
logman query "SenseIRTraceSession" -ets 2>$null

ETW providers that matter for endpoint security

Windows includes hundreds of ETW providers, but a small subset generates the telemetry that MDE and Sysmon depend on for security monitoring. Understanding which providers generate which events helps you recognise what an attacker loses visibility to when they tamper with a specific provider.

Microsoft-Windows-Kernel-Process: generates process creation and termination events. This is the foundation of DeviceProcessEvents in MDE. When an attacker patches this provider, MDE stops receiving new process creation events from the attacker’s process context — the attacker becomes invisible in the process table.

Microsoft-Windows-Kernel-File: generates file creation, modification, and deletion events. This feeds DeviceFileEvents. Tampering with this provider hides file drops and file modifications from MDE’s telemetry.

Microsoft-Windows-Kernel-Network: generates network connection events. This feeds DeviceNetworkEvents. An attacker who patches this provider can establish C2 connections and perform data exfiltration without the connections appearing in MDE’s network telemetry.

Microsoft-Windows-PowerShell: generates PowerShell execution events including ScriptBlock logging (Event ID 4104). This provider is a frequent target for attackers because PowerShell is the primary execution engine for many attack tools. Patching this provider suppresses ScriptBlock logging — the decoded command content is not recorded even when ScriptBlock logging is configured through Group Policy.

Microsoft-Windows-Security-Auditing: generates Windows Security event log events (4624 logon, 4688 process creation, 4672 privilege use). This provider operates through a different mechanism than the kernel ETW providers — it is managed by the Local Security Authority (LSA) and is harder to tamper with from user mode. However, an attacker with SYSTEM privileges can modify the audit policy to suppress specific event categories.

The detection strategy for ETW tampering: monitor for the patching behaviour itself (API calls to EtwEventWrite modification patterns), deploy Sysmon as an independent telemetry channel that uses kernel callbacks rather than ETW subscriptions, and alert on anomalous telemetry gaps (a device that suddenly stops generating process events is suspicious in itself). ES12.4 covers ETW tampering detection in depth.

ETW session architecture and performance implications

ETW sessions are the intermediary between providers and consumers. The kernel maintains buffers for each active session, and events flow from provider → session buffer → consumer. Two session types matter for security:

Real-time sessions deliver events to consumers as they are generated — MDE’s sensor uses real-time sessions for immediate processing. The trade-off: real-time sessions consume kernel memory proportional to event volume, and if the consumer cannot process events fast enough, events are dropped silently. On high-throughput servers generating thousands of events per second, ETW event loss is a real operational concern — events are generated but never reach the security tool. The MDE sensor is optimised for this, but third-party ETW consumers (custom security tools, log forwarders) may not handle high-volume sessions gracefully.

Log file sessions write events to .etl files on disk — the Windows Event Log service uses this mechanism. Events are buffered and flushed periodically. The advantage: no real-time processing bottleneck. The disadvantage: latency between event generation and availability (typically seconds, but longer under heavy IO load). For forensic investigation, both real-time (MDE telemetry) and log file (Windows Event Log, Sysmon Operational log) capture the same events through different paths — providing redundancy when one path fails.

Troubleshooting

“Our Sysmon events stopped appearing in Sentinel but the Sysmon service is running.” Check whether the Sysmon ETW session is active: logman query "EventLog-Microsoft-Windows-Sysmon/Operational" -ets. If the session exists but events are not flowing to Sentinel, the issue is likely in the log forwarding pipeline (Windows Event Forwarding or the Sentinel agent). If the session does not exist, the Sysmon service may be running but its ETW provider may not be generating events — reinstall or reconfigure Sysmon.

“MDE shows ‘Sensor health: Active’ but we are not seeing new process events in Advanced Hunting.” The sensor health check confirms the sensor service is running and communicating with the cloud. It does not confirm that all ETW providers are generating events. Check whether tamper protection is enabled (Settings → Endpoints → Advanced features). If tamper protection is off, an attacker (or misconfigured software) may have disrupted MDE’s trace sessions. Enable tamper protection and restart the sensor service.