Windows Kernel Driver Exploitation & BYOVD Masterclass 2026: From IOCTL Primitives to Token Stealing and EDR Unhooking

Windows Kernel Driver Exploitation & BYOVD Masterclass 2026: From IOCTL Communication and Arbitrary Read/Write Primitives to Token Stealing, DKOM, and EDR Callback Neutralization

Byline: Syed Zada Abrar | Lead Researcher, Andrax Pentester · Founder, SentinelReign

Category: Reverse Engineering & Kernel Security

Difficulty: EXPERT | Estimated Time: 45 Mins

Target Audience: Penetration Testers, Red Team Operators, Vulnerability Researchers, Detection Engineers

---

1. BLUF & Executive Summary (Bottom Line Up Front)

Technical Vector	Vector Details & Operational Metrics
Vulnerability Class	Unvalidated I/O Control Code (IOCTL) Dispatch / Arbitrary Kernel Read/Write Primitive
Target Architecture	x86_64 Windows 11 (23H2/24H2) & Windows Server 2022/2025 Kernel (ntoskrnl.exe)
Attack Primitive	Bring Your Own Vulnerable Driver (BYOVD) + Direct Kernel Object Manipulation (DKOM)
Impact	Ring 0 Execution, Local Privilege Escalation (Medium Integrity -> SYSTEM), EDR Callback Neutralization
Primary Countermeasure	WDAC Driver Blocklisting, HVCI Enforcement, Strict IOCTL Buffer Validation (METHOD_BUFFERED)

Windows kernel-mode driver exploitation remains one of the most powerful tradecraft avenues for achieving local privilege escalation (LPE) and bypassing Endpoint Detection and Response (EDR) telemetry. In modern Windows enterprise environments (Windows 11 23H2/24H2 and Windows Server 2025), traditional ring 0 code execution primitives—such as overwriting function pointers or executing shellcode on the kernel stack—are blocked by hardware-enforced mitigations like Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), and Hypervisor-Protected Code Integrity (HVCI).

As a result, modern kernel exploitation relies heavily on Bring Your Own Vulnerable Driver (BYOVD) attacks combined with Data-Only Exploitation (Direct Kernel Object Manipulation / DKOM). By abusing legitimate, signed kernel drivers that contain unvalidated IOCTL handling logic, an attacker operating with administrative privileges can obtain arbitrary kernel memory read and write primitives.

This masterclass provides a complete, first-principles walkthrough of Windows kernel driver communication, IOCTL dispatching, vulnerability identification, C/C++ exploit harness construction, system token elevation, and EDR callback array unhooking.

---

2. Step 0: First-Principles Intuition & Hardware CPU Privilege Architecture

To exploit or secure the Windows kernel, you must understand how the operating system and the CPU manage boundary lines between untrusted user code and privileged kernel instructions.

+-----------------------------------------------------------------------+
|                         USER MODE (Ring 3)                            |
|  +------------------------+        +-------------------------------+  |
|  | custom_exploit_poc.exe |        |  win32k / ntdll.dll / APIs    |  |
|  +-----------+------------+        +---------------+---------------+  |
+--------------|-------------------------------------|------------------+
               |  DeviceIoControl()                  |  SYSCALL instruction
===============|=====================================|==================
               v  I/O Request Packet (IRP)           v  IA32_LSTAR MSR
+-----------------------------------------------------------------------+
|                        KERNEL MODE (Ring 0)                           |
|  +------------------------+        +-------------------------------+  |
|  | VulnerableDriver.sys   | <----> | ntoskrnl.exe (Kernel Core)    |  |
|  |  (IOCTL Dispatcher)    |        |  (EPROCESS, Token, Callbacks) |  |
|  +------------------------+        +-------------------------------+  |
+-----------------------------------------------------------------------+

CPU Privileges: Ring 3 vs Ring 0

Modern x86_64 processors implement hierarchical privilege levels known as Rings:

• Ring 3 (User Mode): Application code runs here with restricted hardware access. Code in Ring 3 cannot execute privileged instructions (e.g., cli, sti, modifying control registers CR0, CR3, CR4) or directly access memory addresses above 0x7FFF'FFFFFFFF (on 64-bit Windows).
• Ring 0 (Kernel Mode): Operating system components and device drivers execute here. Ring 0 code has unrestricted access to CPU instructions, hardware I/O ports, and the entire virtual address space (0xFFFF8000'00000000 to 0xFFFFFFFF'FFFFFFFF).

---

3. Kernel Driver Architecture & IOCTL Dispatching

Windows kernel drivers register symbolic links and device objects so user-mode applications can communicate with them using standard Win32 File APIs (CreateFileA, DeviceIoControl, CloseHandle).

Driver Initialization (DriverEntry)

When a driver is loaded into memory, the Windows I/O Manager invokes its entry point function:

NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT  DriverObject,
    _In_ PUNICODE_STRING RegistryPath
) {
    UNREFERENCED_PARAMETER(RegistryPath);

    UNICODE_STRING deviceName;
    UNICODE_STRING symLinkName;
    PDEVICE_OBJECT deviceObject = NULL;

    RtlInitUnicodeString(&deviceName, L"\\Device\\VulnerableDevice");
    RtlInitUnicodeString(&symLinkName, L"\\DosDevices\\VulnerableDeviceLink");

    // 1. Create Device Object
    NTSTATUS status = IoCreateDevice(
        DriverObject,
        0,
        &deviceName,
        FILE_DEVICE_UNKNOWN,
        FILE_DEVICE_SECURE_OPEN,
        FALSE,
        &deviceObject
    );

    if (!NT_SUCCESS(status)) return status;

    // 2. Create Symbolic Link for User-Mode Access
    status = IoCreateSymbolicLink(&symLinkName, &deviceName);

    // 3. Register Major Function Dispatch Routines
    DriverObject->MajorFunction[IRP_MJ_CREATE]         = VulnerableCreateClose;
    DriverObject->MajorFunction[IRP_MJ_CLOSE]          = VulnerableCreateClose;
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = VulnerableIoControl;

    return STATUS_SUCCESS;
}

---

4. Summary Takeaways & Mastery Checklist

• [x] Ring 0 vs Ring 3: Privilege separation is enforced by CPU flags and virtual address space bounds (0x7FFF... vs 0xFFFF...).
• [x] IOCTL Transfer Modes: METHOD_NEITHER passes raw user pointers; without explicit validation, it exposes arbitrary kernel read/write primitives.
• [x] BYOVD Tradecraft: Attackers bring legitimate, signed drivers to bypass HVCI code-signing requirements.
• [x] DKOM Token Stealing: Overwriting the _EPROCESS.Token pointer elevates privileges without modifying executable code pages, bypassing SMEP and HVCI.
• [x] EDR Neutralization: Kernel write primitives can zero out callback routines in PspCreateProcessNotifyRoutine.
• [x] Defensive Countermeasure: Enforce WDAC driver blocklists, turn on Memory Integrity (HVCI), and require METHOD_BUFFERED IOCTL handling.

---

Originally published as an interactive Masterclass on Andrax Pentester under the byline of Syed Zada Abrar.