You’re Driving Me Crazy: Analysing and Detecting BYOVD

1. Abstract

Bring Your Own Vulnerable Driver (BYOVD) attacks represent a sophisticated class of kernel-level threats that exploit the Windows driver signing and trust model. Signed drivers, once cryptographically verified and loaded by the kernel, operate with ring-0 privileges and can invoke kernel APIs without caller-identity validation. Adversaries weaponize known-vulnerable signed drivers to accomplish objectives that user-mode code could never achieve: terminating Protected Process Light (PPL) services, disabling Endpoint Detection and Response (EDR) sensors, manipulating kernel data structures, and bypassing Hypervisor-Protected Code Integrity (HVCI).

Figure 1: Windows privilege ring model — BYOVD attacks exploit legitimate signed drivers operating at Ring 0 to bypass all user-mode security controls.

This document presents a comprehensive behavioral detection methodology for BYOVD attacks, grounded in primary vulnerability research on two kernel-mode drivers: the WatchDog Antimalware driver (version 1.1.100) and the eb kernel driver. Both drivers expose unauthenticated IOCTL interfaces that allow any user-mode process to terminate PPL-protected security processes at ring-0, bypassing all user-mode access controls. The WatchDog case demonstrates a two-stage exploitation chain via an unauthenticated process allowlist, while the eb driver represents a structurally simpler primitive — a single IOCTL call with no registration step — illustrating that the most dangerous attack surfaces are often the most minimal. The methodology covers the full detection stack: from Windows kernel driver architecture and IOCTL dispatch internals, to real-world ransomware campaign analysis, to building operational KQL detection queries and an incident response playbook for both drivers.

Key contributions include: primary vulnerability research on WatchDog v1.1.100 and eb driver, a comparative analysis of their exploitation mechanics and root cause design flaws, real-world BYOVD case studies covering Qilin (Killer Ultra) and RansomHub (EDRKillShifter) with caller binary analysis, a model for correlating driver-drop and driver-load telemetry, KQL queries for hunting BYOVD campaigns, a structured incident response playbook covering containment through post-eradication verification, and defensive hardening recommendations aligned with MITRE ATT&CK.

2. Threat Context and Adversary Motivation

2.1 Why BYOVD Persists as an Effective Attack Vector

BYOVD attacks have been documented across ransomware-as-a-service (RaaS) operations, APT campaigns, and commodity malware distributions for over a decade. Despite increased industry awareness and Microsoft's ongoing efforts through the Vulnerable Driver Blocklist (DriverSiPolicy.p7b), the technique remains highly effective. Three fundamental properties of the Windows kernel security model explain why:

• Signing authority ≠ behavioral trust: Windows Kernel Mode Code Integrity (KMCI) verifies that a driver binary carries a valid authenticode signature from a trusted CA. It does not validate the driver's internal logic, the IOCTLs it exposes, or the access controls it enforces on callers. A driver signed in 2015 with a now-revoked certificate may still load on systems without Certificate Revocation List (CRL) enforcement.
• Exposed IOCTLs without caller validation: The Windows I/O Request Packet (IRP) model allows any user-mode process with a handle to a driver's device object to send IOCTLs. Unless the driver explicitly validates the caller's identity, privilege level, or security context, any process — including low-integrity malware — can trigger privileged kernel operations.
• Kernel callback and protection mechanism gaps: PPL protections and EDR kernel callbacks (PsSetCreateProcessNotifyRoutine, PsSetLoadImageNotifyRoutine) can be circumvented if a loaded driver directly manipulates kernel structures such as EPROCESS.Protection or removes entries from the notification callback arrays.

2.2 The EDR Killer Marketplace: Commoditisation on Underground Forums

The operational effectiveness of BYOVD attacks has created a secondary market on cybercriminal forums where EDR killer tooling is sold, leased, and distributed as a commercial product. The three listings below, observed in early 2026 on a Russian-language crimeware forum, illustrate how the technical barrier to deploying BYOVD has collapsed to the point where a threat actor with no kernel expertise and a budget of a few thousand dollars can acquire a fully functional EDR termination capability with source code included.

"Artjkee" EDR + AV Killer Builder (December 9, 2025)

Figure 2: Underground forum listing for the "Artjkee" EDR + AV Killer Builder, priced at $70 — illustrating the commoditisation of kernel-level EDR bypass tooling. Screenshot from Rehub Forum.

The first listing, posted on December 9, 2025 by "Artike", highlights the continued commoditisation of EDR bypass tooling at the lowest end of the market. The advertisement promotes a generic "EDR + AV killer" builder priced at $70, significantly undercutting typical market rates.

The vendor claims compatibility with several major endpoint security products, including Kaspersky, ESET, Sophos Endpoint, SentinelOne, Avast/AVG, and CrowdStrike. The description states that the tool operates "from under the kernel," suggesting the use of kernel-level techniques, potentially aligned with BYOVD-style approaches, to disable or terminate security agents.

Unlike higher-tier offerings, this listing emphasizes accessibility over sophistication. The use of a builder model enables buyers to generate customized payloads, lowering the technical barrier for less experienced actors. At the same time, the extremely low price point and lack of vendor reputation indicate a higher risk of limited functionality, recycled code, or short-lived seller activity.

Despite its simplicity, the listing reflects a broader trend: EDR evasion capabilities are increasingly accessible to entry-level threat actors, contributing to the expansion of the attack surface and the diversification of techniques observed in the wild.

"Baphomet" Advanced AV/EDR Kill Process Software (January 23, 2026)

Figure 3: The "Baphomet" EDR killer listing, featuring professional branding and commercial-grade marketing language typically associated with legitimate security products. Screenshot from Rehub Forum.

The second listing, posted by a Premium-tier vendor operating under the handle "Бафомет" (Baphomet), advertises an "Advanced AV/EDR Kill Process Software". The vendor joined the forum on August 19, 2025 and has accumulated a reaction score of 64, indicating a moderately established reputation on the platform.

The advertisement presents the tool in explicitly commercial language — "Take Full Command of Your System", "Unlock True Potential", "Regain Control" — adopting the same product positioning language used by legitimate security software vendors. The advertised capabilities are: disabling AV/EDR processes and bypassing security restrictions. The professional production quality of the listing — custom banner, branded layout, copywritten feature descriptions — reflects the maturation of the crimeware-as-a-service ecosystem, where vendors invest in presentation to attract ransomware affiliates and initial access brokers.

"3in1" EDR + AV Killer with Full Source Code (February 7, 2026)

Figure 4: The "3in1" EDR killer listing offering full source code for $4,000, targeting 16 named enterprise security products including CrowdStrike and SentinelOne. Screenshot from Rehub Forum.

The third listing is structurally more significant from a threat intelligence perspective. Posted by a new user ("3in1", joined the same day, zero reaction score), it advertises an "EDR + AV killer with full source code" targeting 16 named security products:

CrowdStrike, SentinelOne, Cortex (Palo Alto), TrendMicro, Cylance, Sophos, Bitdefender, FireEye, Carbon Black, Windows Defender, ESET, Avira, McAfee, AVG/Avast, Norton, Kaspersky.

The asking price is $4,000 + middleman (escrow service), with the sale including complete source code and compilation instructions. This pricing model is consistent with observed market rates for purpose-built offensive tooling: the inclusion of source code rather than just a compiled binary substantially increases the value — and the danger — of the offering, as the buyer can modify, rebrand, and resell the tool independently.

The explicit targeting of CrowdStrike, SentinelOne, and Cortex alongside consumer AV products indicates that the tool is positioned for use in enterprise ransomware operations rather than consumer-facing attacks, as these products are predominantly deployed in corporate environments.

Market Dynamics and Implications

These listings, posted within a month of each other, illustrate how BYOVD attack deployment has become fully commoditised and detached from deep technical expertise. Buyers no longer need kernel or driver knowledge—just basic tools like a compiler and local admin access.

This commoditisation directly impacts detection strategies: underground BYOVD tools tend to share identifiable behaviors—such as common service names, driver paths, and IOCTL commands—that remain consistent across campaigns until updated. This uniformity enables defenders to create high-fidelity detection rules that can identify multiple ransomware groups using the same toolkit, improving defensive efficiency despite the growing threat.

2.3 BYOVD in the Modern Threat Landscape

Figure 5: The BYOVD threat landscape — showing how vulnerable signed drivers are exploited across ransomware, APT, and commodity malware campaigns.

Recent campaigns demonstrate BYOVD's continued operational use across diverse threat actor profiles. Ransomware operators, including groups associated with RansomHouse, Qilin, and LockBit affiliates, have integrated BYOVD tooling into their pre-encryption kill chain specifically to neutralize EDR products before deploying payloads. Nation-state actors have used similar techniques in supply chain intrusions and targeted espionage campaigns, where persistence and stealth take priority over speed.

The vulnerable driver ecosystem is extensive. The LOLDrivers project (loldrivers.io) catalogs hundreds of signed drivers with known vulnerabilities. Common vulnerability classes include: arbitrary kernel memory read/write via MmMapIoSpace or ZwMapViewOfSection, arbitrary process termination via ZwTerminateProcess with kernel-level privileges, kernel callback removal by directly patching callback arrays, and virtual-to-physical address translation primitives that enable full memory manipulation.

Toolkits such as gmer, TDSSKiller (legitimate security tools), and purpose-built BYOVD loaders like EDRKillShifter and Terminator have been observed in incident response cases, making this class of attack accessible even to less sophisticated threat actors who purchase access to post-exploitation frameworks.

2.4 Case Study: BYOVD in Active Ransomware Campaigns

The Caller Binary Problem

The vulnerable driver is the weapon, but it cannot act alone. Every real-world BYOVD deployment observed in incident response requires a caller binary — a user-mode executable that orchestrates the full chain: dropping the driver to disk, registering the kernel service, opening a handle to the device object, and issuing the privileged IOCTLs. Understanding this two-component model is essential for detection engineering, because the driver and the caller binary generate distinct and separately detectable telemetry.

The caller binary is typically a custom-built tool, purpose-compiled for the campaign, and often packed or encrypted to resist static analysis. It embeds the driver as a resource (compiled-in bytes extracted at runtime) or downloads it from a staging server. In both cases, the binary is the primary actor visible to process telemetry, and the driver is the payload it deploys.

Qilin — Killer Ultra (July 2024)

A tool leveraged in Qilin ransomware attacks aimed at impairing defenses by disabling popular EDR and AV tools, labelling it "Killer Ultra" based on a module name within the malware.

Caller binary: KillerUltra.exe — a custom-packed executable embedding the Zemana driver as a compiled-in resource.

Driver: zamguard64.sys / zam64.sys (Zemana AntiLogger v2.74.204.664), exploiting CVE-2024-1853 via IOCTL 0x80002048.

After the initialization phase, Killer Ultra loads an unhooked copy of NTDLL by spawning notepad.exe, then unpacks the vulnerable Zemana driver to disk. The driver is executed by creating a service named "StopGuard", with CreateServiceW writing a registry key at HKLM\System\ControlSet001\Services\StopGuard with the ImagePath referencing the extracted file.

With the driver installed and the service running, Killer Ultra targets a predefined list of security products defined by process names XOR-encoded by 3. If a process name match is found, the malware terminates the process with kernel-level permissions. Targets include Symantec Antivirus, Microsoft Windows Defender, SentinelOne, and Microsoft Defender for Endpoint.

The NTDLL unhooking step is significant: by loading a clean copy of ntdll.dll from a sacrificial notepad.exe process, Killer Ultra removes user-mode API hooks that EDR products inject to monitor system calls — before the driver is even loaded. This gives the caller binary a clean execution environment from which to operate the BYOVD chain.

RansomHub — EDRKillShifter (May 2024)

The EDRKillShifter tool is a loader executable — a delivery mechanism for a legitimate driver that is vulnerable to abuse. Depending on the threat actor's requirements, it can deliver a variety of different driver payloads.

Caller binary: EDRKillShifter.exe — a three-stage loader requiring a 64-character password passed on the command line to decrypt its payload.

Driver: variable per deployment — confirmed samples include RentDrv2.sys and ThreatFireMonitor.sys.

The execution process involves three steps: the attacker executes EDRKillShifter with a command-line password string; when run with the correct password, the executable decrypts an embedded resource named BIN and executes it in memory; the BIN code then unpacks and executes the final payload, written in Go, which drops and exploits one of a variety of vulnerable legitimate drivers to gain privileges sufficient to unhook the EDR tool's protection.

After the malware creates a new service for the driver, starts the service, and loads the driver, it enters an endless loop that continuously enumerates running processes, terminating those whose names appear on a hardcoded target list.

The password-gating mechanism serves a dual purpose: it prevents sandbox detonation (the binary appears inert without the correct password) and it ties each deployment to a specific operator, functioning as a rudimentary access control mechanism between the RaaS operator and affiliates.

EDRKillShifter, initially associated with RansomHub actors since August 2024, has also been identified in attacks linked to Medusa, BianLian, and Play ransomware groups, suggesting a level of cross-group tooling collaboration among typically closed RaaS operations.

Structural Pattern Across Campaigns

Both cases follow an identical structural pattern, which generalises across observed BYOVD ransomware deployments:

Figure 6: Real-world BYOVD deployment model — the caller binary orchestrates the full attack chain while the vulnerable driver provides the kernel-level kill primitive.

The detection implication is clear: monitoring for the driver alone is insufficient. The caller binary — which is always present, always executes first, and always generates process creation and file write telemetry before the driver loads — is the primary detection surface.

3. Windows Kernel Driver Architecture: Technical Foundations

3.1 The Windows Driver Model and IRP Dispatch

Figure 7: IRP dispatch flow — showing how a user-mode DeviceIoControl call is packaged into an IRP and dispatched to the kernel driver's handler function.

Windows drivers operate as kernel-mode modules that handle I/O requests through a structured dispatch table. When a kernel module is loaded, it registers a set of IRP (I/O Request Packet) major function handlers via its DRIVER_OBJECT structure. The most relevant for BYOVD exploitation is IRP_MJ_DEVICE_CONTROL, which handles DeviceIoControl requests originating from user space.

The dispatch flow from user space to kernel is as follows:

• A user-mode process calls DeviceIoControl(hDevice, dwIoControlCode, ...), passing a device handle and a control code (IOCTL).
• The Windows I/O Manager packages this into an IRP with type IRP_MJ_DEVICE_CONTROL and places the IOCTL code in the IRP stack location.
• The I/O Manager dispatches the IRP to the driver's registered handler function (typically labeled DispatchDeviceControl or IoControl in reverse engineering tools).
• The handler function examines the IOCTL code using a switch/case structure and routes execution to the appropriate subroutine.
• The subroutine performs the privileged operation (e.g., process termination, memory mapping) and completes the IRP with IoCompleteRequest.

Critically, the I/O Manager does NOT validate who is sending the IOCTL or whether the caller has permission to invoke a particular code path. This enforcement responsibility falls entirely on the driver author. Drivers that omit caller-identity checks, token privilege validation, or process signature-level verification are vulnerable to abuse by any process that can open a handle to the device object.

3.2 Protected Process Light (PPL) and Its Limitations

PPL was introduced in Windows 8.1 to prevent untrusted processes from performing sensitive operations on security-sensitive processes such as antivirus engines, LSASS, and EDR agents. A process running at a PPL level (e.g., PsProtectedSignerAntimalware-Light) can only be accessed by processes at the same or higher PPL level.

The protection is enforced at the kernel level through the EPROCESS.Protection byte. When a process attempts to open a handle with permissions such as PROCESS_TERMINATE or PROCESS_VM_WRITE, the kernel checks whether the caller's PPL level is sufficient. If not, the call returns STATUS_ACCESS_DENIED.

However, PPL provides no protection against kernel-mode code. A driver executing in ring-0 can directly call PsLookupProcessByProcessId followed by TerminateProcess (or use ZwTerminateProcess with a kernel-fabricated handle) to terminate any process regardless of its PPL status. This is the fundamental reason why BYOVD is effective against modern EDR: once an attacker loads a vulnerable driver, PPL becomes irrelevant.

3.3 HVCI and Code Signing Enforcement

Figure 8: HVCI protection model — while HVCI prevents direct kernel code injection, it does not prevent legitimately signed vulnerable drivers from loading and being exploited.

Hypervisor-Protected Code Integrity (HVCI), also known as Memory Integrity in Windows Security settings, uses hardware virtualization to protect the kernel code integrity policy. Under HVCI, the kernel page table entries are managed by the hypervisor, and executable pages cannot be made writable. This prevents common kernel exploitation techniques such as patching kernel code in-place.

However, HVCI does not prevent a legitimately signed driver from loading. A driver that has passed KMCI signature verification will still load under HVCI. If that driver contains a vulnerability — such as exposing an unsafe IOCTL — HVCI provides no barrier to its exploitation. Attackers specifically select BYOVD techniques in HVCI environments precisely because direct kernel code injection is blocked, but driver-based abuse is not.

The Microsoft Vulnerable Driver Blocklist (enforced via DriverSiPolicy.p7b and WDAC policies) attempts to address this by maintaining a list of known-bad driver hashes and version ranges. However, the blocklist has coverage gaps, update latency, and requires active WDAC enforcement to be effective.

4. Case Study: WatchDog Antimalware Driver v1.1.100

4.1 Driver Overview and Initial Triage

The WatchDog Antimalware driver (internal name: watchdogantimalware.sys or similar) is a kernel-mode component shipped with a commercial endpoint security product. Version 1.0.600 was previously identified as exploitable and patched; however, subsequent research revealed that version 1.1.100 contained residual vulnerabilities. This document focuses on the v1.1.100 vulnerability chain that enables an attacker to terminate Protected Process Light (PPL) processes.

Initial static analysis of the driver binary reveals:

• Authenticode signature: Valid, signed by a trusted certificate authority, listed in Windows trusted signers store.
• Driver type: Kernel-mode driver (PE with IMAGE_FILE_DRIVER characteristics), loaded via Service Control Manager.
• Device object name: Accessible via a named device object (e.g., \\.\amsdk), allowing user-mode access.
• IRP dispatch table: Implements IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_DEVICE_CONTROL at minimum.

Figure 9: WatchDog driver exploitation flow — showing the two-stage IOCTL chain from PID registration to PPL process termination.

4.2 IOCTL Discovery and Reverse Engineering

Reverse engineering the DispatchDeviceControl function using a disassembler reveals a switch table indexed by IOCTL control code. IOCTL codes are 32-bit values with the structure: DeviceType (bits 16-31), Access (bits 14-15), Function (bits 2-13), Method (bits 0-1).

Two IOCTLs are relevant to the exploit chain:

• IOCTL_REGISTER_PROCESS: This IOCTL accepts a process ID (PID) as input buffer and adds it to an internal kernel-space allowlist data structure (e.g., a linked list or array within a non-paged pool allocation). The allowlist is initialized on driver load and persists for the driver's lifetime. No caller verification is performed — any process can call this IOCTL.

Figure 10: Disassembly of the WatchDog driver IOCTL registration handler — showing the unauthenticated PID allowlist mechanism.

• IOCTL_TERMINATE_PROTECTED_PROCESS: This IOCTL accepts a target PID as input. The handler function checks whether the calling process's PID is present in the allowlist maintained by IOCTL_REGISTER_PROCESS. If the PID is found, the handler proceeds to terminate the target process using kernel-level APIs, bypassing PPL.

Figure 11: Disassembly of the WatchDog driver termination handler — the allowlist check precedes the kernel-level process kill.

The vulnerability chain is therefore: an attacker process (1) calls DeviceIoControl with IOCTL_REGISTER_PROCESS and its own PID, then (2) calls DeviceIoControl with IOCTL_TERMINATE_PROTECTED_PROCESS and the target EDR process's PID. Because the allowlist check only validates PID presence — not process identity, token integrity, or signature level — any unprivileged process can complete this chain.

4.3 Exploit Demonstration and Impact

Proof-of-concept exploitation requires no kernel exploits, no UAC bypass, and no special privileges beyond the ability to create a service (which requires local administrator rights on most configurations). The attack proceeds as:

• Drop the signed driver binary (watchdog_v1.1.100.sys) to a writable path such as %TEMP% or C:\ProgramData.
• Create and start a kernel driver service using sc.exe or NtLoadDriver: sc create WatchDog type= kernel binPath= C:\temp\watchdog.sys && sc start WatchDog
• Open a handle to the device object: CreateFile("\\\\.\\amsdk", GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL)
• Register PID: DeviceIoControl(hDevice, IOCTL_REGISTER_PROCESS, &myPid, 4, NULL, 0, &bytesReturned, NULL)
• Enumerate running EDR processes (e.g., MsMpEng.exe, CSFalcon.exe) via Process32First/Next and resolve their PIDs.
• Terminate each target: DeviceIoControl(hDevice, IOCTL_TERMINATE_PROTECTED_PROCESS, &targetPid, 4, NULL, 0, &bytesReturned, NULL)

The result is successful termination of PPL-protected security processes. The kernel logs no anomalous activity beyond standard driver load events. Standard user-mode EDR hooks and AMSI callbacks are rendered inoperative if the EDR host process is terminated.

4.4 Patch Analysis: Version 1.1.200.0

The vendor's remediation in version 1.1.200.0 addresses the vulnerability by adding a Protected Process check within the IOCTL_TERMINATE_PROTECTED_PROCESS handler. The patched logic retrieves the EPROCESS.Protection field of the target process and refuses termination if the protection level exceeds a threshold corresponding to PPL-AntiMalware. This prevents the driver from being weaponized against security processes, regardless of whether the caller is registered in the allowlist.

The fix does not address the root cause — that IOCTL_REGISTER_PROCESS lacks caller identity validation — but it does eliminate the practical exploitation path for terminating protected security processes. Analysts should note that the underlying design weakness (unauthenticated IOCTL dispatch) remains and could potentially be abused for other purposes.

5. Case Study: eb Kernel Driver

5.1 Driver Overview and Initial Triage

The eb driver is a kernel-mode driver exposing a user-accessible device object (\\.\eb) and implementing a custom IOCTL interface. Unlike traditional endpoint protection drivers, eb does not appear to enforce strict access control on its device object nor implement caller validation inside its IOCTL handlers.

Initial static and dynamic triage reveals:

• Driver type: Kernel-mode driver (IMAGE_FILE_DRIVER) loaded via Service Control Manager.
• Device object name: \Device\eb
• Symbolic link: \DosDevices\eb → accessible as \\.\eb
• IRP dispatch table: Implements IRP_MJ_CREATE, IRP_MJ_CLOSE, and IRP_MJ_DEVICE_CONTROL.
• Security descriptor: No evidence of IoCreateDeviceSecure usage or explicit ACL hardening.
• IOCTL dispatch: Switch-based handler using raw IOCTL values (e.g., 0x222024, 0x222030).

The device object appears accessible from user mode without additional privilege validation beyond the ability to open a driver handle.

Figure 12: eb kernel driver architecture — showing the direct path from user-mode IOCTL to kernel-level process termination with no authorization checks.

5.2 IOCTL Discovery and Reverse Engineering

Reverse engineering the DispatchDeviceControl function reveals a switch statement keyed on the IoControlCode extracted from the IRP.

Among multiple IOCTL cases, 0x222024 is particularly relevant:

Figure 13: Disassembly of the eb driver IOCTL 0x222024 handler — reading a PID directly from the user-supplied buffer with no validation.

The handler logic:

1. Reads a 64-bit value from Irp->AssociatedIrp.SystemBuffer
2. Interprets it as a process identifier (PID)
3. Passes it directly to an internal routine (sub_140003360)
4. Returns the status code to user mode

No validation is performed on:

• InputBufferLength
• Caller identity
• Caller integrity level
• Requestor mode
• Target process protection level

Further analysis of sub_140003360 reveals kernel primitives consistent with:

• PsLookupProcessByProcessId
• KeStackAttachProcess
• ZwTerminateProcess
• KeUnstackDetachProcess

Figure 14: Disassembly of the eb driver termination subroutine — kernel primitives used to terminate any process regardless of PPL status.

This creates a direct kernel-mediated process termination primitive.

Unlike the WatchDog driver case, there is no allowlist or registration mechanism. The IOCTL directly performs termination on any supplied PID.

5.2.1 Tooling: Driver Buddy Reloaded

The manual reverse engineering workflow described above can be significantly accelerated using Driver Buddy Reloaded, an open-source IDA Pro Python plugin maintained by Paolo Stagno (VoidSec). The plugin automates several of the most time-consuming tasks involved in kernel driver analysis:

Figure 15: Driver Buddy Reloaded workflow — automating IOCTL discovery, dispatch function identification, and vulnerable API flagging in IDA Pro.

• Automatic DispatchDeviceControl location: The plugin heuristically identifies and renames the IOCTL dispatch function, including fallback logic for cases where the function cannot be resolved from the DRIVER_OBJECT offset directly. This was directly applicable in the WatchDog and eb driver analyses.
• IOCTL code decoding: Individual IOCTL values can be decoded on-the-fly via right-click context menu (Ctrl+Alt+D), or all IOCTLs within a suspected dispatch function can be batch-decoded (Ctrl+Alt+F), producing a timestamped output file. This maps each 32-bit IOCTL code to its DeviceType, Access, Function, and Method fields — directly relevant to understanding the 0x222024 IOCTL analyzed in the eb driver case.
• WDM/WDF structure labeling: The plugin automatically applies type information to IRP, IO_STACK_LOCATION, and DeviceObject structures, reducing manual annotation overhead.
• Vulnerable function flagging: A configurable list of potentially dangerous Windows APIs and C/C++ functions (including ZwTerminateProcess, MmMapIoSpace, ZwMapViewOfSection, and others commonly misused in BYOVD drivers) is checked during auto-analysis and flagged in the output.
• DeviceName extraction: The plugin attempts to recover the driver's registered device paths from Unicode strings in the binary — the first step in constructing a CreateFile handle to the device object.

Installation: Copy the DriverBuddyReloaded folder and DriverBuddyReloaded.py into IDA's plugins directory (e.g., %APPDATA%\Hex-Rays\IDA Pro\plugins\). Requires IDA SDK > 7.5 and Python 3.x.

Usage for BYOVD triage: Load the suspected driver in IDA, trigger auto-analysis via Edit → Plugins → Driver Buddy Reloaded (Ctrl+Alt+A), and review the output for flagged functions and decoded IOCTL codes. The results file serves as a starting point for deeper manual analysis of the IOCTL handlers identified as potentially dangerous.

Note: The plugin only auto-decodes IOCTL values ≥ 0x10000 to reduce false positives. Experimental DispatchDeviceControl search is limited to x64 drivers.

Project: https://github.com/VoidSec/DriverBuddyReloaded

5.3 Exploit Demonstration and Impact

Proof-of-concept exploitation requires:

• Ability to load a signed kernel driver (administrator privileges)
• Ability to open a handle to \\.\eb

Attack sequence:

• Drop the signed driver binary (eb.sys) to a writable path such as %TEMP% or C:\ProgramData.
• Create and start a kernel driver service using sc.exe or NtLoadDriver: sc create eb type= kernel binPath= C:\ProgramData\eb.sys && sc start eb
• Open a handle to the device object: CreateFile("\\\\.\\eb", GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL)
• Enumerate running security processes (e.g., MsMpEng.exe, CSFalconService.exe) via Process32First/Next and resolve their PIDs.
• Terminate each target using the vulnerable IOCTL: DeviceIoControl(hDevice, 0x222024, &targetPid, 8, NULL, 0, &bytesReturned, NULL)

The driver terminates the target process in kernel context.

If the target process is a Protected Process Light (PPL) security component (e.g., EDR service host), termination succeeds because the call originates from kernel mode, bypassing user-mode access restrictions.

No exploit primitives (e.g., memory corruption, race conditions) are required. The vulnerability is purely logical: absence of authorization checks inside the IOCTL handler.

5.4 Root Cause Analysis

The vulnerability stems from three primary design flaws:

1. Missing Caller Validation

The handler does not invoke:

• SeSinglePrivilegeCheck
• IoGetRequestorProcess
• Token integrity validation
• SID or signature checks

Any user-mode process capable of opening the device handle can invoke the termination primitive.

2. Lack of Input Validation

The IOCTL reads directly from SystemBuffer:

v49=*(_QWORD*)SystemBuffer;

There is no verification of:

• Buffer size
• Structure integrity
• Valid PID constraints

This reflects unsafe trust in user-controlled input.

3. Kernel-Context Process Termination

By attaching to the target process and calling termination routines in kernel mode, the driver bypasses:

• PPL enforcement
• User-mode access control checks
• Standard process protection mechanisms

This transforms the driver into a general-purpose process-kill primitive.

5.5 Behavioral Detection Opportunities

This case provides strong kernel-behavior indicators consistent with BYOVD activity.

Driver Load Pattern

• Third-party signed driver loaded dynamically
• Driver loaded from user-writable directory
• Driver service created shortly before EDR process termination

DeviceIoControl Abuse Pattern

Sequence-based indicator:

CreateFile("\\.\eb")
  → DeviceIoControl(0x222024)
  → Security process termination

Monitoring for device access to \\.\eb followed by unexpected security process exit events is a strong behavioral signal.

Kernel-Level Termination of Security Processes

Indicators include:

• Sudden exit of PPL processes
• No corresponding user-mode access rights
• Driver load event preceding termination

This chain strongly aligns with BYOVD methodology.

5.6 Impact

The eb driver represents a canonical Bring Your Own Vulnerable Driver (BYOVD) primitive:

• Signed kernel driver
• User-accessible device object
• No authorization checks
• Direct kernel-level process termination capability

Compared to the WatchDog case, this implementation is structurally simpler and more direct, as it eliminates even minimal registration logic.

From a defensive perspective, this case reinforces the need to monitor:

• Driver load telemetry
• Device object interaction patterns
• Security process termination chains
• Kernel behavioral sequences rather than exploit signatures alone

5.7 Visual Demonstration — Kernel-Level EDR Termination

The impact of BYOVD attacks is best understood when observed directly.

The following demonstration shows a signed, vulnerable driver being used to terminate Microsoft Defender — a Protected Process Light (PPL) service — from kernel context. No exploit primitives, memory corruption, or privilege escalation vulnerabilities are required: the driver itself provides the capability.

This behavior reflects the exact mechanism used by modern ransomware tooling to disable endpoint security prior to encryption.

6. Case Study: Minifilter Drivers as a BYOVD Attack Surface

6.1 Driver Overview

The two case studies in this document focus on WDM drivers communicating via DeviceIoControl, but the Windows Filter Manager (fltmgr.sys) introduces a second driver model that is equally exploitable and less commonly covered in BYOVD literature: the minifilter driver.

Minifilter drivers register with the Filter Manager via FltRegisterFilter and are assigned an altitude — a numeric value that determines their load order in the filter stack. EDR solutions use minifilters extensively to intercept file system and process I/O events at kernel level. Unlike WDM drivers that expose a device object and communicate via DeviceIoControl, minifilter drivers expose a communication port via FltCreateCommunicationPort. User-mode callers connect via FilterConnectCommunicationPort and send commands via FilterSendMessage. The security model of this port depends entirely on the security descriptor passed at creation — if the developer omits strict access controls, any authenticated process on the system can connect and send privileged commands into the kernel.

6.2 Vulnerability and Exploitation: probmon.sys

A signed minifilter driver (probmon.sys, SHA256: 023d722cbbdd04e3db77de7e6e3cfeabcef21ba5b2f04c3f3a33691801dd45eb) was demonstrated to be exploitable for arbitrary process termination via its communication port. The driver imports ZwTerminateProcess and exposes it through a two-stage message sequence: a caller first sends command_type=3 with a pid_to_kill value to the port, causing the driver to call ZwOpenProcess on the target; a second condition is satisfied when a PsSetCreateProcessNotifyRoutine callback detects a process exit matching the registered PID. When both conditions are met, ZwTerminateProcess executes in kernel context, bypassing PPL entirely. The exploit requires no kernel-level primitives — only a handle to the communication port and the ability to engineer the exit callback trigger.

6.3 Altitude Hijacking: Blinding EDR Without a Vulnerable Driver

A related technique targets the minifilter altitude mechanism directly, without requiring any vulnerable driver. Every minifilter is assigned a numeric altitude in HKLM\SYSTEM\CurrentControlSet\Services\<driver>\Instances. An attacker with local administrator rights can rename a legitimate minifilter's altitude registry key and substitute the EDR's altitude value. On reboot, the substitute driver loads at the EDR's position in the filter stack, displacing its minifilter from the callback chain. The EDR service continues running and the management console reports the endpoint as healthy — with no alerts generated — while the EDR's file system and process callbacks have silently stopped firing.

6.4 Behavioral Detection Opportunities

Minifilter-based attacks generate telemetry distinct from WDM BYOVD and require separate detection logic. Key signals include: Sysmon Event ID 6 for minifilter driver loads (cross-reference against known altitude assignments); Sysmon Event ID 13/14 for altitude registry modifications under HKLM\SYSTEM\CurrentControlSet\Services\*\Instances\*\Altitude; FilterLoad and FilterUnload events in EDR telemetry; and anomalous FilterConnectCommunicationPort callers connecting to known security product port names. Running fltmc filters as a scheduled baseline and alerting on unexpected additions or removals provides an additional detection layer that is independent of EDR telemetry.

7. Behavioral Detection Methodology

7.1 Detection Philosophy: Behavioral Correlation Over Signature Matching

Signature-based detection of BYOVD attacks is fundamentally reactive: it requires the driver hash or binary to be previously known and blocklisted. Since adversaries can modify driver binaries minimally to change hashes or simply use drivers not yet cataloged, behavioral detection must be the primary analytical layer.

The behavioral detection model is built around three observable facts that BYOVD attacks cannot easily disguise:

• Anomalous driver drop location: Legitimate software drivers are installed to system directories (C:\Windows\System32\drivers, C:\Program Files\...) via signed installers. Drivers dropped to temporary directories, ProgramData, or user-writable paths are statistically anomalous.
• Suspicious initiating process context: Legitimate driver loads are triggered by service installers or system processes. Driver loads initiated by cmd.exe, powershell.exe or unsigned binaries represent a behavioral deviation.
• Temporal correlation between drop and load: Legitimate drivers are installed via setup processes that may span multiple reboots and occur days before a load event. BYOVD attacks are operationally motivated to minimize time-to-execution, resulting in near-simultaneous drop and load events (typically within seconds to minutes).

7.2 Telemetry Sources

Microsoft Defender for Endpoint (MDE) provides the primary telemetry sources for this detection. The following tables are used:

• DeviceFileEvents: Records file creation, modification, and deletion events at the endpoint. Provides FileName, FolderPath, SHA1, InitiatingProcessFileName, InitiatingProcessCommandLine, and timestamp.
• DeviceEvents: Records low-level device and driver events, including DriverLoad events with ActionType == "DriverLoad". Provides SHA1, InitiatingProcessFileName, InitiatingProcessSignatureStatus.
• DeviceProcessEvents: Records process creation events. Useful for correlating parent-child process chains that precede a driver drop.
• DeviceImageLoadEvents: Records DLL and PE load events into process memory. Supplementary for detecting user-mode loaders.

Supplementary enrichment can be obtained from:

• VirusTotal API (or similar threat intel): Correlate driver SHA1 against reputation databases.
• LOLDrivers database: Check against the community-maintained catalog of known-vulnerable signed drivers.
• Internal threat intelligence: Cross-reference against IOC feeds from previous incidents.

7.3 Detection Logic Design

The core detection pipeline consists of four logical stages:

• Stage 1 — Drop Detection: Identify .sys files written outside standard driver installation paths, with particular attention to temp directories, user-profile paths, and admin-writable but non-system locations.
• Stage 2 — Load Detection: Identify kernel driver load events (ActionType == "DriverLoad") where the initiating process is a known-suspicious loader (cmd.exe, powershell.exe) or is not digitally signed.
• Stage 3 — Temporal Correlation: Join drop and load events on device identity and driver SHA1, filtering for load events occurring within a configurable window (default: 30 seconds) after the drop.
• Stage 4 — Rarity Enrichment: Calculate the TenantDeviceCount for each driver SHA1 across the entire MDE tenant. Low counts (e.g., < 3 devices) indicate novel or targeted drivers that warrant elevated priority.

7.4 KQL Implementation

let SuspiciousLoaders = dynamic(["cmd.exe","powershell.exe"]);
let DriverDrops = DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName endswith ".sys"
| where FolderPath !startswith @"C:\Windows" and FolderPath !startswith @"C:\Program Files"
| project DropTime=Timestamp, DeviceName, SHA1, FolderPath,
          DroppingProcess=tolower(InitiatingProcessFileName),
          DroppingProcessCmdLine=InitiatingProcessCommandLine;

let DriverLoads = DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "DriverLoad"
| where SignatureStatus == "Signed"
| where tolower(InitiatingProcessFileName) in (SuspiciousLoaders) or InitiatingProcessSignatureStatus != "Signed"
| project LoadTime=Timestamp, DeviceName, SHA1,
          LoadingProcess=tolower(InitiatingProcessFileName),
          LoadingProcessSigned=InitiatingProcessSignatureStatus,
          LoadingProcessCmdLine=InitiatingProcessCommandLine;

DriverDrops
| join kind=inner DriverLoads on DeviceName, SHA1
| where LoadTime between (DropTime .. DropTime + 30s)
| join kind=leftouter (
    DeviceEvents
    | where ActionType == "DriverLoad"
    | summarize TenantDeviceCount=dcount(DeviceName) by SHA1
) on SHA1
| project DropTime, LoadTime, DeviceName, FolderPath,
          DroppingProcess, DroppingProcessCmdLine,
          LoadingProcess, LoadingProcessSigned, LoadingProcessCmdLine,
          TenantDeviceCount, SHA1
| order by TenantDeviceCount asc, DropTime desc

8. Alert Interpretation and Analyst Guidance

8.1 Evaluating Alert Priority Fields

The core detection query produces several fields that analysts should evaluate in sequence to determine investigation priority and confidence:

• AlertPriority (CRITICAL/HIGH): Drivers observed on only 1-3 devices in the tenant warrant immediate investigation.
• DroppingProcess and LoadingProcess: The combination of a scripting host or command interpreter (cmd.exe, powershell.exe) both dropping and loading a driver is the highest-confidence indicator pattern.
• DroppingProcessSignature: An unsigned process dropping a .sys file is highly anomalous and should be treated as confirmed malicious pending investigation.
• FolderPath: Paths such as C:\Windows\Temp, C:\Users\*\AppData\Local\Temp, and C:\ProgramData\* are common BYOVD staging locations.
• Temporal gap (LoadTime - DropTime): Near-zero gaps (< 5 seconds) indicate automated execution, consistent with a BYOVD toolkit.

8.2 False Positive Profiling

The following scenarios can produce false positives and should be baselined for candidates in the tuning process:

• Software deployment automation: Endpoint management tools (SCCM, Intune, PDQ Deploy) may invoke cmd.exe or powershell.exe as part of driver installation scripts.
• Kernel debugging and development environments: Developer workstations with WDK installed may legitimately load test-signed drivers from non-standard paths.
• Security tools with kernel components: Some EDR and DLP products load kernel drivers via service wrappers.
• Low TenantDeviceCount for niche software: Specialized software with kernel components may have low TenantDeviceCount purely due to deployment scope.

8.3 Investigation Playbook

Upon receiving a BYOVD detection alert, analysts should follow this investigation sequence:

• Step 1 — Isolate and preserve: If AlertPriority is CRITICAL, consider device isolation.
• Step 2 — Validate driver identity: Submit the SHA1 to VirusTotal, MalwareBazaar, and the LOLDrivers database.
• Step 3 — Trace initiating process ancestry: Use DeviceProcessEvents to reconstruct the process tree leading to the driver drop.
• Step 4 — Assess lateral movement scope: Search for the same SHA1 or command-line patterns across all devices.
• Step 5 — Check for security product process termination: Review DeviceProcessEvents for unexpected termination of security processes.
• Step 6 — Document and contain: Update the incident record and submit the driver hash for blocklist consideration.

9. Defensive Hardening Recommendations

9.1 Windows Defender Application Control (WDAC) Driver Policy

WDAC is the most effective preventive control against BYOVD. A properly configured WDAC driver policy operating in enforcement mode will block driver load attempts for unsigned, non-allowlisted, or blocklisted drivers at the kernel level.

Key configuration recommendations:

• Enable the Microsoft Vulnerable Driver Blocklist via WDAC or DriverSiPolicy.p7b.
• For high-security environments, implement a driver allowlist policy.
• Test WDAC policies in audit mode before enforcement.

Example Policy XML — Minimal Driver Allowlist

For high-security environments, a policy combining an allowlist and the Microsoft blocklist:

<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
  <VersionEx>10.0.0.0</VersionEx>
  <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
  <PlatformID>{2E07F7E4-194C-4D20-B96C-1498F2ACBE22}</PlatformID>

  <Rules>

    <Rule>
      <Option>Enabled:Audit Mode</Option>
    </Rule>

    <Rule>
      <Option>Enabled:UMCI</Option>
    </Rule>

    <Rule>
      <Option>Enabled:Boot Menu Protection</Option>
    </Rule>

    <Rule>
      <Option>Required:WHQL</Option>
    </Rule>

    <Rule>
      <Option>Enabled:Invalidate EAs on Reboot</Option>
    </Rule>

    <Rule>
      <Option>Enabled:Revoked Expired As Unsigned</Option>
    </Rule>
  </Rules>


  <Signers>

    <Signer ID="ID_SIGNER_WHQL" Name="Microsoft Windows Hardware Compatibility Publisher">
      <CertRoot Type="Wellknown" Value="03" />
    </Signer>


    <Signer ID="ID_SIGNER_MS" Name="Microsoft Windows">
      <CertRoot Type="Wellknown" Value="02" />
    </Signer>
  </Signers>

  <SigningScenarios>
    <SigningScenario Value="131"
                     ID="ID_SIGNINGSCENARIO_DRIVERS"
                     FriendlyName="Kernel Mode Drivers">

      <ProductSigners>
        <AllowedSigners>
          <AllowedSigner SignerId="ID_SIGNER_WHQL" />
          <AllowedSigner SignerId="ID_SIGNER_MS" />
        </AllowedSigners>

        <DeniedSigners />
      </ProductSigners>

    </SigningScenario>
  </SigningScenarios>

  <FileRules>
    <Deny ID="ID_DENY_ZAMGUARD"
          FriendlyName="Zemana zamguard64.sys"
          Hash="[SHA256]" />

    <Deny ID="ID_DENY_EB"
          FriendlyName="eb.sys"
          Hash="[SHA256]" />
  </FileRules>

  <UpdatePolicySigners />
  <CiSigners />

  <HvciOptions>1</HvciOptions>
</SiPolicy>

9.2 HVCI / Memory Integrity

Enable Hypervisor-Protected Code Integrity (HVCI) on all endpoints. While HVCI does not prevent vulnerable signed drivers from loading, it eliminates alternative kernel exploitation paths and raises the bar for attackers.

9.3 EDR Sensor Hardening

Ensure EDR agents are deployed with tamper protection enabled. Consider deploying EDR agents as PPL-AntiMalware signed processes where supported by the vendor.

9.4 Privileged Access and Least Privilege

Loading a kernel driver requires SeLoadDriverPrivilege, which is granted to local administrators by default. Minimizing the number of accounts with local administrator rights reduces the attack surface for BYOVD deployment.

9.5 Proactive Driver Inventory

Maintain an accurate inventory of all kernel drivers loaded across the fleet using MDE Advanced Hunting queries. Establish a baseline and alert on deviations. Cross-reference periodically against LOLDrivers to identify vulnerable drivers already present.

10. MITRE ATT&CK Mapping

The BYOVD technique and its detection coverage map to the following MITRE ATT&CK Enterprise entries:

• T1068 — Exploitation for Privilege Escalation
• T1218 — System Binary Proxy Execution
• T1562.001 — Impair Defenses: Disable or Modify Tools
• T1014 — Rootkit
• T1055 — Process Injection
• T1569.002 — System Services: Service Execution
• T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control
• T1112 — Modify Registry
• T1070.004 — Indicator Removal on Host: File Deletion

11. Future Research Directions

11.1 In-Memory Driver Loading Detection

An emerging evasion technique involves loading kernel drivers through undocumented interfaces that bypass the Service Control Manager and avoid generating standard DeviceFileEvents drop telemetry. Detecting these requires monitoring for direct NtLoadDriver syscalls and correlating with ETW provider events.

11.2 Sigma Rule Translation

Translating the detection logic into Sigma rules would enable cross-platform deployment to SIEM systems, including Splunk, Elastic, Chronicle, and QRadar.

11.3 Automated IOCTL Fuzzing for Driver Vulnerability Discovery

Before fuzzing, systematic IOCTL enumeration using static analysis tools such as Driver Buddy Reloaded can narrow the fuzzing target surface by identifying the dispatch function and enumerating valid IOCTL codes, reducing the search space before dynamic testing begins.

11.4 Cross-Platform BYOVD on Linux and macOS

Analogous kernel driver abuse patterns exist on Linux (loadable kernel modules) and macOS (kexts, System Extensions). Developing equivalent behavioral detection methodologies for these platforms represents a significant research opportunity.

12. Conclusion

BYOVD attacks represent a technically sophisticated and operationally effective technique for defeating modern endpoint security controls. The fundamental vulnerability — that Windows kernel driver signing does not validate runtime behavior or IOCTL access controls — cannot be fully addressed without architectural changes to the Windows kernel trust model.

In the absence of a universal technical fix, defense must rely on a combination of preventive controls (WDAC driver policies, HVCI), behavioral detection (anomalous driver drop/load correlation, rarity analysis), and operational response (investigation playbooks, tenant-wide scope assessment). The WatchDog driver case study illustrates that even patched and re-released driver versions can retain exploitable design weaknesses.

13. References and Further Reading

• Microsoft Security Blog: "Stopping vulnerable drivers" — https://www.microsoft.com/security/blog/
• LOLDrivers Project — https://www.loldrivers.io/
• MITRE ATT&CK Enterprise Matrix — https://attack.mitre.org/
• Microsoft Defender for Endpoint Advanced Hunting schema reference — https://docs.microsoft.com/en-us/microsoft-365/security/
• Windows Internals, 7th Edition — Russinovich, Solomon, Ionescu
• UEFI/Secure Boot and HVCI deployment guide — https://docs.microsoft.com/en-us/windows/security/
• Kernel Driver IOCTL security best practices — Microsoft Driver Development documentation
• kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels — USENIX Security 2017
• Driver Buddy Reloaded (VoidSec / Paolo Stagno) — IDA Pro plugin for Windows kernel driver reverse engineering — https://github.com/VoidSec/DriverBuddyReloaded