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 \u201cMicrosoft 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.\u201dTrust but verify that driver blocklists are updatingThere is an oft-used phrase in cybersecurity: \u201ctrust but verify\u201d. 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\u2019t. Goodin reached out to researcher Will Dornmann, Senior Vulnerability Analyst at ANALYGENCE, and confirmed that this feature wasn\u2019t working as expected. Goodin and Dormann found that even with HVCI enabled, the vulnerable driver list wasn\u2019t getting updated as it was supposed to. Rather, on Windows 10, it hadn\u2019t 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: \u201cthe 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.\u201d 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\u2019ve 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 blocklistsAs 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%system32CodeIntegrity.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 \u2013 Operational.Select Filter Current Log.Replace "" 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\u2019ll 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 ISEFrom a Github link, copy and paste (CTRL+A, CTRL+c and CTRL+v) into the Powershell ISEType ApplyWDACPolicy -auto -enforce and hit enter.As always ensure that you test on a computer before rolling it out firm-wide.Some users \u2013 primarily gamers \u2013 still disable blocklist intentionallyWhile those of us with secure networks want to enforce this blocklist, it\u2019s 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, \u201cHKLMSystemCurrentControlSetControlCIConfig, then create a new DWORD named VulnerableDriverBlocklistEnable and set to 0\u201d will bypass the malicious driver block.You may want to add monitoring for this registry key to ensure that malicious actors don\u2019t 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\u2019s not recommended to run it for monitoring 24\/7. For long-term review of changes to the system, I recommend deploying Sysmon. \u00a0\u201cSystem 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.\u201d 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\u2019t fully understand their own systems. It\u2019s imperative that we do all we can to better understand them.Microsoft delivers an updateIn a late breaking change, on October 26, Microsoft released in a preview update an updated driver blocklist. As noted in KB5020779, this preview release addresses an issue that only updates the blocklist for full Windows OS releases. When you install this release, the blocklist on older OS versions will be the same as the blocklist on Windows 11, version 21H2 and later. This fix will be rolled into the November security updates to be released on November 8, 2022 and thus manually updating using this cumbersome process will no longer be needed. Clearly Microsoft understood that this was not acceptable process to keep our machines protected.