# Stopping Vulnerable Driver Attacks

Microsoft Process Explorer driver allows unrestricted handle duplication, letting user-mode attackers duplicate a System-process physical memory handle to gain arbitrary kernel read/write.

- Payout: Research
- Severity: high
- Program: Microsoft Process Explorer
- Write-up by: Joe Desimone
- Disclosed: 2023-03-01
- Write-up quality: 7/10
- Original: https://www.elastic.co/security-labs/blog/stopping-vulnerable-driver-attacks
- Library page: https://bugbountylibrary.com/r/blog%3Aelastic-co-security-labs-blog-stopping-vulnerable-driver-attacks
- Tags: area:os domain:desktop impact:privesc impact:rce kind:research platform:threat-intel sev:high tech:windows technique:source-review vuln:memory-corruption vuln:privilege-escalation

**Target:** Windows kernel driver (Process Explorer driver IOCTL)
**Root cause:** The driver exposes an IOCTL that performs unrestricted handle duplication, allowing a user-mode caller to duplicate a sensitive handle (raw physical memory) held by the System (PID 4) process into its own process.
**Steps:**
1. Open handle to the Process Explorer driver device and issue the handle-duplication IOCTL targeting the System (PID 4) process's physical memory handle.
2. Duplicate the raw physical memory handle from PID 4 into the attacker process.
3. Read the cr3 value from the duplicated physical memory handle.
4. Walk the page tables to translate virtual kernel addresses to physical addresses, yielding an arbitrary virtual read/write primitive.
5. Tamper with kernel data structures or, on HVCI systems, hijack thread control flow to execute arbitrary kernel functions.
**How found:** Reviewing driver IOCTL surfaces for dangerous primitives; noted handle duplication as an under-appreciated flaw class and identified the latest Microsoft Process Explorer driver exposing such a function.
**Exploitation:** Attacker with user-mode code on the host abuses the driver's handle-duplication IOCTL to obtain a physical memory handle from PID 4, derives cr3, walks page tables for arbitrary kernel R/W, then tampers kernel structures or hijacks thread control flow to run kernel code — enabling termination/tampering of endpoint security products.
**Escalation:** Physical memory handle from System process → cr3 → page-table walk → arbitrary kernel virtual read/write → kernel code execution even under HVCI via thread control flow hijack.
**Insight:** Audit driver IOCTLs that duplicate handles: a duplicated handle to a privileged process's physical memory (PID 4) is a direct path to cr3 and arbitrary kernel R/W, even with HVCI enabled.