Serious Discussion BYOVD attacks, prevention, and Core Isolation.

[Andy Ful]

BYOVD attacks, prevention, and Core Isolation.

The BYOVD attack involves introducing a digitally signed and trusted vulnerable driver into the kernel and exploiting it to gain kernel-level access.

For simplicity, the protective features can be classified as:
1. Prevention: The installation of the driver is prevented before it can be loaded.
2. Blocking: Loading of the driver is blocked.


BLOCKING

To avoid misunderstanding, I do not mean that mentioning "Blocking" in the second point makes it less important.
Simply, it happens later in the infection stage.
It is worth mentioning that such driver blocking features as Memory Integrity and Microsoft Vulnerable Driver Blocklist (both included in Core Isolation) are the most robust ones (hardest to bypass). Memory Integrity (MI) is protected by VBS. Microsoft Vulnerable Driver Blocklist (MVDB) is protected by VBS when MI is enabled. If not, then MVDB depends on standard kernel-mode code integrity mechanisms (less robust than VBS).

Another feature that can be hardened by VBS is App Control for Businesses (previously known as WDAC). It has the ability to prevent driver installation (User Mode Code Integrity) and block driver loading.
Properly configured WDAC is a strong protection against BYOVD attacks. Many enterprises run WDAC without MI enabled, due to compatibility problems. However, WDAC with enabled MI better mitigates kernel exploits.


PREVENTION

Enterprises use many preventive features to fight BYOVD attacks. In the case of Microsoft Defender (MD):
1. Multifactor authentication.
2. Network monitoring.
3. Advanced Hunting queries.
4. MD ASR rules (enabling all rules are recommended).
5. Web/email protection, etc.

All those features are important.


Home environment with MD.

At home, the WDAC can be replaced by Smart App Control.
Core Isolation settings should be enabled.
MD ASR rules should be enabled (by using PowerShell or a dedicated application).
Solid web protection and a hardened firewall are also highly recommended.


Differences between "Microsoft Vulnerable Driver Blocklist" (MVDB) and ASR rule "Block abuse of exploited vulnerable signed drivers".

The MVDB is updated with each new major release of Windows, typically 1-2 times per year. This block list can miss some vulnerable drivers included in the WDAC blocklist. The most current MVDB blocklist is also available as an optional update.

A better updated driver blocklist is included in the ASR rule. This blocklist is triggered only when malware tries to install/drop the driver file to disk. It does not block already installed drivers. Although it can prevent most BYOVD attacks, it is not as robust as MVDB. For example:

• UEFI bootkits can bypass it and install vulnerable drivers.
• ASR rules depend on Microsoft Defender and may fail if it is tampered with.
• ASR rules can be deactivated by user-mode processes.

 

[Parkinsond]

Attack surface reduction rule for pre-execution protection, and Microsoft vulnerable driver blocklist for post-execution protection.

 

[Divergent]

This is an excellent summary, Andy.

You have precisely articulated the technical reasoning behind my report's prioritization.

You correctly identify that Memory Integrity/HVCI is the 'most robust (hardest to bypass)' defense.

You confirm that the Vulnerable Driver Blocklist depends on Memory Integrity to be protected by VBS. As you noted, without it, the blocklist is 'less robust.'

This is exactly why my report prioritizes Core Isolation.

We prioritize the 'Most Robust' layer.

We ensure the Blocklist has the VBS protection it needs to function correctly.

I am glad we have reached a consensus. This classification perfectly supports the architectural hierarchy I presented.

 

[Andy Ful]

Attack surface reduction rule for pre-execution protection, and Microsoft vulnerable driver blocklist for post-execution protection.

MVDB is not exactly a post-execution protection. It can be triggered at the boot-time when no malware has been executed yet.
Of course, some malware had to be executed/implanted during one of the past Windows sessions.

 

[Andy Ful]

This is an excellent summary, Andy.

Thanks. I tried to present it as clearly as possible.

 

[Parkinsond]

MVDB is not exactly a post-execution protection. It can be triggered at the boot-time when no malware has been executed yet.
Of course, some malware had to be executed/implanted during one of the past Windows sessions.

Can the same concept be applied to ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" and WDAC handling of executable files?

 

[Zero Knowledge]

I thought we learnt blacklisting vulnerable software/drivers does not equal protection hence why we invented whitelisting and anti-exploit protection.

MS can blacklist and block bad drivers but how many vulnerable drivers are out there? Probably tens of thousands.

 

[Divergent]

I thought we learnt blacklisting vulnerable software/drivers does not equal protection hence why we invented whitelisting and anti-exploit protection.

MS can blacklist and block bad drivers but how many vulnerable drivers are out there? Probably tens of thousands.

You are right that Whitelisting is theoretically stronger, but for a Home User, it is a usability nightmare that breaks games and updates constantly.

To answer your point about 'anti-exploit protection', that is exactly what Core Isolation (HVCI) is.

It isn't just a 'Blacklist' of bad names. It uses hardware virtualization to physically lock down kernel memory.

The Blocklist stops the known weaponized drivers (The Bouncer).

Core Isolation (HVCI) is the 'Anti-Exploit' rule. It prevents ANY driver, even one NOT on the blocklist, from injecting malicious code into the kernel.

So, if a brand new vulnerable driver appears tomorrow (and isn't on the list yet), Core Isolation still stops the attack technique.

It's prioritized because it provides that architectural anti-exploit layer without breaking the user's computer.

 

[Halp2001]

In cases where core isolation cannot remain active due to compatibility issues, what other security measures would be considered suitable as a substitute or complement?

 

[Divergent]

In cases where core isolation cannot remain active due to compatibility issues, what other security measures would be considered suitable as a substitute or complement?

If Core Isolation cannot be used due to driver compatibility issues, the most suitable complement is enabling the Microsoft Defender Attack Surface Reduction (ASR) rule: "Block abuse of exploited vulnerable signed drivers." This acts as a software-based prevention layer that stops vulnerable drivers from being dropped or installed in the first place.

However, since ASR is an Enterprise feature, Windows Home users lack a built-in menu to manage it. While you can force-enable it via PowerShell commands, doing so carries significant risks for the average user.

Unlike standard antivirus, ASR rules often block legitimate software (like games or specialized hardware drivers) with cryptic errors and no simple way to click "Allow."

Because these settings are hidden in Windows Home, a user might forget they enabled the rule months later. When a new application fails to install or a system update breaks, they are left with no visible explanation or easy way to toggle the protection off.

ASR is a user-mode defense that is "less robust" than Core Isolation; it can be deactivated by malware or fail if the Antivirus engine is tampered with.

In short, if you can't lock the Vault (Core Isolation), you are forced to rely on the Doorman (ASR), but for a Home user, that doorman is invisible, difficult to talk to, and prone to locking you out of your own house, unless you use a third-party GUI tool like Andy Ful’s Hard_Configurator.