Escalating to SYSTEM via Windows NPU Driver Exploitation

TLDR: Researchers at Black Hat 2025 demonstrated that modern AI-accelerated hardware, specifically Windows NPU drivers, share a vulnerable device driver interface (DDI) with GPUs. By leveraging heap fengshui and manipulating Windows Notification Facility (WNF) state data, they achieved arbitrary read/write primitives to escalate privileges to SYSTEM. This research highlights that while the hardware is new, the underlying driver vulnerabilities are the same decade-old memory corruption issues we have seen in GPU drivers since the Windows Vista era.

Modern hardware acceleration is the new frontier for local privilege escalation. As manufacturers rush to integrate Neural Processing Units (NPUs) into consumer laptops to support local AI features, they are effectively porting the same complex, high-privilege driver architectures that have plagued GPU security for years. The recent research presented at Black Hat 2025 proves that these NPU drivers are not just similar to GPU drivers; they are often built on the exact same, brittle foundations.

The DDI Shared Vulnerability

The core of this research lies in the Device Driver Interface (DDI), which acts as the bridge between user-mode applications and kernel-mode hardware drivers. Because NPUs and GPUs perform similar computational tasks, they share the same Windows Display Driver Model (WDDM) and the newer Microsoft Compute Driver Model (MCDM).

The researchers identified that these drivers often fail to properly validate user-supplied data passed through DDI functions. Specifically, properties like pPrivateDriverData and pPrivateDriverDataSize are frequently passed directly from user-mode to the kernel without sufficient sanitization. This is a classic recipe for memory corruption. If you have ever performed kernel exploitation on older Windows graphics drivers, this will feel familiar. The attack surface is essentially a massive, complex interface that was never designed with a strict security boundary in mind.

Exploiting the Heap

To turn these unchecked inputs into a reliable exploit, the researchers employed heap fengshui. By carefully grooming the kernel heap, they could place their own controlled objects adjacent to the target structures. The goal was to manipulate WNF state data, which acts as a versatile primitive for both reading and writing kernel memory.

The exploit flow follows a predictable, yet highly effective path:

1. Heap Grooming: Allocate and free specific objects to create a predictable heap layout.
2. Primitive Acquisition: Trigger an integer overflow or heap overflow to overwrite the WNF state data structure.
3. Arbitrary Read/Write: Use the corrupted WNF structure to gain an arbitrary read primitive, allowing the attacker to locate the EPROCESS token of the current process.
4. Privilege Escalation: Use an arbitrary write primitive to modify the EPROCESS token, specifically flipping the bits that define the process's security context to match the SYSTEM account.

This technique was used to successfully exploit CVE-2024-53033 and CVE-2024-36336. The researchers demonstrated that even with modern mitigations, if you can control the kernel heap, you can control the system.

Real-World Impact for Pentesters

For those of us conducting red team engagements or local privilege escalation research, this is a goldmine. Any machine running a modern NPU-enabled processor is a potential target. During a standard engagement, you should be enumerating the installed drivers for any NPU-related components. If you find an unpatched driver, the likelihood of finding a memory corruption vulnerability is high.

The impact is absolute. Once you have achieved SYSTEM-level execution, you have bypassed all local user-mode restrictions. You can dump credentials, install persistence, or move laterally through the network. The fact that this can be done from a low-privileged user account makes it a critical finding for any internal security assessment.

Defensive Considerations

Defending against this is difficult because the vulnerability exists in the driver's logic, not in the application code. Blue teams should focus on strict driver update policies. If a vendor releases a patch for an NPU driver, it should be treated with the same urgency as a critical OS patch. Furthermore, implementing Kernel Mode Code Integrity (KMCI) and ensuring that only signed, verified drivers are loaded can prevent the most egregious forms of exploitation. However, as this research shows, signed drivers can still be inherently insecure.

The shift toward local AI processing is inevitable, but the security industry must stop treating these new hardware drivers as "black boxes" that are somehow immune to the vulnerabilities of the past. We are seeing a repeat of the graphics driver security crisis from the mid-2010s, just with a different marketing label. If you are auditing these systems, look for the same old bugs in the same old places. The hardware has changed, but the memory corruption remains.