How to update your Windows driver blocklist to keep malicious drivers away

For many years, attackers have used and abused various ways to get on our systems. From phishing to tricking us to click on websites, if an attacker can get their code on our systems they are no longer our systems. Attackers will even invest the time, energy, and expense to get their malicious drivers approved and co-designed through the Windows Hardware Compatibility Program in order to gain access to our machines. Ensuring that these malicious drivers are blocked is a key method for protecting systems.

Microsoft has long touted a means to update this master listing on our systems and, in theory, the idea was valid: using settings and security hardware on the computer, enabling hypervisor-protected code integrity (HVCI) was supposed to protect systems from malicious drivers. Attackers have used such attacks in the past ranging from RobbinHood, Uroburos, Derusbi, GrayFish, and Sauron, to campaigns by the threat actor STRONTIUM. As a Microsoft blog in 2020 pointed out, if a computer had HVCI enabled, it would be able to defend itself against vulnerable and malicious drivers. In the blog post, it was noted that “Microsoft threat research teams continuously monitor the threat ecosystem and update the list of drivers that in the Microsoft-supplied blocklist. This blocklist is pushed down to devices via Windows update.”

Trust but verify that driver blocklists are updating

There is an oft-used phrase in cybersecurity: “trust but verify”. When Ars Technica Security Editor Dan Goodin decided to verify this setting, he began to poke around to confirm that the malicious driver blocklist was indeed updating. Expecting to find that it was, he instead found that it wasn’t. Goodin reached out to researcher Will Dornmann, Senior Vulnerability Analyst at ANALYGENCE, and confirmed that this feature wasn’t working as expected. Goodin and Dormann found that even with HVCI enabled, the vulnerable driver list wasn’t getting updated as it was supposed to. Rather, on Windows 10, it hadn’t been receiving updates since 2019.

Microsoft recently posted that with the Windows 11 22H2 update the vulnerable driver blocklist setting is enabled by default. They posted that: “the blocklist is updated with each new major release of Windows. We plan to update the current blocklist for non-Windows 11 customers in an upcoming servicing release and will occasionally publish future updates through regular Windows servicing.” Thus, they finally admitted that it was not being serviced with the Microsoft update process as we had assumed.

As a result of Goodwin and Dormann finding that the driver blocklist was not getting updated, Microsoft provided a revised How-To guide in order to manually refresh the blocklist. So, if you’ve relied or planned your security posture on this driver blocklist functionality, I recommend that you add updating this driver block list manually to your to-do list until Microsoft includes a process on a regular basis to update this blocklist.

Recommended steps to update driver blocklists

As noted in the documentation Microsoft recommends you can perform the following steps:

• Download the WDAC policy refresh tool. Choose the version that you will need for your version of Windows (32 bit, 64 bit or ARM versions).
• Download and extract the vulnerable driver blocklist binaries.
• Select either the audit only version or the enforced version and rename the file to SiPolicy.p7b.
• Copy SiPolicy.p7b to %windir%\system32\CodeIntegrity.
• Run the WDAC policy refresh tool you downloaded in Step 1 above to activate and refresh all WDAC policies on your computer.

To check that the policy was successfully applied on your computer:

• Open Event Viewer.
• Browse to Applications and Services Logs – Microsoft – Windows – CodeIntegrity – Operational.
• Select Filter Current Log.
• Replace “<All Event IDs>” with “3099” and select OK.
• Look for a 3099 event where the PolicyNameBuffer and PolicyIdBuffer match the name and ID PolicyInfo settings found at the bottom of the blocklist WDAC Policy XML in this article. NOTE: Your computer may have more than one 3099 event if other WDAC policies are also present.

You should be able to build a PowerShell script to deploy the updated values across your network using similar tools for setting WDAC policies in your network. You’ll need to download the WDAC policy refresh tool on all your endpoints in order to update across your network.

Will Dormann has provided his own independent tool to update the driver list. For this, perform the following steps:

• Open an administrator command prompt.
• Type in powershell_ise.exe to start Powershell ISE
• From a Github link, copy and paste (CTRL+A, CTRL+c and CTRL+v) into the Powershell ISE
• Type ApplyWDACPolicy -auto -enforce and hit enter.

As always ensure that you test on a computer before rolling it out firm-wide.

Some users – primarily gamers – still disable blocklist intentionally

While those of us with secure networks want to enforce this blocklist, it’s always fascinating to find examples of people who intentionally disable this feature. Case in point is the gamer community, who want to get around malicious driver blocks. Using gaming cheats is blocked by Windows 11 22H2, clearly showcasing that, at least for this platform, the malicious driver block utility is working. As they note, “HKLM\System\CurrentControlSet\Control\CI\Config\, then create a new DWORD named VulnerableDriverBlocklistEnable and set to 0” will bypass the malicious driver block.

You may want to add monitoring for this registry key to ensure that malicious actors don’t disable this blocking and leave you exposed. If your firm does not already have a solution to proactively monitor file and registry changes, you may want to consider using tools like ProcMon or Process Monitor in order to review changes made over time. However, it’s not recommended to run it for monitoring 24/7. For long-term review of changes to the system, I recommend deploying Sysmon.  

“System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time.” I recommend that you install it on outward internet-facing servers and any workstation that is subject to increased risk. You can also consider deploying it to all workstations as the overhead of the Sysmon tool running in the background is minimal.

Bottom line: the key thought to keep in mind behind any vendor claim of security is to trust but verify. It would appear that even Microsoft doesn’t fully understand their own systems. It’s imperative that we do all we can to better understand them.