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 in Advanced Hunting 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 for process creation and termination, Microsoft-Windows-Kernel-File for file system operations, Microsoft-Windows-Kernel-Network for network connections, Microsoft-Windows-Kernel-Registry for registry modifications, Microsoft-Windows-Security-Auditing for logon and audit events, Microsoft-Windows-PowerShell for script execution, and Microsoft-Antimalware-Engine for Defender AV scan results. When these providers function normally, MDE and Sysmon have full visibility. When any provider is tampered with, the corresponding detection category goes dark — silently, without generating an alert about its own blindness.

The architectural dependency is worth stating explicitly: MDE does not independently observe process creation. It receives process creation events from ETW providers and kernel callbacks. If the ETW provider stops generating events, MDE's user-mode telemetry stops for that data source. This does not generate an alert — from MDE's perspective, no new events occurred. The absence of events is indistinguishable from a quiet system. There is no "events stopped arriving" alert because the system cannot distinguish between "nothing happened" and "something happened but the reporting mechanism was suppressed." This fundamental limitation is why ETW integrity protection — tamper protection, HVCI, the vulnerable driver ASR rule — is not an advanced configuration but a prerequisite for trusting your detection stack. This is why ETW tampering is classified as defense evasion (T1562.006 — Impair Defenses: Indicator Blocking): the attacker blinds the data source rather than disabling the security tool, which tamper protection would prevent.

ETW tampering: three techniques to 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 because each process has its own copy of ntdll.dll mapped into its address space. MDE's kernel callbacks still observe the patched process because kernel callbacks are independent of user-mode ETW. This technique evades user-mode ETW consumers but not kernel-mode visibility. It is available in most modern C2 frameworks — Cobalt Strike's blockdlls and inline ETW patching, Sliver's built-in ETW bypass, and standalone tools like SharpETWMonitor — and requires no special privileges beyond standard code execution.

The patching is trivially simple at the code level: the attacker writes bytes 0xC3 (ret) to the start of the EtwEventWrite function in the process's copy of ntdll.dll. After the patch, any call to EtwEventWrite within that process returns immediately without executing the event write logic. AMSI telemetry, PowerShell ScriptBlock logging, and .NET ETW events from that process are all suppressed. The patch is process-local — it does not affect other processes on the system — but the attacker's process is typically the one running the post-exploitation tooling, which means the most security-relevant events are the ones being suppressed.

Trace session manipulation. An attacker with administrative privileges can stop ETW trace sessions using logman stop "EventLog-Security" or similar commands, effectively disabling the Security event log. They can also modify session parameters to reduce buffer sizes — causing silent event loss — or disable specific providers within a session. MDE's sensor runs its own trace session protected by tamper protection, so an attacker cannot easily stop MDE's session. But other sessions — Event Log, Sysmon operational log, custom security monitoring — are vulnerable if tamper protection does not extend to them.

Kernel callback removal. The most sophisticated technique. An attacker who can execute kernel code — typically through a BYOVD attack loading a vulnerable signed driver — locates and removes the callback routines that MDE's driver registered with the kernel (PsSetCreateProcessNotifyRoutine and similar). 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 that user-mode patching cannot reach. The technique is documented in tools like Blackout, EDRSandblast, and custom kernel exploits. Defense: HVCI prevents unsigned kernel code from executing, the ASR rule "Block abuse of exploited vulnerable signed drivers" prevents known exploitable drivers from loading, and Microsoft maintains a vulnerable driver blocklist that Windows can enforce at boot. The combination of HVCI and the vulnerable driver ASR rule in block mode eliminates the most common prerequisite for kernel callback removal — the ability to load and exploit a vulnerable driver.

What ETW tampering evidence looks like

Understanding what normal ETW operation looks like is the prerequisite for detecting when it has been disrupted.

PS C:\> logman query -ets | Select-String "Session Name"
Session Name                : Circular Kernel Context Logger
Session Name                : Eventlog-Security
Session Name                : DiagLog
Session Name                : DiagTrack
Session Name                : EventLog-Application
Session Name                : EventLog-System
Session Name                : EventLog-Microsoft-Windows-Sysmon/Operational
Session Name                : SenseIRTraceSession
Session Name                : SenseNdrPktmon

This is what a healthy endpoint's ETW session list looks like. The security-relevant sessions are: Eventlog-Security (Security event log — authentication, audit events), EventLog-Microsoft-Windows-Sysmon/Operational (Sysmon events), DiagTrack and SenseIRTraceSession (MDE sensor sessions). If any of these sessions are missing from the output on an endpoint where they should be active, the corresponding telemetry source has been disrupted. A missing Sysmon session means Sysmon events are not being generated even though the Sysmon service may appear running. A missing SenseIR session means MDE's real-time investigation telemetry is offline.

When an attacker patches user-mode ETW, the session list remains intact — the sessions still exist, but the patched process silently drops its events before they reach the session buffer. Detecting this requires looking for the patching behavior itself rather than the absence of sessions.

Log Name:      Microsoft-Windows-Sysmon/Operational
Source:        Microsoft-Windows-Sysmon
Event ID:      7
Task Category: Image loaded (rule: ImageLoad)
Level:         Information
Computer:      DESKTOP-NGE042.northgate.local
Description:
  RuleName:      technique_id=T1562.006,technique_name=Indicator Blocking
  UtcTime:       2026-02-14 09:22:45.891
  ProcessGuid:   {a23f8c41-8b12-67ae-1100-000000004600}
  ProcessId:     7284
  Image:         C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  ImageLoaded:   C:\Windows\System32\ntdll.dll
  Hashes:        SHA256=3B4C0...
  Signed:        true
  Signature:     Microsoft Windows
  SignatureStatus: Valid

This Sysmon Event ID 7 (ImageLoaded) shows ntdll.dll being loaded into the PowerShell process. Every process loads ntdll.dll — this event alone is not suspicious. But when correlated with a subsequent memory write to the ntdll.dll region within the same process — captured by Sysmon Event ID 10 (ProcessAccess) with WriteProcessMemory targeting the ntdll base address — the combination indicates ETW patching. The first event is the DLL load. The second event, milliseconds later, is the patch. Neither event alone is conclusive. Together they identify the evasion technique with high confidence.

The investigator's approach to this evidence is temporal correlation: find the Sysmon Event ID 7 showing ntdll.dll loaded into a suspicious process (one spawned from an Office application, a LOLBin parent, or an unfamiliar executable). Then search the same time window for Sysmon Event ID 10 or DeviceEvents showing virtual memory protection changes (NtProtectVirtualMemory with PAGE_EXECUTE_READWRITE permission) in the same process. The protection change is the red flag — legitimate processes do not modify the memory protection of system DLLs after loading them. This correlation pattern is the foundation of the KQL detection that follows, and it demonstrates why Sysmon's Event ID 7 and Event ID 10 together provide detection capability that neither provides alone.

The providers that matter and what breaks when they're tampered

Each ETW provider feeds a specific detection capability. Understanding the mapping tells you what the attacker loses visibility to when they target a specific provider.

Microsoft-Windows-Kernel-Process feeds DeviceProcessEvents in MDE. When patched, MDE stops receiving process creation events from the attacker's context — the attacker becomes invisible in the process telemetry. Microsoft-Windows-Kernel-Network feeds DeviceNetworkEvents. An attacker who patches this provider can establish C2 connections and exfiltrate data without the connections appearing in MDE's network telemetry. Microsoft-Windows-PowerShell generates ScriptBlock logging events (Event ID 4104). This is a frequent target because PowerShell is the primary execution engine for most attack tools — patching this provider suppresses the decoded command content from the forensic record even when ScriptBlock logging is configured. Microsoft-Windows-Security-Auditing generates the Security event log (4624, 4688, 4672). This provider operates through LSA and is harder to tamper with from user mode, but an attacker with SYSTEM privileges can modify audit policy to suppress specific categories.

MDE's kernel-mode driver provides partial protection because it uses kernel callbacks that are independent of user-mode ETW. An attacker who patches user-mode ETW still generates kernel callback events for process creation, thread creation, and network connections. The kernel-mode telemetry continues while the user-mode telemetry is suppressed. This is the architectural reason MDE has both components — the user-mode service provides rich API-level detail, and the kernel driver provides guaranteed visibility that survives user-mode evasion.

ETW session architecture and the performance reality

ETW sessions are the intermediary between providers and consumers. The kernel maintains buffers for each active session, and events flow from provider to session buffer to consumer. Real-time sessions deliver events to consumers as they are generated — MDE's sensor uses real-time sessions for immediate processing. The tradeoff: 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 by the provider but never reach the security tool because the buffer overflowed.

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 is no real-time processing bottleneck. The disadvantage is 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 (Event Log, Sysmon) capture the same events through different paths — providing redundancy that matters when one path fails or is tampered with. This dual-path architecture is the reason Sysmon deployment is recommended even when MDE is active: the two systems use different ETW sessions, different consumers, and different storage mechanisms, so an attacker who disrupts one path does not automatically disrupt the other.

The performance implication for security engineering: on servers with high event volume, you may need to tune ETW buffer sizes to prevent event loss. MDE handles this internally for its own sessions, but Sysmon's ETW session uses default buffer sizes that may be insufficient on busy domain controllers or file servers. Event loss manifests as gaps in the Sysmon operational log — events that should have been captured are simply absent with no indication of the loss. Module ES11 covers Sysmon performance tuning for high-volume environments.

// Detect ETW tampering indicators — processes loading ntdll and modifying it
DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName =~ "ntdll.dll"
| join kind=inner (
    DeviceEvents
    | where ActionType == "NtAllocateVirtualMemory"
        or ActionType == "NtProtectVirtualMemory"
    | where Timestamp > ago(7d)
) on DeviceId, InitiatingProcessId
| where Timestamp1 between (Timestamp .. (Timestamp + 5s))
| project Timestamp, DeviceName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, ActionType1

This query correlates ntdll.dll loads with subsequent virtual memory protection changes in the same process within a 5-second window — the behavioral signature of user-mode ETW patching. A process that loads ntdll.dll (normal) and immediately changes the memory protection of its text section (not normal) is likely preparing to overwrite the EtwEventWrite function. False positives include some debugging tools and .NET JIT compilation, but the correlation with specific process contexts (especially processes spawned from suspicious parent chains) makes this a high-value detection.