EDR Bypass via Kernel Callbacks in 2025: Direct Syscalls, BYOVD Evolution, and Detection Engineering

Cybersecurity

EDR evasion has matured from userland API hooking bypasses to kernel-level callback removal and vulnerable driver exploitation. A 2025 technical analysis of the attack surface, the evolving BYOVD landscape, and practical detection engineering responses.

By Arjun Raghavan, Security & Systems Lead, BIPI · August 15, 2025 · 13 min read

The arms race between endpoint detection tools and adversaries has, in 2025, firmly moved to the kernel. The era of userland EDR bypass — unhooking ntdll.dll, using indirect syscalls, or loading a clean copy of the DLL from disk — is not over, but sophisticated adversaries treat it as a fallback. The primary offensive focus in 2025 is kernel-level interference: removing or manipulating the callbacks that EDR products register with the Windows kernel to receive notification of process creation, image loading, and thread operations.

This shift has been driven by three trends: the maturation of Bring Your Own Vulnerable Driver techniques following the public release of multiple working exploit templates, the publication of open-source callback removal tooling, and the recognition by ransomware operations including RansomHub and Play that neutralising EDR before encryption significantly increases success rates.

How EDR Uses Kernel Callbacks

Windows provides a set of kernel notification routines that drivers can register to receive real-time notification of system events. EDR products use these to observe process creation, image loads including DLLs and executables, thread creation, registry operations, and object operations including handle duplication. By removing or patching these callbacks, an attacker can operate in a system where the EDR product is running but blind to most malicious activity.

BYOVD in 2025: The Technique

BYOVD exploits the code-signing requirement for kernel drivers on Windows. Attackers cannot load an unsigned malicious driver, but they can load a legitimately signed driver that has a known privilege escalation or arbitrary memory write vulnerability. Using the vulnerability, they obtain a kernel-mode write primitive and can patch kernel structures directly — including the callback arrays.

1. Select a vulnerable signed driver from the LOLDrivers database appropriate for the target OS version
2. Load driver via Service Control Manager or via NtLoadDriver for a lower-noise approach
3. Exploit the driver vulnerability using a known IOCTL-triggered arbitrary write to obtain a kernel write primitive
4. Walk kernel memory to find PspNotifyEnableMask and the callback array structures
5. Remove or null callbacks: overwrite the callback function pointers to prevent EDR notification
6. Execute payload: with EDR callbacks removed, standard offensive techniques proceed without interception

Evolution Beyond BYOVD

Microsoft has progressively expanded the Vulnerable Driver Blocklist, which prevents known-vulnerable drivers from loading even if legitimately signed. In response, the offensive community has pivoted to multiple alternative approaches: exploiting drivers not yet on the blocklist, using newer direct kernel object manipulation techniques that do not require a vulnerable driver, and leveraging kernel-mode exploits in the hypervisor or secure boot chain.

• Living-off-the-land kernel drivers: abusing legitimately installed security product drivers with IOCTL interfaces that allow kernel reads
• ETW patching: targeting Event Tracing for Windows kernel providers to prevent telemetry reaching EDR platforms
• PPL attacks: using BYOVD to remove Protected Process Light protection from EDR process, then terminating it
• Hypervisor-level attacks: targeting Hyper-V root partition for environments where kernel protections are enforced via VBS
• Direct kernel object manipulation: hiding processes and drivers from kernel linked lists without callback removal

Detection Engineering Responses

Defending against kernel-level EDR bypass requires detection both before the bypass is achieved and at points the bypass does not cover. The pre-bypass detection window is the most reliable: a BYOVD attack requires loading a driver, which is a high-privilege, infrequent operation that should trigger immediate investigation.

• Alert on any kernel driver load (Event ID 6 in Sysmon) that is not in an approved driver whitelist
• Monitor for LOLDrivers database matches: hash the loaded driver and compare against the loldrivers.io hash list in real time
• Ensure Microsoft Vulnerable Driver Blocklist is enforced via Windows Defender Application Control policy
• Maintain ETW-based kernel telemetry pipelines: Microsoft Defender for Endpoint uses ETW providers that survive some callback removal
• Canary callback: some defensive tools register a decoy callback that alerts when removed — commercial EDRs increasingly implement this
• Use WDAC to prevent driver loads from non-OS paths except explicitly approved vendors

The most important detection window for BYOVD attacks is before the vulnerable driver loads, not after it removes EDR visibility. Once callbacks are removed, the EDR is running but not watching. The defence must happen earlier in the chain.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.