Thread by @wdormann

The Microsoft recommended driver block rules page states that the driver block list "is applied to" HVCI-enabled devices.
Yet here is an HVCI-enabled system, and one of the drivers in the block list (WinRing0) is happily loaded.
I don't believe the docs.
docs.microsoft.com/en-us/windows/…

https://twitter.com/wdormann/status/1570520940811030528

The GUI for "Microsoft Vulnerable Driver Blocklist" isn't present unless you're running the "Dev Channel" Insider Preview for Windows 11.
Yet the documentation for Microsoft recommended driver block rules says that it gets applied to HVCI-enabled Win10.

https://twitter.com/wdormann/status/1570123694554374144

If I *MANUALLY* apply the driver blocklist using WDAC in enforcing mode, the driver is blocked.
But the documentation for the Microsoft recommended driver block rules assures me that it is applied to Windows 10 HVCI-enabled machines.
Why do I have trust issues, I wonder...

Two things seem to be at play here:
1) Windows never seems to get updates to the recommended driver block rules. Win10 always stays at 10.0.19014.0, and Win11 stays at 10.0.21250.0.
2) Insider preview w/ updated block list still doesn't actually block.
🤦‍♂️

https://twitter.com/wdormann/status/1570849857346367489

Even with the bleeding-edge Insider Preview Dev build that has a nice "Microsoft Vulnerable Driver Blocklist" thing in the GUI doesn't actually block a driver in the Microsoft recommended driver block rules.
Both without HVCI, and with HVCI enabled.
What am I missing here??

Doing a Google search to find a CVE for a driver name in the Microsoft recommended driver block rules led me to a vulnerable driver that is *NOT* in the list.
So therefore my driver blocking experiments have been invalid. 🤦‍♂️
Does anybody have a good known blocked driver example?

Courtesy of github.com/eclypsium/Scre… , I've found that the MSI BS_HWMIO64_W10.sys driver is a good canary test for the Microsoft recommended driver block rules, especially since it's in there via version, and not by hash.
It's AUTOMATICALLY blocked on a system with HVCI enabled.👍

If HVCI is not enabled, there is NO automatic blocking of the known vulnerable driver on the Microsoft recommended driver block rules list.

What's concerning is that regardless of how many Windows Updates happen, the code integrity policy on a Win10 machine is at least 2 years old.
That is, while HVCI-enabled systems will get the benefit of automatic driver blocking, the list never updates, so will be quite old!

The CIP on the current Windows 10 version always stays at 10.0.19014.0 regardless of Windows Updates happening, and Windows 11 always stays at 10.0.21250.0.
It's nice that the Microsoft recommended driver block rules is updated over time online, Windows doesn't see those updates.

The initial commit of the Microsoft recommended driver block rules web page on Github is from October 16, 2020, and it's 10.0.19565.0.
github.com/MicrosoftDocs/…
What you get with Win10 21H2 + add all Windows Updates is still 10.0.19014.0. So I can't even tell how old that list is.

It appears that this new (not really out in the wild yet) "Microsoft Vulnerable Driver Blocklist" option handles the case where HVCI is NOT enabled. The driver is blocked, without having to manually sift through and merge / apply WDAC hell.

What's a touch misleading is that "Microsoft Vulnerable Driver Blocklist" is listed under "Core isolation", which "use virtualization-based security".
Which implies that enabling it will enable HVCI and/or will only be possible with HVCI.
This is wrong. It doesn't really fit here

The Microsoft recommended driver block rules automatically used by HVCI are provided by:
C:\Windows\System32\CodeIntegrity\driversipolicy.p7b
With a fully-patched latest (21H2) Windows 10 OS, this file was last modified on Dec 12, 2019.
YOU don't get updates to this file. Duh?

I'll just manually install the Microsoft recommended driver block rules using the XML available at learn.microsoft.com/en-us/windows/… , right?
Well, if you're using "script" deployment, be aware of:
1) This Policy has an "audit" section it it. If you don't remove it, nothing's blocked.
...

2) Starting with Windows 10 1903, policies are deployed as {GUID}.cip for multi-format policy files.
This MS driver block list? NOT a multi-format policy file!
Workaround:
You can deploy as {PolicyTypeID_GUID}.cip
EXCEPT:
{D2BDA982-CCF6-4344-AC5B-0B44427B6816} is special. Change!

If the planets are in alignment, you can compile and install this policy (with the new GUID), and it will be fully applied during the next reboot.
After Windows comes up, you should notice that drivers in the *CURRENT* Microsoft recommended driver block rules will be blocked.

Ironically, using the not-recommended WDAC method for blocking drivers gets you the current list. And if the system happens to have HVCI enabled, WDAC will take advantage of HVCI for enforcement.
If you use the "Turn HVCI on" method, you'll get a 3-year old list with Win 10. 🤷‍♂️

How about Windows Server 2016?
The "Microsoft recommended driver block rules" doc says it applies to it. We get protections if HVCI is enabled, right?
No, I see no evidence that any drivers are explicitly blocked. WHQL is enforced, but that's unrelated to the driver blocklist.

What if I've been paying attention to things, and I know that I need to *manually* apply the latest Microsoft recommended driver block rules, which "applies to" Windows Server 2016? That should just work, right?

You clearly haven't been paying CLOSE attention, have you? 😀

If you don't trust the Microsoft recommended driver block rules to not break things, or if you're making your own rules, rather than getting rid of the "Audit Mode" option, you can change it to "Boot Audit On Failure" (case sensitive!).
Instead of non-booting Windows, audit logs.

But please don't rely on "Boot Audit On Failure" if you're on Windows Server 2016 and you have a bad WDAC driver policy (e.g. blocks critical drivers).
In my testing, that option will simply cause Windows to fail to boot in a different way, which isn't really an improvement.

In both cases, the fix is easy.
Select the "Startup Settings" option in Advanced options.
Select "Disable Driver Signature Enforcement" and once back in Windows, undo what you did.
So yeah, Windows isn't bricked. But I feel like it takes a certain masochism to choose WDAC. 😫

How might one get a "bad" WDAC driver policy installed? Imagine this:
- You use New-CIPolicy to create a "deny" policy using a known-bad driver.
- You remove the "Audit Mode" option, because you're feeling lucky.

Congrats! You now told Windows that it cannot load ANY driver.

Why does such a seemingly innocuous action have such catastrophic consequences?
Well, WDAC is an ALLOW list capability.
So if you tell WDAC to "Just block this one driver", you'll have accomplished telling Windows to not allow anything, including explicitly blocking that driver.

For people familiar with how WDAC works, this may be a "well, duh!" moment.
But I'm not one of those people, and this thread was my journey along the way.
And I bet there are other sysadmins there that are also not familiar with WDAC and its idiosyncrasies.
So maybe this'll help.

How about Windows Server 2019?
Surely this Microsoft recommended driver block rules thing that "Applies to" "Windows Server 2016 or above" comes into play, right?
Well, sorta.
1) The driver blocklist on fully-patched Server 2019 is from 2018 contains only TWO blocked drivers.
...

2) Even if you wanted to manually install the "Microsoft recommended driver block rules" policy, it seems to silently fail to do anything on Windows Server 2019.
At least Server 2016 had the courtesy to tell you that it doesn't understand the policy XML file.

We're all having fun here, right?
Why stop now?
Microsoft Attack Surface Reduction (ASR) can also block drivers and the lists are in sync with the HVCI-enforced driver block list.
Except... in my testing it doesn't block a thing.
Child process blocking: ✅
Vulnerable drivers: ❌

Or if you'd prefer to see a screen recording as proof:
The "Block all Office applications from creating child processes" ASR rule clearly works fine.
The "Block abuse of exploited vulnerable signed drivers" ASR rule does nothing to block a driver that's known to be vulnerable.

Regarding Server 2016/2019 incompatibility with the list:
1) Server 2016 doesn't understand the MaximumFileVersion= attribute, so those will need to be removed.
2) On September 19, Microsoft changed PolicyTypeId to {A244370E-44C9-4C06-B551-F6016E563076}.
github.com/MicrosoftDocs/…

My earlier troubles in this thread with Windows Server were related to the fact that I was still using an XML file that was a week old. Maybe somebody at MS is monitoring this thread? 😀

All I want to do is learn about WDAC.
But when the official documentation seems, well, wrong...
Why do I get the impression that there aren't a lot of people doing this in the real world? 🤔

To be fair, this EFI stuff may not even matter in my particular case, as it appears that *SIGNED* WDAC policies are a whole other animal, beyond what I'm looking to accomplish.
learn.microsoft.com/en-us/windows/…
I just would prefer documentation to be not obviously wrong.
Too much to ask??

Instead of "In addition to the steps outlined above, the binary policy file must also be copied to the device's EFI partition."
more user-friendly would be:
"If you have implemented a signed WDAC policy, you must perform these steps for EFI. Otherwise, these steps are irrelevant"

Based on my experience in this thread, perhaps there is a need for a SIMPLE PowerShell script that can take a WDAC policy of any format, and apply it to any supported Windows system.
Does this sound useful to anybody, or is nobody using WDAC in the real world with PowerShell?

As requested: github.com/wdormann/apply…
For people not too familiar with WDAC, this PowerShell script can help you easily apply WDAC rules, such as the Microsoft recommended driver block rules.
For those already using WDAC, please stick to whatever you're already doing.

I've updated this script to have an -auto option, which will automatically download the newly/available precompiled driver block list from Microsoft and install it, in either the default audit mode, or enforcing.
Easier than requiring your own XML file.

FTR, we "all" know by now that the Microsoft recommended driver block rules isn't pushed out to Windows endpoints. The Windows 10 list is from 2019.
What about Windows Server 2019? You get TWO blocked drivers: capcom.sys and bandai.sys
Server 2016: ZERO. There is no list.

Since we now know that this statement has never been true, can we maybe update this page to reflect reality? @msftsecurity
microsoft.com/security/blog/…

Or maybe this blog post from 2020 advertising Secured Core PCs. It's promoting a feature that doesn't exist.
microsoft.com/security/blog/…