Microsoft vulnerable driver blocklist: stop BYOVD

Loading a kernel driver needs administrator rights and a valid signature. Attackers who already have admin rights want the kernel, because from there they can kill EDR processes, strip LSA protection from LSASS or disable tamper protection. They cannot sign a malicious driver, so they bring a legitimately signed one with a known vulnerability, load it, and exploit it. That is bring your own vulnerable driver (BYOVD), and it is how most "EDR killer" tools used by ransomware affiliates work.

The Microsoft vulnerable driver blocklist is an App Control policy that refuses to load known-vulnerable and known-malicious drivers. Microsoft maintains it with hardware vendors and ships it in Windows. This guide goes deeper than the mention in the App Control pillar: how to confirm it is active, how to keep it current and how to handle the gaps.

What the blocklist is, and what it is not

It is not a full driver allowlist. A vulnerable driver that Microsoft has not added yet will load. For that reason the blocklist is a baseline to combine with detection and, on high-value systems, a full App Control policy.

Step 1: check the current state

On a single machine, Windows Security shows it under Device security > Core isolation details > Microsoft Vulnerable Driver Blocklist. When memory integrity, Smart App Control or S mode is on, the toggle is on and greyed out, because those features always enforce the blocklist.

The setting behind the toggle is a registry value:

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

1 means enabled. Also check whether memory integrity is running, since that guarantees enforcement:

(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard).SecurityServicesRunning   # 2 = memory integrity (HVCI)

Across a fleet, collect both values with your management tool, a Configuration Manager hardware inventory extension or an Intune remediation script in detect-only mode. Focus on Windows Server first: in-place upgraded servers and VMs without virtualization-based security are the usual gaps.

Step 2: enable it where it is off

The simplest fix is to turn on memory integrity (HVCI), which brings the blocklist with it and blocks a wider class of kernel attacks. Where HVCI is not possible yet (incompatible drivers, older hardware), set the blocklist on its own:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
  -Name VulnerableDriverBlocklistEnable -Value 1 -Type DWord

Deploy that value with a Group Policy Preferences registry item or an Intune remediation, and reboot: the driver policy is evaluated at boot. On builds where the switch does not exist, deploy the blocklist as an App Control policy instead (next step).

Step 3: stay current between Windows releases

The copy shipped with Windows lags behind the list Microsoft publishes. Microsoft offers the latest blocklist as a download (linked from the "Microsoft recommended driver block rules" page in the App Control documentation) in both XML and binary form, with audit and enforced variants.

Two ways to use it:

1. Standalone: Microsoft's documented method is to rename the audit or enforced binary to SiPolicy.p7b, copy it to %windir%\System32\CodeIntegrity and run the App Control policy refresh tool (or reboot). Test the audit version first on a pilot ring. That file name is the single-policy slot, so it replaces any existing single-format policy on the device. Where the device supports multiple policies, Microsoft recommends deploying the blocklist alongside your existing policies instead, for example by converting the published XML (here DriverBlockRules.xml) to a .cip and applying it with CiTool on Windows 11 22H2 and later:

   PowerShell

   Copy-Item .\DriverBlockRules.xml .\DriverBlock.xml
   Set-CIPolicyIdInfo -FilePath .\DriverBlock.xml -ResetPolicyID   # multiple-policy format, new ID
   ConvertFrom-CIPolicy -XmlFilePath .\DriverBlock.xml -BinaryFilePath .\DriverBlock.cip
   CiTool.exe --update-policy .\DriverBlock.cip
   CiTool.exe --list-policies

   Drivers already running are only blocked after a reboot.

2. Merged into your App Control base policy: if you already enforce App Control, merge the published XML into your base. The published XML contains allow-all rules so that it can run on its own; remove those rules before merging into an allowlist policy, or you will open your allowlist completely.

   PowerShell

   Merge-CIPolicy -PolicyPaths .\Base.xml, .\DriverBlockRules.xml -OutputFilePath .\Base-merged.xml

Whichever you choose, put a recurring task in your change calendar: check the published version each quarter and after major BYOVD disclosures.

Step 4: add the ASR rule and detection

The blocklist stops a driver from loading. Two more layers help:

• ASR rule "Block abuse of exploited vulnerable signed drivers" (GUID 56a863a9-875e-4185-98a7-b882c64b5ce5) stops applications from writing known vulnerable drivers to disk. Set it to block; it is in the standard protection set described in the ASR rules guide.
• Detection on driver loads. Sysmon event 6 (driver loaded) records the hash and signature of every driver. Compare new hashes against your known-good inventory and against community lists such as LOLDrivers. System log event 7045 (a service was installed) catches the service creation that usually precedes a driver load.

Drivers used in real BYOVD attacks are often old, legitimately signed utilities: overclocking tools, vendor firmware updaters and anti-cheat components. The same signed file can be harmless on a gaming PC and a red flag on a file server.

A quick way to review driver loads on one host with Sysmon installed:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=6} -MaxEvents 500 |
  ForEach-Object { $x = [xml]$_.ToXml(); [pscustomobject]@{
    Time      = $_.TimeCreated
    Driver    = ($x.Event.EventData.Data | Where-Object Name -eq 'ImageLoaded').'#text'
    Signature = ($x.Event.EventData.Data | Where-Object Name -eq 'Signature').'#text'
    Hashes    = ($x.Event.EventData.Data | Where-Object Name -eq 'Hashes').'#text' } } |
  Sort-Object Driver -Unique

Anything loaded from a user profile, C:\ProgramData, C:\Windows\Temp or another writable location is suspicious regardless of its signature.

Step 5: go further on servers

The blocklist answers "is this driver known to be bad?". On servers, you can ask the stronger question "is this driver expected here?". Server hardware changes rarely, so the set of drivers is small and stable, which makes a driver allowlist realistic:

1. Build an App Control policy from a reference server of each hardware model, with kernel drivers at publisher level (New-CIPolicy -Level Publisher -Fallback Hash -ScanPath C:\Windows\System32\drivers).
2. Merge the recommended driver block rules into it, without their allow-all rules.
3. Run it in audit mode for a full patch cycle, including firmware and storage driver updates, then enforce.

If that is too much for now, at least keep a driver inventory per server model and alert on any driver whose hash has never been seen in your estate. The managed installer guide covers how to keep such a policy maintainable once it grows beyond drivers.

What breaks

Very little, which is why this control should be universal. The rare cases:

• Old hardware utilities: vendor tools that ship a vulnerable driver version (fan control, RGB lighting, BIOS flashing tools). The fix is the vendor's updated version, which normally is not on the list.
• Legacy anti-cheat or DRM on personal devices.
• Specialised industrial or lab drivers that were never updated.

When a driver is blocked, the device keeps booting, but the component fails to start. Check before enforcing on servers with unusual hardware, and resist the temptation to switch the blocklist off for one tool; replace or isolate the tool.

Verify it

1. Policy active: CiTool.exe --list-policies lists the active policies, including the driver block policy, with their version; compare the version with the one you intended to deploy.
2. Boot-time activation: in Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, event 3099 records each policy activated at boot, with its name and version.
3. Blocks: events 3077 (enforced) and 3076 (audit) in the same log show a driver that was, or would have been, blocked. Event 3089 follows with the signature details.
4. Test safely: do not download vulnerable drivers onto production systems to test. Use an isolated lab VM, or rely on the policy and event checks above.

Forward CodeIntegrity events to your SIEM. A blocked driver on a server is almost never an accident; treat event 3077 for a known BYOVD driver as an active intrusion signal and start incident response.

Checklist

• VulnerableDriverBlocklistEnable = 1, or memory integrity running, on every client and server
• Servers and VMs without virtualization-based security checked explicitly
• Latest published blocklist deployed, tested first in audit on a pilot ring
• Allow-all rules removed before merging the blocklist into an App Control allowlist
• ASR rule for vulnerable signed drivers in block mode
• Sysmon event 6 and System event 7045 collected and reviewed
• CodeIntegrity 3077 on drivers alerted as a high-severity event
• Quarterly task to check for a newer blocklist version

The blocklist is a small change with an outsized effect on how attackers disable your defences. It works best alongside memory integrity and a full policy from the application control area, with the managed installer keeping that policy maintainable.