Bypassing EDR Telemetry via Kernel-Mode Callback Manipulation

TLDR: This research demonstrates how attackers can use signed, vulnerable drivers to gain kernel-mode execution and systematically dismantle security telemetry. By manipulating kernel callbacks and Event Tracing for Windows (ETW), an attacker can effectively blind EDR solutions without triggering alerts. Pentesters should prioritize auditing third-party drivers in their environments, as these represent a massive, often overlooked, attack surface for privilege escalation and persistence.

Security researchers often focus on user-mode bypasses, but the real battle for endpoint control is fought in Ring 0. When an attacker achieves kernel-mode execution, the operating system's security features—and the EDR agents tasked with monitoring them—are essentially running on borrowed time. The recent presentation at Black Hat 2023, "Close Encounters of the Advanced Persistent Kind," provides a masterclass in how modern adversaries are moving beyond simple process injection to surgically disable the very telemetry that defenders rely on.

The Mechanics of Kernel Subversion

The core of this research centers on the "Bring Your Own Vulnerable Driver" (BYOVD) technique. By loading a signed but vulnerable driver, an attacker can execute arbitrary code in the kernel. Once there, the goal is not just to escalate privileges, but to maintain a stealthy presence by blinding the EDR.

The researchers focused on two primary targets: kernel callbacks and ETW. Windows uses kernel callbacks to notify security products about system events like process creation, thread injection, or registry modifications. If an attacker can locate the array of pointers that the kernel uses to manage these callbacks, they can simply remove their malicious process from the list or redirect the callback to a benign function.

The same logic applies to ETW. Security products ingest vast amounts of data through ETW providers to build their detection heuristics. By locating the ETW_REG_ENTRY structures in kernel memory, an attacker can modify the IsEnabled flag or alter the TraceEnableInfo structure to selectively filter out events. This allows the attacker to perform malicious actions—like process injection or credential dumping—while the EDR remains completely unaware, as the necessary telemetry never reaches the user-mode agent.

Exploiting CVE-2023-21768

A highlight of the talk was the demonstration of CVE-2023-21768, a vulnerability in the Ancillary Function Driver (AFD). The researchers showed how insufficient user-mode checks allowed them to write a semi-controlled value to a kernel address.

The exploit flow is remarkably efficient:

1. Identify the vulnerable driver.
2. Trigger the memory corruption to gain a write-what-where primitive.
3. Use this primitive to locate and modify the callback or ETW structures.
4. Execute the payload with SYSTEM privileges.

The researchers noted that the entire process, from analyzing the patch to weaponizing the exploit, took less than 24 hours. This speed underscores the danger of relying on signature-based detection for known vulnerable drivers. If you are not actively blocking known vulnerable drivers via Microsoft's recommended blocklist, you are leaving the front door wide open.

The Role of Feature Flags

Beyond direct memory manipulation, the talk explored the use of Windows feature flags to alter system behavior. Windows uses these flags to toggle experimental features, but they can also be used to disable security mitigations. Tools like Vive and Mach2 are already popular for enabling hidden OS features, but the researchers demonstrated that these flags can be manipulated directly in kernel memory using DKOM (Direct Kernel Object Manipulation).

By modifying the nt!CmfSystemManager object, an attacker can toggle features that might otherwise be locked behind administrative policies. This is a powerful, under-researched area for persistence. If an attacker can flip a bit in memory to disable a security feature, they don't need to worry about persistent registry keys or file system changes that might be flagged by integrity checkers.

Defensive Realities

Defending against kernel-mode rootkits is notoriously difficult because the attacker has the same level of privilege as the security software. However, the path forward is clear. First, implement Windows Defender Application Control (WDAC) to strictly control which drivers are allowed to load. The WDAC Wizard is the standard tool for generating these policies.

Second, move toward hardware-backed security. Features like Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) create an isolated environment that prevents even a compromised kernel from modifying critical system structures. While these mitigations are not a silver bullet—as demonstrated by the researchers' discussion of page-swapping attacks—they significantly raise the cost of exploitation for the attacker.

The era of assuming the kernel is a trusted boundary is over. Pentesters should start treating third-party drivers as high-value targets during every engagement. If you can load a driver, you can own the box. The next time you are on an assessment, look at the loaded modules. If you see an old, signed driver from a legacy vendor, you might be looking at your path to SYSTEM.