The Microsoft Vulnerable Driver Blocklist: Is Yours Actually On?

Kernel drivers are the last place most defenders look and the first place a serious attacker wants to be. A driver runs in ring 0 with the same privileges as the operating system itself, so anything running there can read protected process memory, terminate your EDR, and rewrite the rules that everything else on the box relies on. The uncomfortable truth is that an attacker does not need a zero-day to get there. They can just carry in a legitimately signed driver that happens to have an exploitable vulnerability — a technique known as Bring Your Own Vulnerable Driver (BYOVD), mapped to MITRE ATT&CK technique T1211 and the signed-driver abuse in T1068.

Why a valid signature is not enough

Windows requires kernel-mode drivers to be signed, and that requirement stops random malware from loading its own driver. But signing only proves who wrote the code, not whether the code is safe. Dozens of drivers from reputable vendors — CPU tuning utilities, anti-cheat modules, old disk and BIOS-flashing tools — expose primitives that let an unprivileged caller read and write arbitrary physical memory. Once such a driver is loaded, an attacker uses it as a signed gateway into the kernel:

• Kill protected processes, including tamper-protected antivirus and EDR services.
• Patch kernel callbacks so process-creation and image-load notifications stop firing.
• Read LSASS memory or credentials that would otherwise be walled off by Credential Guard-adjacent protections.
• Establish persistence that survives a reboot because the loader itself is trusted.

This is exactly how ransomware crews and nation-state operators have repeatedly disabled endpoint defenses before encryption — the EDR was working perfectly, then a signed .sys file switched it off from below.

The blocklist Windows already ships

Microsoft maintains a Vulnerable Driver Blocklist: a curated policy that names the known-bad drivers by hash and refuses to load them, even though their signatures are valid. It is enforced through Windows Defender Application Control (WDAC) and, on capable hardware, backed by Memory Integrity (HVCI). On clean installs of Windows 11 it is on by default. The problem is everything that is not a clean Windows 11 install.

A blocklist that is turned off, or three years out of date, provides exactly zero protection against the driver that was added to it last month.

Two failure modes dominate in the field. First, the feature is simply disabled — upgraded-from-Windows-10 machines, images built before it defaulted on, or systems where an admin turned off Memory Integrity to fix a driver-compatibility complaint and never re-enabled it. Second, the blocklist is stale: Microsoft ships updates to the list, but they arrive through servicing, and a machine that is behind on updates is carrying an old roster of blocked hashes while new BYOVD drivers circulate freely.

How to check it on a single machine

Start with whether the enforcement mechanisms are even active. From an elevated PowerShell prompt:

Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesRunning, CodeIntegrityPolicyEnforcementStatus

A SecurityServicesRunning value that includes 2 means HVCI/Memory Integrity is running. You can also confirm the blocklist toggle directly in the registry:

Get-ItemProperty `
  "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
  -Name VulnerableDriverBlocklistEnable -ErrorAction SilentlyContinue

A value of 1 means the blocklist is enabled. If the property is missing or 0, the machine is relying on nothing but signature validation — which BYOVD defeats by design. To turn it on, enable Memory Integrity under Windows Security → Device security → Core isolation, or set the registry value and reboot after validating driver compatibility. Then confirm the machine is current on quality updates so the list itself is fresh.

Why this becomes a fleet problem

Checking one laptop is a five-minute exercise. Checking whether all 80 workstations, the four jump hosts, and the mixed bag of upgraded-from-Windows-10 machines are all enforcing a current blocklist is a different job entirely — and it is precisely the kind of setting that drifts silently. One driver-compatibility ticket, one imaging shortcut, one machine that fell behind on updates, and you have a hole nobody notices until an incident.

WinSentinel audits this locally as part of its kernel and exploit-mitigation checks: on any single machine, the free agent flags a disabled blocklist, missing HVCI, and update lag that would leave the list stale, with the exact remediation steps inline. That full-depth audit runs on one box with no limits.

Where an organization needs to prove the control holds across every endpoint, WinSentinel Pro rolls those per-machine findings up through a central node: you see which hosts have the blocklist off, get a drift alert the moment a machine regresses after someone disables Core Isolation, and can track update currency so no endpoint is quietly running a year-old roster of blocked hashes. The single-machine audit is the same either way — the fleet layer is about never having to trust that all of them stayed configured.

The takeaway

BYOVD works because signatures answer the wrong question. Windows already ships the right answer in the form of the Vulnerable Driver Blocklist — but only if it is enabled, backed by Memory Integrity where the hardware allows, and kept current through updates. Verify it on every machine, not just the newest ones, and treat a disabled or stale blocklist as a finding worth an incident-grade fix. The kernel is not a place you want to discover you were unprotected.