Introduction
Bring Your Own Vulnerable Driver (BYOVD) is an increasingly popular attacker technique wherein a threat actor brings a known-vulnerable signed driver alongside their malware, loads it into the kernel, then exploits it to perform some action within the kernel that they would not otherwise be able to do. After achieving kernel access, they may tamper with or disable security software, dump otherwise inaccessible credentials, or modify operating system behavior to hide their presence. Joe Desimone and I covered this in-depth, among other kernel mode threats, at Black Hat USA 2018. Employed by advanced threat actors for over a decade, BYOVD is becoming increasingly common in ransomware and commodity malware.
Driver Signing Enforcement (DSE), first deployed in 2007 by Windows Vista x64, was the first time that Microsoft attempted to limit the power of admins. With DSE in place, admins could no longer instantly load any code into the kernel. Admin restrictions grew over time with the rollout of Boot Guard, Secure Boot, and Trusted Boot to protect the boot chain from admin malware, which could previously install their own boot loaders / bootkits.
Further limiting admins' power, Microsoft recently deployed the Vulnerable Driver Blocklist by default, starting in Windows 11 22H2. This is a move in the right direction, making Windows 11 more secure by default. Unfortunately, the blocklist's deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of “secure by default” territory.
Security boundaries
When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary, which it defines as follows:
A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic and straightforward security boundary.
Based on this definition, one might be inclined to think that malware running in user mode should not be able to modify kernel memory. The boundary is “straightforward” after all. Logically, any violation of that boundary should be met with a remedial action such as a patch or blocklist update.
Unfortunately, the situation gets murkier from here. That document later states that administrator-to-kernel is not a security boundary, with the following explanation:
Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong [sic] isolated from the kernel boundary.
At this point, we have two seemingly conflicting viewpoints. On one hand, MSRC states that admin-to-kernel is an indefensible boundary and not worth fixing. On the other hand, Microsoft is attempting to defend this boundary with mechanisms such as Driver Signing Enforcement, Secure Boot, and the Vulnerable Driver Blocklist. Because the defense is incomplete, MSRC instead calls them “defense-in-depth security features.”
MSRC similarly does not consider admin-to-PPL a security boundary, instead classifying it as a defense-in-depth security feature. More on this in the next section.
The rest of this article will refer to MSRC and Microsoft separately. While MSRC is part of Microsoft, Microsoft is a much larger entity than MSRC; they shouldn't be equated.
Exploiting vulnerabilities
In September 2022, I filed VULN-074311 with MSRC, notifying them of two zero-day vulnerabilities in Windows: one admin-to-PPL and one PPL-to-kernel. I provided source code for both exploits. The response concisely indicated that they understood the vulnerabilities and declined to take any further action, as stated below:
The research describes a multi-step attack that leverages a PPL bypass to gain kernel code execution. Note that all of the proposed attacks do require administrative privileges to perform and thus the reported issue does not meet our bar for immediate servicing. We do not expect any further action and will proceed with closing out the case.
In this parlance, “servicing” means “patching.” Their response is consistent with the aforementioned policy and their historical treatment of the admin-to-kernel boundary. Their behavior is consistent too - it's been over 11 months and they still haven't patched either vulnerability. I find it fascinating that Microsoft is willing to block drivers that can modify kernel memory but MSRC is unwilling to service vulnerabilities that can do the same.
When I announced my Black Hat Asia 2023 talk, PPLdump Is Dead. Long Live PPLdump, on Twitter five months after the MSRC report, the Windows Defender team quickly reached out to learn more. It seems that MSRC closed the case without telling the Defender team, whose products rely on PPL to protect hundreds of millions of Windows machines, about a PPL bypass. This type of miscommunication mustn't be allowed to continue.
Turnkey tooling
EDRSandBlast is a tool that weaponizes vulnerable drivers to bypass AV & EDR software. It can modify kernel memory to remove hooks installed by AV & EDR, temporarily or permanently blinding them to malicious activity on the system.
As I discussed in my Black Hat Asia talk, MSRC has de-facto shown that they are unwilling to service admin-to-PPL and admin-to-kernel vulnerabilities and that it requires the existence of turnkey tooling on GitHub to motivate Microsoft to action. This led me to release the admin-to-PPL exploit PPLFault and admin-to-kernel exploit chain GodFault as easy-to-use tools on GitHub. For brevity, below we'll call them “PPL vulnerability” and “kernel vulnerability”, respectively.
In this same “turnkey tooling” spirit, to highlight the inconsistency of blocking known-vulnerable drivers while simultaneously refusing to patch admin-to-kernel exploit chains, I am releasing a version of EDRSandBlast that integrates PPLFault to demonstrate the same result, sans vulnerable drivers. You can see it here disabling the Windows Defender driver. My goal in releasing this is to motivate MSRC to treat both PPL and kernel vulnerabilities with greater urgency.
Mitigation
I released a small kernel driver alongside PPLFault and GodFault called NoFault which breaks the PPL exploit. Until Windows is fixed, anti-malware vendors can employ this code to mitigate the PPL vulnerability. We've incorporated NoFault's protection into the latest version of Elastic Endpoint/Defend - please update to 8.9.0+ if you haven't already. One comprehensive fix could be to have the memory manager enforce page hashes for all executable images loaded into PPL, a feature already employed for full Protected Processes.
GodFault is not the first tool to exploit the kernel vulnerability. ANGRYORCHARD first used it with the now-patched KnownDLLs PPL vulnerability. The PPL vulnerability has since been fixed, but the kernel one was not. I was able to easily reuse the kernel vulnerability in GodFault - it's only a few lines of code. If this is not patched, then any future PPL exploits will immediately be chainable to the kernel. Note that NoFault breaks the kernel exploit chain by preventing its requisite PPL code execution, but does not fix the kernel vulnerability itself.
Discussion
Making EDRSandBlast driverless is just one example of the things you can do with such exploits. Admin-to-kernel exploits enable a whole menu of malware capabilities that are normally impossible from user mode, including:
- Disable kernel mode telemetry including process, thread, object manager, filesystem, and registry callbacks. EDRSandBlast does some of these.
- Disable kernel ETW loggers
- Terminate and/or inject malware into PPL anti-malware processes
- Bypass LSA RunAsPPL to dump credentials or tamper with Credential Guard
- Read/write the memory of shielded VM worker processes, which run as PPL
- Run malware with greater privilege than anti-malware, such that it can't be scanned or terminated from user mode
- Implement rootkit behavior such as hiding processes, files, and registry keys
- Gain full read-write access to physical memory
Such kernel-driven capabilities, often enabled by BYOVD, are regularly used by criminals to defeat and degrade security products, empowering them to hurt people and businesses. PPL and kernel vulnerabilities enable these same capabilities, so MSRC needs to service them proactively before threat actors abuse them, not after.
I don't want to understate the difficulty of the problem - defending the kernel against admins is hard and will require continual effort as new bypasses are found. It will not be solved, but rather a difficult and ongoing arms race. Fortunately, Microsoft recently adopted a new philosophy of “no longer avoiding the hard things” (timestamped link). Addressing these types of vulnerabilities is a “hard thing” affecting Windows security today that Microsoft can do something about while simultaneously moving towards their vision of an Adminless future. They're a large well-funded company filled with smart people, capable of addressing multiple issues at once.
Conclusion
Microsoft created the Vulnerable Driver Blocklist to stop admins from tampering with the kernel, but they've done nothing about an admin-to-kernel exploit chain that was reported over 11 months ago. By removing the vulnerable driver requirement from EDRSandBlast via GodFault, I hope to prove that admin-to-kernel exploits can be just as dangerous as vulnerable drivers and that MSRC needs to take them seriously. Given Windows 11's goal of default security and the fact that the Vulnerable Driver Blocklist is now enabled by default, MSRC needs to reconsider its policy of indifference towards PPL and kernel exploits.