For modern defenders, Event Tracing for Windows (ETW) is the source of truth. It is the nervous system of the Windows endpoint, providing the telemetry that EDRs rely on to detect process injection, .NET abuse, and malicious network connections.
But from a Red Team perspective, ETW is just another software component. And like any software component, it can be manipulated, suppressed, or blinded.
In this post, we will dissect ETW from an attacker’s viewpoint. We will explore how the kernel generates these events, how we dismantle the logging pipeline during engagements, and, most importantly, how you can detect these evasion attempts to build a more resilient defense.
To blind the system, we first have to understand how it sees. ETW isn’t a single monolith; it is a pipeline composed of four distinct components. If an attacker breaks any link in this chain, the defensive tools at the end go blind.
Providers: The components generating the events. This can be user-mode applications (like the CLR) or the Windows Kernel itself.
Sessions: The kernel objects that act as buffers, collecting events from providers and relaying them.
Controllers: The management layer (e.g., logman.exe) that starts, stops, and configures trace sessions.
Consumers: The end destination. In most environments, your EDR agent is the primary real-time consumer.
The Red Team Takeaway: We don’t need to destroy the whole system. We just need to stop the Session or silence the Provider, and the Consumer (your EDR) will simply stop receiving data.
Before we discuss breaking it, it is crucial to appreciate what we are up against. The Windows Kernel (ntoskrnl.exe) has embedded sensors that are incredibly difficult to bypass without high privileges. These sensors are divided into two categories: Threat Intelligence (Ti) and Security Mitigations (Tim).
These are the “high fidelity” sensors that Microsoft added to catch advanced tradecraft. They hook directly into critical kernel functions.
EtwTiLogReadWriteVm: Triggered by MiReadWriteVirtualMemory. This catches us when we try to read/write to another process’s memory (e.g., dumping LSASS).
EtwTiLogSetContextThread: Triggered by PspSetContextThreadInternal. This is the primary indicator for Thread Hijacking injection techniques.
EtwTiLogDeviceObjectLoad: Triggered when a driver is loaded.
These sensors fire when a security control blocks an operation.
EtwTimLogBlockNonCetBinaries: Fired when a binary is blocked because it doesn’t comply with Control-Flow Enforcement Technology (CET).
EtwTimLogProhibitDynamicCode: Triggered by functions like MiArbitraryCodeBlocked. This alerts you when a process tries to execute code in a way that violates Arbitrary Code Guard (ACG).
Defensive Note: These kernel-level events are generated inside Ring 0. Unlike user-mode logs, we cannot simply “patch” them from a standard process. However, we can stop the sessions that listen to them.
During a Red Team engagement, we cannot afford to let these sensors report back to the SIEM. Here are the three primary techniques we use to neutralize ETW.
The most straightforward way to blind an EDR is to attack the Controller. Windows includes a built-in utility called logman.exe designed to manage traces. An attacker with administrative privileges can list all active sessions and simply kill the one belonging to the security product.
# List all active ETW sessions
logman query -ets
# Stop the specific session (e.g., "Circular Kernel Context Logger" or a vendor-specific session)
logman stop "Session-Name" -ets
Why this works: The EDR agent is often a Consumer. If we kill the Session at the kernel level, the EDR process keeps running, but the data hose is disconnected. The dashboard shows “Healthy,” but the sensor is deaf.
Sometimes we don’t want to kill a session; we want to own it. Tools like Process Monitor (Procmon) rely on specific trace sessions (e.g., PROCMON TRACE).
By querying the providers, we can see exactly what a tool is listening to. During our research, we found we could effectively “hijack” these sessions or flood them. For example, by flooding the .NET CLR Provider with register/unregister events, we attempted to overflow the buffers used by analysis tools. While Windows is resilient, this highlights that the consumption of events is finite. If we generate noise faster than the consumer can parse it, we create gaps in visibility.
This is the most common technique used by modern malware to hide user-land activity (like .NET assembly execution).
Most user-mode applications (including PowerShell and the .NET runtime) generate events by calling the Win32 API EtwEventWrite. This function resides in ntdll.dll. Since ntdll.dll is loaded into the memory space of every process, it is accessible to that process.
The Attack Chain:
Locate: The malware finds the memory address of the EtwEventWrite function within its own process.
Unlock: It uses VirtualProtect to change the memory permissions of that function to PAGE_EXECUTE_READWRITE.
Patch: It overwrites the very first instruction of the function with 0xC3 (the assembly opcode for RET or “Return”).
Lock: It restores the memory permissions.
The Result: Now, whenever the CLR tries to log “Suspicious Assembly Loaded,” it calls EtwEventWrite. The CPU sees the RET instruction immediately and returns “Success” to the caller. No event is sent to the kernel. No log is generated. To the EDR, the process is silent.
If ETW can be patched, killed, or flooded, how can defenders trust their data? The answer lies in Detection-in-Depth. We must stop treating ETW as infallible and start detecting the attempts to tamper with it.
Attacking ETW via logman.exe is noisy. It leaves a distinct process execution artifact. You should have high-severity alerts for any usage of logman stopping a tracing session, especially if the target session name matches your security tooling.
DeviceProcessEvents
| where FileName =~ "logman.exe"
| where ProcessCommandLine has "stop" or ProcessCommandLine has "delete"
| where ProcessCommandLine has "-ets"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
The “Surgical Strike” (patching ntdll.dll) leaves a forensic scar in memory. The ntdll.dll loaded in memory should be identical to the file on disk. If an attacker patches it, the memory page containing EtwEventWrite will be marked as Private/Commit rather than Image/Shared.
Tools for this:
Moneta / PE-sieve: These tools scan processes for “unbacked code” or modified system DLLs.
Elastic EDR: Has specific capabilities to detect when system DLLs are hooked or patched in memory.
User-mode patching only blinds user-mode telemetry. It does not blind the kernel. EDRs should utilize Kernel Callbacks (PsSetCreateProcessNotifyRoutine, ObRegisterCallbacks) for critical events like process creation and handle manipulation. These operate at a layer below ntdll.dll and are significantly harder for standard malware to tamper with.
Finally, use anomaly detection. A process that is performing complex actions (network connections, high CPU usage, file IO) but generating zero ETW events is highly suspicious.
Example: If powershell.exe is making network connections but hasn’t generated a single ScriptBlock log or CLR load event, it has likely been blinded.
ETW is a masterpiece of engineering, but in the cat-and-mouse game of cybersecurity, it is not a silver bullet. Attackers view it as a constraint to be bypassed, not a law of physics.
By understanding the mechanics of Session Killing and Function Patching, defenders can move beyond blind trust in their logs and start hunting for the absence of evidence.
Red Team: We will keep finding ways to turn off the lights.
Blue Team: Your job is to notice when the room goes dark.