ETW Bypassing: How Cybercriminals Disable Windows Event Logs to Stay Hidden

Before dissecting the techniques used to bypass ETW, it is essential to understand its architecture and how it operates within the Windows ecosystem. Event Tracing for Windows was introduced in Windows 2000 and has since evolved into a highly robust and complex telemetry framework. The architecture is primarily composed of three distinct components: Providers, Controllers, and Consumers.

ETW Architecture

1. Providers: These are the applications, drivers, or system components that generate events. Windows comes with thousands of built-in providers that monitor almost every aspect of the operating system, from network activity and file system changes to kernel-level API calls. For example, the Microsoft-Windows-Kernel-Process provider generates events whenever a new process or thread is created. Providers must be registered with the system, and they only generate events when they are actively enabled by a Controller.
2. Controllers: Controllers are responsible for managing ETW sessions. They have the authority to start and stop trace sessions, enable or disable specific Providers, and configure the verbosity level of the events being captured. System administrators or security software often act as Controllers, using built-in tools like logman.exe or custom code to manage the flow of telemetry.
3. Consumers: Consumers are the applications that read and analyze the events generated by Providers. This can happen in real-time or by parsing saved event log files (.etl files). Modern EDR solutions act as the primary Consumers in a corporate environment, continuously ingesting ETW data, running it through behavioral analysis engines, and alerting on suspicious activity.

ETW Threat Intelligence (ETW-Ti)

As security vendors increasingly relied on ETW to catch malware, Microsoft recognized the need for a more secure and robust telemetry source specifically designed for security products. This led to the creation of the ETW Threat Intelligence (ETW-Ti) provider, integrated directly into the Windows Kernel. ETW-Ti monitors highly sensitive operations, such as dynamic code injection, suspicious memory allocations (like VirtualAlloc with PAGE_EXECUTE_READWRITE), and thread hijacking.

Crucially, ETW-Ti operates at a higher privilege level and is protected by Early Launch Anti-Malware (ELAM) and Protected Process Light (PPL) technologies. This means that, theoretically, an attacker running with standard Administrator privileges cannot simply disable the ETW-Ti provider, making it a formidable obstacle for offensive operations.

When an attacker executes a malicious payload, the actions taken by that payload—such as allocating executable memory or injecting code into another process—trigger events via ETW providers. The EDR consumes these events and raises an alarm. To stay hidden, attackers employ ETW Bypassing techniques to break the chain between the Provider and the Consumer. These techniques typically focus on either patching the functions responsible for sending events or manipulating the environment to prevent the events from being generated in the first place.

1. Patching EtwEventWrite

One of the most common and historically effective methods for ETW Bypassing involves memory patching in userland. When a user-mode application (like a malicious executable or a compromised process) wants to log an event, it calls specific functions exported by ntdll.dll, the core system library that interfaces with the kernel. The primary function responsible for this is EtwEventWrite (or EtwEventWriteFull).

Because ntdll.dll is loaded into the memory space of every user-mode process, an attacker who has compromised a process can modify the memory permissions of the EtwEventWrite function and overwrite its first few bytes with a RET (Return) instruction.

When the patched process subsequently attempts to log a suspicious action (such as executing a .NET assembly via Assembly.Load), the execution flow hits the EtwEventWrite function, encounters the RET instruction, and immediately returns execution to the caller without ever passing the event data to the kernel. The EDR, relying on the ETW consumer, receives nothing, and the malicious activity proceeds undetected. While highly effective, this technique has become well-known, and many EDRs now actively monitor for memory modifications to critical functions within ntdll.dll.

2. Disabling Providers via COM and Registry

Another approach involves preventing specific Providers from generating events by manipulating system configurations. Some ETW providers are configured via the Windows Registry or rely on Component Object Model (COM) interfaces. If an attacker has sufficient privileges, they can modify these configurations to silence the telemetry.

For example, the Anti-Malware Scan Interface (AMSI), which is closely related to ETW for logging script execution (like PowerShell or VBScript), can be bypassed by manipulating registry keys to unregister the AMSI provider or by patching the AmsiScanBuffer function similarly to EtwEventWrite. Disabling specific ETW providers often requires elevated privileges, but it provides a clean bypass without the need for memory patching, which might trigger other heuristic alerts.

3. Utilizing Hardware Breakpoints

As EDR solutions became adept at detecting in-memory patching of ntdll.dll, attackers shifted to more sophisticated techniques, such as utilizing Hardware Breakpoints. Instead of modifying the memory of EtwEventWrite directly, an attacker can set a hardware breakpoint on the function's address using the debug registers (DR0-DR3) of the CPU.

When the process attempts to call EtwEventWrite, the CPU triggers an exception before the instruction is executed. The attacker's custom exception handler intercepts this event, modifies the execution context (such as changing the instruction pointer or zeroing out the event data arguments), and resumes execution. This technique is highly stealthy because the bytes of the EtwEventWrite function remain unaltered, effectively bypassing EDR memory integrity checks.

4. Direct System Calls (Syscalls)

Perhaps the most robust method for evading user-mode ETW telemetry is the use of Direct System Calls. Instead of calling the standard Windows APIs (which internally call the ETW logging functions before transitioning to the kernel), an attacker can manually implement the assembly instructions required to transition directly into the kernel.

By bypassing ntdll.dll entirely, the attacker avoids the user-mode hooks and ETW logging functions placed there by the operating system and the EDR. When the attacker executes a direct syscall to allocate memory or create a thread, the action occurs directly in the kernel, leaving the user-mode ETW providers completely blind. However, this does not bypass kernel-level ETW providers like ETW-Ti, which monitor the activity from within the kernel itself.

5. Kernel-Level Bypasses (BYOVD)

To bypass ETW-Ti and other kernel-level telemetry, attackers must achieve code execution in the kernel, crossing the boundary from Ring 3 (user mode) to Ring 0 (kernel mode). Because modern Windows systems strictly enforce Driver Signature Enforcement (DSE), attackers cannot simply load a malicious, unsigned driver.

Instead, they employ a technique known as Bring Your Own Vulnerable Driver (BYOVD). The attacker drops a legitimate, digitally signed driver that contains a known vulnerability (such as an arbitrary read/write primitive). By exploiting this vulnerable driver, the attacker gains the ability to read and write kernel memory. From there, they can patch kernel data structures, disable the ETW-Ti callbacks, or unregister the EDR's kernel-mode consumer, completely blinding the security product at the highest privilege level.

The impact of ETW Bypassing is evident in numerous advanced cyber attacks and Red Team engagements where threat actors successfully operated undetected for extended periods.

A prime example involves the deployment of highly sophisticated ransomware by APT groups. In several incidents, attackers initially gained access to a corporate network via a phishing payload. Once a foothold was established, the malware executed a routine that patched EtwEventWrite in the memory of its own process. By doing so, the malware was able to dynamically load post-exploitation frameworks, such as Cobalt Strike, directly into memory without triggering the EDR's alerts for suspicious module loading or .NET assembly execution. The attackers then moved laterally, harvested credentials, and ultimately deployed ransomware across the enterprise—all while the EDR remained silent, deprived of the necessary ETW telemetry.

Another significant example highlights the use of BYOVD techniques by nation-state actors. In a targeted espionage campaign, attackers deployed a vulnerable version of a popular anti-cheat driver to targeted systems. By exploiting the driver, they gained kernel-level access and systematically disabled the ETW-Ti provider and the specific kernel callbacks registered by the organization's EDR solution. This kernel-level blinding allowed the attackers to deploy rootkits, hide their network connections, and maintain long-term persistence, effectively rendering the endpoint security controls useless.

These real-world scenarios demonstrate that as defensive technologies rely more heavily on specific telemetry sources, offensive actors will continuously innovate to sever that telemetry stream.

Defending against ETW Bypassing requires a defense-in-depth approach. Security teams cannot rely on a single data source or detection method; they must assume that an advanced attacker will attempt to blind their tools and build robust mechanisms to detect the blinding attempts themselves.

1. Monitor for API Hooking and Memory Patching

While attackers attempt to bypass ETW by patching functions like EtwEventWrite, defensive tools must actively monitor the integrity of critical system libraries. EDR solutions should routinely verify the memory pages of ntdll.dll and other core components against their on-disk representations. Any discrepancy—such as a RET instruction placed at the beginning of an ETW function—should immediately trigger a high-severity alert indicating tampering.

2. Leverage Kernel-Level Telemetry

User-mode telemetry is inherently fragile because it operates at the same privilege level as the attacker's initial payload. To ensure reliable visibility, organizations must deploy security solutions that leverage robust kernel-level telemetry, such as ETW-Ti and Kernel Callbacks. Because modifying these components requires Ring 0 access and bypassing security boundaries like PatchGuard, they provide a much higher degree of assurance than user-mode logs.

3. Implement Strict Application Control and Attack Surface Reduction

The most effective way to prevent ETW Bypassing is to stop the malicious code from executing in the first place. Implement strict Application Control (such as Windows Defender Application Control - WDAC) to ensure that only authorized and digitally signed executables can run on corporate endpoints. Additionally, utilize Attack Surface Reduction (ASR) rules to block common infection vectors, such as Office macros launching child processes or obfuscated scripts executing via Windows Script Host.

4. Detect BYOVD Attacks

To defend against kernel-level ETW bypasses, organizations must actively combat the Bring Your Own Vulnerable Driver (BYOVD) technique. Maintain up-to-date blocklists of known vulnerable drivers (such as the Microsoft Vulnerable Driver Blocklist) and enforce strict policies that prevent standard users from loading drivers. Security operations teams should aggressively monitor for unexpected driver installations, especially those signed by obscure or revoked certificates.

5. Correlate Disparate Data Sources (XDR)

When an attacker successfully bypasses ETW on a specific endpoint, that endpoint goes "dark." However, the attacker's actions will likely generate noise elsewhere. By implementing Extended Detection and Response (XDR) and correlating data across multiple domains—such as network traffic analysis, identity logs, and cloud telemetry—security teams can detect the secondary indicators of an attack. Even if the endpoint telemetry is silenced, abnormal lateral movement or unusual authentication patterns can reveal the attacker's presence.