Red Team Road Rage: Weaponizing Vulnerable Drivers to Blind EDR

Red Team Road Rage: Weaponizing Vulnerable Drivers to Blind EDR

Speaker: Jake Mayhew — White Knight Labs

Conference: NorthSec 2025 — May 15–16, 2025, Marché Bonsecours, Montreal

Watch on YouTube: https://www.youtube.com/watch?v=Q0Io1baL6rc

Reading time: ~8 minutes

TL;DR

Jake Mayhew, Director of Offensive Operations at White Knight Labs, walked through the architecture of Windows kernel-mode EDR components and demonstrated how a red teamer can exploit vulnerable third-party drivers to remove kernel notification callbacks, strip EDR telemetry, and defeat Process Protection Light (PPL) — culminating in a live CrowdStrike Falcon bypass demo. The talk is a practitioner-level reference for both red teams looking to evaluate EDR defenses and blue teams building detection logic against Bring Your Own Vulnerable Driver (BYOVD) attacks.

Introduction

When Jake Mayhew passed his OSCP in the mid-2010s, the labs ran Windows 2000 and unpatched Debian systems with no antivirus in sight. Real-world engagements were a different story. Loading Mimikatz against a CrowdStrike Falcon deployment meant near-immediate detection and response. That gap between lab training and production defenses is what drove Mayhew into kernel-mode research and driver exploitation — a discipline that has since moved from niche red team tradecraft to a mainstream attacker technique.

The same kernel-level bypass methods that red teamers use for authorized engagements are now routinely deployed by ransomware operators. BlackMatter, AvosLocker, and related groups have all adopted vulnerable driver techniques to strip EDR coverage before deploying encryption payloads. The defensive community has responded with the LOLDrivers project, a community-maintained database of known-vulnerable third-party drivers, but the attack surface remains wide.

Mayhew's talk at NorthSec 2025 covers the mechanics from first principles — user mode versus kernel mode, EDR telemetry architecture, PPL, kernel callbacks — and builds through to a demonstrated technique for removing those callbacks using a vulnerable driver. The audience for this talk is any practitioner who wants to understand why EDRs are difficult to disable through user-mode means alone, and what it takes to defeat them at the kernel level.

▶ Watch: Motivation and BYOVD context (0:00)

Windows Architecture: Ring Zero and Ring Three

Mayhew opened with a compact OS architecture review scoped to Windows x86. The key distinction is between user mode (ring 3) and kernel mode (ring 0). All user-facing processes — including those running as SYSTEM — operate in ring 3. The kernel, operating in ring 0, handles memory management, scheduling, hardware interaction, TCP/IP, and security enforcement.

Interaction between the two rings happens through syscalls. A user-mode process making a system call sends a request — analogous to an API call — with arguments to the kernel, which performs the operation and returns a handle or result. The user-mode process never directly observes or modifies kernel data structures. Kernel drivers (.sys files) are portable executables that run at ring 0 and communicate with user-mode software through I/O Request Packets (IRPs) and device control codes.

EDR vendors deploy kernel drivers to intercept operating system events at the source, before any user-mode hooking or process manipulation can interfere. This is what makes kernel-level EDR components qualitatively more resilient than purely user-mode security software.

▶ Watch: User mode vs kernel mode architecture (6:00)

How EDRs Use Kernel Mode: Callbacks and Telemetry

The practical impact of EDR kernel drivers becomes clear when examining the telemetry registration model. When CrowdStrike Falcon's driver loads, it registers callbacks for multiple kernel notification types. These registrations are entries in kernel-maintained arrays of function pointers. When the triggering event occurs, the kernel iterates the array and calls each registered function in sequence.

The three primary callback types Mayhew covered are:

• Process creation callbacks (PsSetCreateProcessNotifyRoutineEx): called whenever a new process is created. CrowdStrike's registered function receives the parent process, the target executable path, and the full command line. This is what enables process tree visualization and command-line argument analysis in the Falcon console.
• Thread creation callbacks (PsSetCreateThreadNotifyRoutine): called on thread creation, enabling detection of process injection, reflective DLL loading, and thread manipulation techniques.
• Image load callbacks (PsSetLoadImageNotifyRoutine): called whenever a PE image is loaded into a process. This catches attempts to remap clean copies of ntdll.dll to bypass user-mode hooks, as well as loading of known-malicious modules.

Additional telemetry sources include object manager callbacks (for detecting LSASS handle access, relevant to credential dumping) and minifilter driver hooks for filesystem and network activity. Together, these create the behavioral telemetry chain that powers modern EDR detection engines.

▶ Watch: EDR kernel telemetry sources and callback types (12:00)

Process Protection Light (PPL)

Before an attacker can disable EDR callbacks, they need to address PPL. Windows protects sensitive processes — including LSASS on Windows 11 by default, and the EDR agent process itself — using a Protection Level field in the kernel's EPROCESS structure. A process with no PPL designation, even running as SYSTEM, cannot read, write, or terminate a process running at a higher protection level.

Attempting to kill the Falcon sensor process from SYSTEM-level malware fails precisely because of this. Bypassing PPL requires either running code that has been granted an equivalent protection level — which normally requires a Microsoft-signed kernel driver — or manipulating the EPROCESS structure directly from kernel mode via a vulnerable driver that provides arbitrary kernel read/write primitives.

This is the core reason why vulnerable driver exploitation has become the standard approach for EDR evasion: it provides the kernel-level access required to modify protection structures and remove callback registrations that are otherwise unreachable from user space.

▶ Watch: PPL and kernel protections (10:00)

The BYOVD Technique: Exploiting Vulnerable Drivers

The Bring Your Own Vulnerable Driver (BYOVD) technique works as follows. An attacker loads a legitimate but vulnerable driver — one that was signed by a real vendor but contains exploitable vulnerabilities, typically unsafe IOCTL handlers that expose kernel memory read/write operations to user-mode callers without access control. The Windows kernel requires drivers to be signed before loading, so BYOVD bypasses this requirement by using a pre-existing valid signature rather than exploiting the signing requirement itself.

With a kernel read/write primitive from the vulnerable driver, an attacker can:

1. Locate the kernel callback arrays for process creation, thread creation, and image load notifications.
2. Enumerate registered callbacks and identify those belonging to the EDR driver.
3. Zero out or replace the EDR's callback function pointers, effectively removing its visibility into those event types.
4. Optionally modify the EPROCESS structure of the EDR service process to strip PPL, enabling process termination.

The LOLDrivers project (loldrivers.io) catalogs hundreds of such drivers, including historical versions of vendor drivers from GPU manufacturers, storage controllers, and system utilities. Many remain loadable on current Windows systems because the drivers retain valid signatures and Microsoft's driver blocklist is not comprehensive.

Mayhew demonstrated this technique against CrowdStrike Falcon in a live demo, removing notification callbacks and executing a payload that would otherwise have triggered immediate detection and blocking.

▶ Watch: Vulnerable driver exploitation and CrowdStrike demo (14:00)

Defensive Countermeasures

Mayhew closed with concrete guidance for defenders:

Microsoft Vulnerable Driver Blocklist. Windows maintains a list of drivers blocked from loading based on known vulnerabilities. Enabling HVCI (Hypervisor-Protected Code Integrity) enforces this blocklist and prevents the loading of many known-vulnerable drivers. HVCI is available on supported hardware (most modern enterprise systems) and is enabled by default on Windows 11 secured-core devices.

LOLDrivers monitoring. SOC teams can maintain detection rules matching driver filenames or hashes against the LOLDrivers database. Loading a driver whose hash appears in the database should generate a high-priority alert.

Kernel Threat Intelligence (KTI) and ETW-Ti. Event Tracing for Windows — Threat Intelligence (ETW-Ti) provides kernel-level telemetry that itself runs at ring 0, making it harder to suppress from user mode. Some EDRs use ETW-Ti as an additional telemetry channel specifically because it is more resistant to user-mode tampering than user-mode hooks.

Driver loading policy. Restricting which drivers can load via Group Policy or WDAC driver rules prevents an attacker from loading an arbitrary vulnerable driver. Environments that do not require driver loading outside of managed deployment channels can disable unsigned driver loading entirely.

▶ Watch: Defense and blue team recommendations (22:00)

Notable Quotes

"I don't want these pesky EDRs stopping me from doing what I want. If I want a payload on there, I just want the payload to run — so we gotta attack the EDR." — Jake Mayhew

"Attackers are resorting to vulnerable drivers to accomplish the same goals. They're wanting to spread ransomware, and disabling and attacking the EDR at the kernel level is a really good way to spread ransomware unfettered." — Jake Mayhew

"Process two, the malware process, can't read, write, terminate, do anything to the other process because there's additional kernel-mode protections in place. You have to have a PPL status of equal or higher to actually impact that other process." — Jake Mayhew

Key Takeaways

1. EDR effectiveness depends critically on kernel callbacks. Removing process creation, thread creation, and image load callbacks strips the majority of behavioral telemetry from a modern EDR, rendering it unable to detect most offensive techniques.

1. PPL protects EDR processes from user-mode termination. Even SYSTEM-level processes cannot kill PPL-protected agents, making user-mode approaches to disabling EDRs ineffective. Kernel-mode access is required to modify PPL designations.

1. BYOVD is the standard kernel-access vector. Signed but vulnerable third-party drivers provide attackers with kernel read/write primitives through legitimate code-signing mechanisms, bypassing driver signing enforcement without exploiting the signing process itself.

1. HVCI and the driver blocklist are the primary preventive controls. Enabling HVCI on supported hardware prevents known-vulnerable drivers from loading, directly blocking the most common BYOVD technique.

1. Offensive techniques directly inform ransomware operators. The same BYOVD methodology demonstrated in red team contexts has been documented in BlackMatter and AvosLocker campaigns — making this class of knowledge essential for blue teams to understand and detect.