Edit for those looking for the TL;DR version of this thread:
There are 3 flaws related to vulnerable driver blocking / WDAC:
1) If HVCI is off, then WDAC blocks via file signer that have a FileAttrib qualifier (e.g. all by-signer entries in the MS vulnerable driver blocklist) will not be blocked
2) The driver block list that's pushed to endpoints is not the same list as the public driver blocklist. The on-endpoint blocklist is missing numerous hashes.
3) HVCI systems do not obey the FilePath qualifier for WDAC rules

MSRC has indicated that they don't consider any of these issues to be vulnerabilities, so they will not fix.

----- Original thread as follows -----

I recently deleted a thread here as my tests were not valid. What was wrong? The driver I was using as an example of "blocked via signer" was indeed in the Microsoft recommended driver block rules list for TWO YEARS (It's present in a March 2023 version of the list). Given that the blocklist is updated on Windows endpoints "1-2 times per year", this should be present in the blocklist on a Win11 machine in 2025, right? Get real. It's bugs all the way down. No, I haven't (yet?) investigated which drivers are in the official list online, but are missing on Windows endpoints. But the fact that the first viable-for-testing driver that I chose was NOT in the list on endpoints... let's just say that this isn't a good sniff test.

Anyway, the problem that came to my attention on the Bad Place was that a user complained that that a driver that was expected to be blocked was being allowed to run if HVCI ("Memory integrity") wasn't enabled. This can't be right, can it?

Yes, it's true. The drivers listed in the Microsoft recommended driver block rules list by way of their signing certificate do NOT result in the driver being blocked (via WDAC). So just as a test, I created my own WDAC block list (with App Control Wizard and applying it with ApplyWDAC) for an arbitrary driver.

Let's compare 3 drivers that should be blocked, on a system with HVCI off, and on a system with HVCI on.

• Blocked via Authentihash in the MS vulnerable driver blocklist
• Blocked via Signer Cert in the MS vulnerable driver blocklist
• Blocked via Signer Cert via WDAC manually

If you do not have HVCI enabled, you are likely missing driver blocks that you are supposed to be getting.

If we test with our own custom WDAC rules, we can confirm that all of the allowed properties to block by are indeed obeyed by Windows. Specifically:
Hash, FileName, FilePath, SignedVersion, PFN, Publisher, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, WHQL, WHQLPublisher, WHQLFilePublisher

When we test these blocking techniques individually, they all seem to work fine. Including blocking by signing cert (FilePublisher). So this suggests that WDAC blocking by signing cert is not broken, but rather there's something broken about the Microsoft recommended driver block rules list when it's not enforced by HVCI.

However, in the process of testing individual blocking techniques, I've discovered a third vulnerability. On a system that is successfully using the FilePath WDAC blocking directive, if I enable HVCI, that block will suddenly stop blocking.

That is, while turning on HVCI is a wise move across the board, this is a specific case where having HVCI enabled is ironically less secure than having it off. The Microsoft recommended driver block rules doesn't have any entries based on FilePath, so this block list is unaffected by this problem. But surely there's somebody out there with FilePath block rules that is unknowingly missing protection on systems with HVCI enabled.

To eliminate variables, I got these screenshots by starting with a system that has a working FilePath WDAC block enabled, and simply enabled HVCI on that same system. The mere act of enabling HVCI on a system causes a working FilePath rule to stop working.

It truly is bugs all the way down, but just to summarize what we've discovered after pulling a thread about blocked drivers not being blocked:

1. If HVCI is off, then the Microsoft recommended driver block rules list will not block any entries that are present based on signing certificate (FilePublisher)
2. The driver block list that you get by enabling the "Microsoft Vulnerable Driver Blocklist" feature in windows is not merely delayed (Microsoft reports that it's updated 1-2 times per year) from the public list, but more importantly it's a different list that you get. (Further investigation in how it differs is required)
3. If HVCI is on, any FilePath-based blocks will be ignored.

UPDATE
Per MSRC, FilePath WDAC rules do not work for kernel-mode drivers. Oddly, with HVCI disabled you can use FIlePath for driver blocking. But since MS claims that you can't do it, it's not a vulnerability.

Further investigation of the endpoint's driver blocklist being out of sync with the online one:

If count Authentihash, filename/version, and code signer entries, a February-2025-patched Win11 box has 1818 entries, while the online Microsoft recommended driver block rules list has 1906. The fact that the online list is more up to date than a thing that gets pushed out on Patch Tuesday is expected, right?

Wouldn't we be so lucky.

If we compare the online driver blocklist vs. the blocklist on fully patched Win11 endpoints and ignore the entries added in December 2024 (which are presumably not present because they're too new) we can break down the missing hashes:
Authentihash:
9 are 2 years old
3 are 1.8 years old
Signer:
3 are 2.4 years old

I'm only comfortable with one of those entries not (yet) being on Windows endpoints. What is the excuse for the rest? If Microsoft is going to maintain two different driver block lists (why?), perhaps it would be wise to do a good job of it? You know, to maybe check that they're in sync? 🤦‍♂️

If we think that WDAC individual block list rules work OK, but the Microsoft recommended driver block rules do not work on HVCI-disabled system, how can that be?

The MS list, despite listing blocked signers, also uses a FileAttrib qualifier for the signer being blocked. In the case of the Truesight driver I'm using for testing, the MS blocklist specifies a "FileNameand aMaximumFileVersion` property that is required for the block to take place.

Why is this done? If you simply use WDAC to block a file by it's signer, you'll have a lot of collateral damage.

That nasty driver you want to block? It also has signers that are legit. For example, Microsoft Windows Hardware Compatibility Publisher. 😀

What happens if we just attempt to block this Truesight driver based on its signer without using such qualifiers? Windows won't boot. Why? Well, this vsock.sys driver shares a signer with the bad Truesight driver. Therefore, without a precise block list, the driver will fail to load because the important driver is blocked.

So, based on our BSOD, we can conclude that non-HVCI WDAC driver blocking based on signer does work. But didn't I say earlier that it does not?

I'm glad you're paying attention. Yes, based on this test we can conclude that WDAC driver blocking based on signer does indeed work. But blocking based solely on signer never really happens in the real world, since it's important for Windows to be able to boot. So in the real world we have blocking by signer with FileAttrib qualifiers.

This is what's broken with non-HVCI attempts to block things based on signer. (Publisher and friends)

Without a FileAttrib qualifier, Windows will BSOD, thus proving that WDAC is effective in blocking drivers by signer. However, with a FileAttrib qualifier, Windows without HVCI won't bother blocking anything by signer.

But what about with HVCI on? Does turning HVCI on now make FileAttrib qualifiers work for block lists?

Wouldn't it be so easy? On the upside, blocking by signer with FileAttrib qualifiers works.

On the confusing side, the FileName qualifier is seemingly not enforced in a way that makes sense.

That is, I can make a copy of the Truesight driver and give it a completely different name (bysigner in my case), and it's still blocked by "Device Guard". I cannot fathom why/how this is the case. Other than HVCI-enabled systems having an altogether different blocklist than non-HVCI systems?

But as it is, DeniedSigner blocking with an associated FileAttrib qualifier is currently broken in Windows. In the case of non-HVCI systems, drivers are allowed that should be blocked. And in the case of HVCI systems, drivers are blocked that should probably be allowed.

I think I've reached my limit as to what my poor brain can grok with all of this. But all 3 bugs (vulnerabilities, IMO) are in Microsoft's hands, so we'll see how they sort it out.

@wdormann mean while at Securing Windows 11 you can no longer test Beta or Canary builds on VMware

BSOD Unsupported Processor

*host is 13th gen

@RonnyTNL
That's what you get for having a too-new processor?

FWIW, 12th Gen Intel is fine for me with Insider Canary.

Even recently, there are folks talking about how the Microsoft recommended driver block rules list protects against BYOVD attacks.

This is a lie. Or at best misinformation, which seems to unfortunately gets repeated by those who don't really understand how things work.

Yes, you can prevent an attacker from bringing their own driver ("vulnerable" or not) by using a signed (e.g. enforced by SecureBoot) WDAC policy. I hope you don't mind extra work, as this isn't easy/free.

If you want to dig deeper into the thought experiment about what constitutes a "vulnerable" driver vs. one that isn't vulnerable, feel free to read up on BYOVD Protection is a Lie (Part 2)

TL;DR: Anybody suggesting that the Microsoft recommended driver block rules protects against BYOVD is wrong. An attacker bringing their own driver is already an admin, and on default Windows configurations, an admin can do what they want on a system. They don't need vulnerabilities. Heck, an admin attacker can install arbitrary homemade drivers that have never even had a valid signature if they wanted to.

The Microsoft recommended driver block rules is fine for preventing vulnerable drivers that might be already present on your system from being exploited. But don't fool yourself into thinking that it will help protect against attackers bringing your own driver.

Once Microsoft fixes the blocking capabilities of the Microsoft recommended driver block rules on non-HVCI systems, then the ability for attackers to target already-present drivers will be further hampered. But the flaws that I've outlined in this thread won't affect attackers bringing their own drivers. They already own your system.

@wdormann you got a minute ;)

My Insider is a different build, this is my Canary build 27788.1000

@wdormann here is my Insider Beta which is broken since feb 8th. 22635.4945 ends with Install error - 0xc1900209

@wdormann and to top it off, stable 23H2 snapshot upgraded 50% of the ~20 machines from the same snapshot master fine to 24H2 on the 7th of Feb, continuing the other day it was game over the rest of the snapshots stay on 23H2 no matter what.

@RonnyTNL
Ah, it looks like I was on Insider "Dev" as opposed to Canary, despite what my snapshot was named. 😂
Attempting to install Canary update now...

@RonnyTNL
Yeah, I suspect that the 24H2 rollout is staged. I've seen no consistency in what gets offered the updated and what does not.

@RonnyTNL
Eh, 27802.1000 works for me. 🤷‍♂️

@wdormann

@wdormann Could you share your VM Hardware settings?

@RonnyTNL
https://pastebin.com/1fuQuWma

@wdormann 4️⃣ 0️⃣ 4️⃣

@RonnyTNL
LOL. It was there, but they deleted it. 😂

LOL. Just got a response from MSRC, and they don't consider any of the 3 vulnerabilities I reported to them (outlined earlier in this thread) to be security issues, and therefore will not be servicing any of them.

CWE-693: Protection Mechanism Failure is not a thing in Microsoft's minds, apparently.

@wdormann this is a bit on you though. You’ve reported this near the end of the fiscal year. The bug bounty prize pool is gone. They will fix it anyway in one or two releases (or it requires that much rework that we conveniently forget about Trustworth Computing 3 (4?))

@jtig @wdormann, is_vulnerability = some_func(reporter, datetime.now(), report)?

@jtig
I don't want a damn bounty.
I want them to:
1) Actually read my reports instead of skim them.
2) Acknowledge and fix the bugs.

Clearly this is too much to ask. 🤦‍♂️

One of the 3 vulnerabilities that I've outlined is that the on-endpoint driver blocklist is a differently-maintained list than the online list.
Am I being pedantic and nit-picking here?

Per MSRC, the discrepancy is intentional:

Lastly, regarding the Online Driver Blocklist, the online list is supposed to be a superset

Let's say that theoretically this is not a lie...
1) How well known is it that the online Microsoft recommended driver block rules list is intentionally a superset of what endpoints see? The language in the online blocklist clearly says that the blocklist gets put on endpoints via Windows Update. 🤔

2) Let's pick a sample driver used by the years-old exploit KDU. Driver number 1 provided by this tool is RTCore64.sys
This driver is definitely in the online Microsoft recommended driver block rules list. Let's test it out in a Windows 11 with the "Microsoft Vulnerable Driver Blocklist" option enabled.
Oh... it loads? And it allows us to disable driver signature verification?
This seems less than ideal.

Tell me, oh internet public, why might Microsoft intentionally choose to allow a years-old public exploit to continue to work?

Oh, right. It's easier to blow off a researcher with a "this is intentional" as opposed to actually read the report that they submitted and address the problem. 🤦‍♂️

@wdormann In their "defense" you did make the video reaaaaaaaaaallllllly long 😂

@cR0w
I mean, when they refused to accept my video on YouTube, they did tell me to upload the video to OneDrive, which could end up costing me money depending on my quota. 😂

@cR0w
I did have an AV vendor recently request my EICAR-containing PoC in a password-protected ZIP file in my already-PGP-encrypted email.
Presumably their workflow for handling encrypted emails automatically deleted my PoC. 😂

@cR0w
I assume that they eat their own dogfood, and their AV product "protected" them from my attack.

@wdormann @cR0w Reminds me of: https://project-zero.issues.chromium.org/issues/42452353#comment2

@cR0w @buherator @wdormann off topic: Your thoughts on an organization I co-founded? Link --> https://www.cascadiacommons.org/common-bond

@cR0w @wdormann Probably? Gmail definitely does that. Zero-click attack surface ftw!

@cR0w @wdormann I mean it's the logical next step if you want to pretend you can solve an unsolvable problem.

@buherator @cR0w
Yeah, even with a number of different ZIP passwords, I found that Gmail's SMTP server still found the evil inside if I didn't use PGP encryption at the higher layer.

@cR0w @buherator
I didn't investigate much further, but I suspect that Gmail's SMTP server will attempt a list of known passwords, plus each word that exists in the email itself to decrypt encrypted ZIP files that are attached.

@wdormann @cR0w @buherator

"Encrypted Zip files"?

You over estimate the "Clean Opsec" of these Muppets.

They password protect the documents in Orifice365/Google Docs cloud.

Did you verify that Gmail doesn't flag just all encrypted ZIP files of any contents as a "potential security issue" without decrypting them?

CC: @cR0w@infosec.exchange @buherator@infosec.place

@cy @cR0w @buherator
Ah, good guess!

Using standard zip encryption with an unguessable password not in the message body:

• <eicar string> as eicar.com: Blocked
• hi as hi.txt: Allowed
• <eicar string> as wd.txt: Blocked

Were it not for the last case, I'd assume that somehow the combination of encrypted + suspicious filename = Block. But that last case...
I'm at a complete loss as for how the EICAR string as wd.txt in an encrypted ZIP file is blocked. 🤷‍♂️

@cR0w @cy @buherator
Eh, whatever zip comes with macOS. Info-ZIP, it seems.

I assume it uses standard ZIP 2.0 encryption, as opposed to the newer AES.

@pup @cR0w @buherator @cy
CRC32 isn't enough to uniquely identify files. There'd be too many false positives due to collisions, IMO.

@cy @cR0w @buherator
Actually, after some further tests:

• The Info-ZIP that comes with macOS creates an encrypted ZIP 1.0 archive, and is reported to be blocked by Gmail SMTP.
• The same encrypted ZIP from 7-zip using "ZipCrypto", or AES encryption is also reported to be blocked by Gmail SMTP.
• I say "reported to be blocked" as while the Gmail SMTP server gives me this warning saying that the sending of the message failed, it actually does send the message. But seemingly delayed slightly. 🤦‍♂️

@pup @cR0w @buherator @cy
FWIW, I generated a file with the same size and CRC32 as eicar.com and put it in a password-protected ZIP file and the Gmail SMTP server didn't complain a bit. 🤔

@wdormann @cy @cR0w Not sure this came up while I was sleeping, but regular ZIP archives don't encrypt metadata (file names) so "trying to send an executable in a pw protected archive" may be grounds for a block too.

@buherator @cy @cR0w
But why would the EICAR string with the file name wd.txt get blocked in an encrypted (password-protected) ZIP?

@wdormann @cy @cR0w I'm not saying pw guessing is not in the picture, but metadata can be a good prefilter (and also something to count with when testing).

@wdormann @buherator @cy @cR0w I know that emails sent via 1&1 were scaned when using classic zip encryption. It works with AES zips.

@buherator @cy @cR0w
That's why I used a randomly generated GUID for the password. 😀

@cR0w @pup @buherator @cy
FWIW, I did some testing with the eicar string in an AES-encrypted zip (via 7-zip)

• EICAR as eicar.com : Blocked
• EICAR as hello.txt : Allowed
• EICAR with an appended A as eicar.com : Blocked
• CRC32 collision as eicar.com: Blocked
• CRC32 collision as hello.txt: Allowed

So at least as of this specific test, it may be that the Gmail SMTP server is perhaps just using filenames for "blocking" the sending of mail.

And again, I use scare quotes around "blocked" as while the SMTP server does say that the message was blocked "because its content presents a potential security issue." But the email is indeed sent to the recipient., despite the warning.

@wdormann @cR0w @pup @cy Could you do a run with `7z -mhe=on`?

@cR0w @pup @buherator @cy
Just standard unwashed masses Gmail.
And now that I think about when I ran into this in the past, it was a VHD file that contained an EICAR file in the filesystem. And that was "blocked"

So I suspect that the Gmail SMTP has a list of "don't allow in an encrypted ZIP" file extensions that will generate the error (but send anyway 😂)

@buherator @cy @cR0w @pup
An encrypted .7z file that uses -mhe=on is blocked, regardless of contents.

@cR0w @buherator @cy @pup
No, that's allowed.

@cR0w @buherator @cy @pup
Nor I. 😂

@wdormann @cR0w @pup @buherator @cy

I've been quietly watching all these tests and trying to come up with theories that explain the results.

I will laugh my ass off if it turns out there is some machine learning algorithm at play here, and that the results are influenced by previous results/the whole thing is basically nondeterministic.

May try and send a similar-to-eicar file in an encrypted zip by itself. Then send the same file in an encrypted zip with the actual eicar/something that has been known bad in the zip as well. Something to maybe 'prime the pump' that the similar-to-eicar file is sketchy...

Then try and re-send the original similar-to eicar file in an encrypted zip by itself again and see if the results are different from the first time the file was tested?