BLOG | THREAT INTEL

The feature that stops BYOVD (bring your own vulnerable driver)

Subscribe

By Brandon Overstreet

July 23, 2026  •  6 minute read



Placeholder image for The feature that stops BYOVD (bring your own vulnerable driver)

TL;DR

  • Driver blocklists can’t win against BYOVD. The blocklists only block drivers already known to be bad, and The Gentlemen’s GentleKiller framework was purpose-built to exploit exactly that gap using obscure, legitimately signed drivers.
  • Windows Defender Application Control (WDAC/App Control for Business) is the feature that structurally closes this gap. The feature flips the security model from “block known bad” to “allow known good,” so an unrecognized driver fails to load by default.
  • Active Directory/Group Policy is a native, supported channel for deploying WDAC fleet-wide, with a phased audit enforce rollout that avoids the outages that make allowlisting projects stall.
  • Pairing WDAC with Hypervisor-Protected Code Integrity (HVCI) extends this protection to the kernel itself, and is the direct structural countermeasure to BYOVD.

 

Bring your own vulnerable driver (BYOVD) attacks work because defenders have been playing Whac-A-Mole. Attackers only need to find one signed driver that isn’t on the blocklist yet, and that pool of legacy, consumer, and niche enterprise drivers on the internet is effectively unbounded. The Gentlemen’s GentleKiller framework demonstrates this at scale, with each attack impersonating a trusted vendor, while loading a different obscure driver underneath. The fix isn’t a better list, but rather a different default. Windows Defender Application Control (WDAC) enforces a deny-by-default model where only explicitly approved drivers and applications can load, and Active Directory gives us a proven, auditable path to deploy it across the environment without needing to predict which driver the next attacker will find.

 

Resilience in detail

Why the gap exists

A blocklist, including Microsoft’s own Vulnerable Driver Blocklist, can only enumerate drivers already known to be exploitable. Microsoft updates it on a fixed cycle, but attackers can weaponize a newly disclosed POC (proof-of-concept) within days. As long as we mistake a cryptographic signature for a security validation, the inventory of legacy or niche drivers on the internet remains an open source library of pre-signed exploits.

WDAC/App Control for Business

WDAC (rebranded by Microsoft as App Control for Business) is a built-in Windows security feature that controls exactly which drivers, applications, scripts, and DLLs are permitted to run on a device. It’s enforced at the operating system and kernel level, not just at the user level, which is what makes it strong enough to govern driver loading instead of just managing application launches. Instead of trying to recognize malicious code, WDAC works on an allowlist principle: nothing runs unless it matches a rule in the active policy (by publisher, certificate, hash, filename, or version).

Hypervisor-Protected Code Integrity (HVCI) is a companion feature that uses the CPU’s virtualization capabilities to run Windows code integrity checks inside an isolated, hypervisor-protected environment, separate from the regular kernel. This matters because a compromised or vulnerable kernel driver normally has enough privilege to tamper with the operating system’s own security checks. HVCI moves those checks somewhere the driver can’t reach, so even a successfully loaded vulnerable driver can’t be used to disable the enforcement itself. In practice, HVCI is what lets WDAC’s driver policy hold up against a kernel-level BYOVD attack, rather than just an application-level one.

Two capabilities matter most for BYOVD:

  1. HVCI extends WDAC enforcement into the kernel itself. A signed but vulnerable driver can still be denied to load if it isn’t on the approved policy. This is the direct structural countermeasure to BYOVD.
  2. On Windows 11 and Windows Server 2022+, organizations can deploy a highly restrictive base policy alongside narrow, auditable supplemental policies for legitimate third-party drivers. This ensures allowlisting doesn’t accidentally freeze the development or operational environment.

 

How Active Directory delivers it

Critical note: The deployment example below is modeled after Microsoft’s baseline documentation. However, because every environment is different, the native pathway must be carefully tailored to your organization’s specific structural needs.

AD/Group Policy is one of the natively supported WDAC deployment channels for domain joined fleets with one important limitation: Group Policy only supports the legacy single policy format, not the newer multiple policy/supplemental-policy format. Microsoft’s own documentation is explicit that Windows Management Implementation (WMI) and Group Policy do not currently support multiple policies, so a Great Policy Object (GPO) delivered policy is always a single, complete base policy rather than a base plus supplemental combination.

The steps below outline the process for taking an authored WDAC policy and deploying it domain-wide via Group Policy to ensure full enforcement across target endpoints:

  1. Author the policy as XML, convert to binary (.cip/SiPolicy.p7b).
  2. Link a dedicated GPO to a test OU first.
  3. Group Policy delivers the compiled policy to %windir%\System32\CodeIntegrity\SiPolicy.p7b.
  4. Use security group filtering to control exactly which machines get which policy.

One operational caveat: for new signed base policies on HVCI-enabled systems, Microsoft documents a known issue where GPO delivered updates don’t reliably activate without a reboot, so in that case, you should deploy new signed base policies via script with a forced restart in that case.

The rollout path
Phase Action

0–Baseline

 Run WDAC in Audit mode on a pilot OU; harvest CodeIntegrity logs (Event ID 3076/8038) to see what actually loads

1–Build base policy

 Start from a Microsoft template; add legitimate line-of-business software as supplemental policies

2–Expand audit

 Broaden ring by ring (pilot → business unit → org-wide) via GPO security group targeting

3–Enforce, narrow first

 Flip to Enforced mode on domain controllers and privileged-access workstations first

4–Enforce broadly + HVCI

 Extend fleet wide; enable HVCI where hardware supports it

5–Sustain

 New software/driver requests go through an exception request workflow instead of waiting on reactive list updates

 

Additional supporting controls

WDAC is the primary fix, but it works best layered with a few other controls that either reduce the attack surface before WDAC even matters, or catch what slips through:

  • Disable legacy driver cross-signing (Windows 11 25H2+/Server 2025+). Systems on kernel build 10.0.26100.32690 and above stop grandfathering in old, non-WHQL approved drivers by default. Windows Hardware Quality Labs (WHQL) is Microsoft’s driver certification program and since Windows 10 1607, vendors must submit drivers to Microsoft for testing and approval before they’re considered valid on modern Windows. Older drivers predating this requirement were historically “grandfathered in” via legacy cross-signing so they’d keep working. Disabling that grandfathering means those old, uncertified drivers simply stop loading. This alone would have blocked the specific legacy driver used in our documented Gentlemen intrusion, with no policy authoring required.
  • Enable virtualization-based security (VBS)/core isolation. VBS is a Windows security feature that uses the CPU’s hardware virtualization capabilities to carve out an isolated memory region, managed by a hypervisor, that runs separately from the main Windows kernel. “Core isolation” is the name of the Windows Settings page where VBS and its related protections are turned on. Because this isolated region sits at a higher trust level than the kernel itself, even a fully compromised kernel driver can’t tamper with whatever security logic Windows chooses to run inside it. This creates a hypervisor-enforced privilege boundary that protects sensitive kernel code, even in the presence of a vulnerable driver. Two sub-features matter most:
    • Memory integrity/kernel Control Flow Guard (kCFG) is one of the protections VBS enables. Normally, once attacker code gains kernel privileges, it can redirect the kernel’s execution flow to run its own malicious shellcode. kCFG maintains a hypervisor-protected list of legitimate call targets and blocks any attempt to jump to code that isn’t on that list. So even with kernel-level access, an attacker’s injected shellcode simply can’t be called.
    • Credential guard acts as the ultimate safety net for enterprise identity. Because it isolates high-value credentials (like NTLM hashes and Kerberos tickets) inside a hypervisor-protected VBS container, it breaks the primary objective of a kernel breach. Even if an attacker abuses local administrator privileges to successfully execute a BYOVD attack and compromise the Windows kernel, they remain architecturally locked out of the isolated credential store.
  • Keep the native Vulnerable Driver Blocklist enabled. Microsoft only updates it quarterly and will miss newly discovered drivers by definition, but it costs nothing to leave on and catches the drivers it does know about.
  • Enable ASR rule “Block abuse of exploited vulnerable signed drives.” This is Microsoft Defender Attack Surface Reduction rule (GUID 56a863a9-875e-4185-98a7-b882c64b5ce5). It’s worth noting that it prevents an application from writing known vulnerable signed drivers to disk, but it doesn’t block a driver that’s already present on the system from loading.
  • Supplement with loldrivers.io. This is a more frequently updated, community-maintained list than Microsoft’s native blocklist. It doesn’t integrate directly with Windows, so enforcing it requires either custom detection rules or a WDAC deny policy referencing it.
  • Last-resort detection for systems that can’t run WDAC (pre-Windows 10 1709). Add known bad driver filenames, device names, and product description strings to your security tooling’s detection ruleset.

Layered together, these controls narrow the BYOVD attack surface at every point WDAC doesn’t fully cover: fewer legacy drivers are even eligible to load, kernel tampering is harder even if one does, and there’s still a safety net for older systems that can’t run WDAC at all.

Ultimately, WDAC is the definitive solution to the BYOVD threat. By deploying it you eliminate the need to chase down every new, obscure driver an attacker might discover if it isn’t explicitly approved, it simply won’t load. This is a highly structured, practical initiative managed through a pilot OU, audit mode, and a ring-based rollout—not an endless Whac-A-Mole game.

 

References

 

Blog home