Threat actors are increasingly utilizing the Bring-Your-Own-Vulnerable-Driver (BYOVD) technique to neutralize security products within targeted networks. This method involves introducing a legitimate, signed. But known to be vulnerable—driver onto a system. By exploiting this driver, unauthorized parties gain kernel-level access, allowing them to terminate security monitoring processes before deploying further unauthorized software, such as ransomware or data exfiltration tools.
The growing prevalence of tools designed to suppress Endpoint Detection and Response (EDR) agents highlights a complex challenge for operating system vendors. While Microsoft has implemented significant measures to secure the Windows kernel over the last two decades, the requirement for backward compatibility creates persistent security gaps.
The Architecture of Driver Trust
The core of the issue lies in how operating systems manage hardware communication. Drivers function at "ring 0," the highest privilege level, to support interaction between software and hardware. To ensure stability, Windows requires kernel drivers to be signed with digital certificates from a trusted Certificate Authority (CA).
However, validating these certificates during the boot process presents a technical hurdle. Windows loads drivers before network services are fully active. Consequently, the operating system cannot query Certificate Revocation Lists (CRLs) in real-time. Implementing such checks during startup would significantly degrade performance and could introduce instability if network connections are unavailable.
This architectural constraint means that if a driver was signed with a valid certificate at the time of issuance, the OS may continue to trust it even after the certificate has been revoked by the vendor.
The Backward Compatibility Exception
To support the vast ecosystem of legacy hardware and software running on Windows, Microsoft enforces a specific policy regarding driver signatures. While Windows 10 and later versions require new kernel drivers to be signed through the Microsoft Hardware Dev Center, an exception exists for older drivers.
Drivers signed with certificates issued prior to July 29, 2015, that chain to a supported cross-signed CA, are permitted to load. This policy ensures that older hardware remains functional but also permits the loading of drivers with known vulnerabilities or revoked certificates.
This gap was demonstrated in a recent security incident documented by Huntress. Threat actors leveraged a driver associated with EnCase, a digital forensics suite. Although the driver’s certificate expired in 2010 and was subsequently revoked by the vendor, the driver could still be loaded on modern systems. This allowed the threat actors to bypass Driver Signature Enforcement and terminate security agents.
Jakub Souček, a senior malware researcher at ESET, notes the inconsistency in this behavior. He argues that a revoked certificate signals a clear intent from the vendor that the code is no longer safe for use, suggesting such drivers should be barred from loading regardless of legacy status.
Challenges with Blocklisting
To mitigate these risks without breaking compatibility, Microsoft maintains a Vulnerable Driver Blocklist. This feature, enabled by default since the Windows 11 2022 update, prevents the OS from loading specific drivers known to be exploited.
While effective in principle, the implementation faces practical limitations:
Update Frequency: The blocklist is updated infrequently. Typically once or twice a year—leaving a window where newly identified vulnerable drivers remain usable by threat actors.
Operational Impact: Blocking a driver globally requires careful consideration. Souček notes that for many vulnerable drivers, legitimate usage accounts for 80% to 90% of observed activity.
Peter Morgan, vice president of research at Halcyon, points out that Microsoft must balance security against the risk of catastrophic failure in critical sectors. For example, blocking a driver used by legacy medical equipment could disrupt healthcare operations. This necessitates a high threshold for adding a driver to the global blocklist.
Strengthening Defenses
While the ecosystem challenges are complex, organizations can take proactive steps to reduce their exposure to BYOVD techniques.
Reduce the Attack Surface Researchers advocate for stricter application of the Vulnerable Driver Blocklist. Anna Pham, senior hunt and response analyst at Huntress, suggests that cloud-based, real-time updates. Similar to antivirus definitions—could narrow the window of opportunity for threat actors.
Validate Driver Usage Dick O’Brien of the Symantec and Carbon Black Threat Hunter Team suggests that future OS improvements could enforce policies where only the original, intended application is permitted to load its associated driver. This would prevent unauthorized tools from repurposing legitimate drivers for malicious ends.
Immediate Configuration Changes For current defense, security teams should focus on available controls:
Enable HVCI: Turning on Hypervisor-protected Code Integrity (HVCI) ensures that the Vulnerable Driver Blocklist is enforced by the Windows kernel.
Deploy WDAC: implementing Windows Defender Application Control (WDAC) allows organizations to apply Microsoft’s recommended driver block rules more strictly than the default OS policy.
Secure Remote Access: Since BYOVD is often a post-intrusion technique, preventing initial access is critical. Enforcing multifactor authentication (MFA) on VPNs and remote access points reduces the likelihood of an intruder reaching the stage where they can deploy driver-based evasion tools.
By understanding the limitations of default driver enforcement and applying these additional controls, defenders can significantly increase the difficulty for unauthorized parties attempting to tamper with system security.