BYOVD Attacks: Bringing Vulnerable Drivers to Ring 0 and How to Defend

Bring Your Own Vulnerable Driver (BYOVD) is no longer a theoretical red-team trick — it has become a practical, high-impact play in real-world intrusions that turns Windows’ own trust model into an offensive asset. Over the past two years operators from commodity ransomware groups to nation-state‑level APTs have repeatedly bundled legitimately signed but vulnerable kernel drivers into loaders and weaponized them to escalate privileges, gain arbitrary kernel read/write, terminate endpoint protection, and move unimpeded. The result is an attacker who doesn’t need to forge signatures or deploy unsigned kernel code: they simply bring a trusted driver that contains defects and use it to break into Ring 0.

Background / Overview​

The BYOVD technique — short for Bring Your Own Vulnerable Driver — exploits a simple reality: many third‑party drivers are shipped with kernel‑mode functionality that, if implemented without strict access checks, can be abused by any local user or process that can trigger the driver’s IOCTL interface. Historically these drivers were created to enable low‑level hardware control (fan and RGB control, hardware monitoring), anti‑cheat systems for games, or utility features that require privileged access. When vendors fail to constrain calls or validate inputs, a signed driver becomes a backdoor to the kernel.
What makes BYOVD especially dangerous today is the convergence of several factors:

• A steady supply of signed drivers with legacy compatibility behavior or incomplete security checks.
• Attackers able to obtain local administrator rights (phishing, credential theft, exposed RDP, bought access).
• Incomplete or reactive vendor and OS blocklists that lag real‑world exploitation.
• Techniques that evade simple hash‑based blocking or signature revocation by preserving a valid digital signature while changing file-level attributes.

In short: adversaries are weaponizing trusted components — not forging them.

---

How BYOVD attacks unfold: step‑by‑step​

BYOVD is not an initial access vector; it is an escalation and defense-evasion technique that an attacker runs after gaining a foothold. The basic execution flow is concise and repeatable:

• Attacker obtains local administrative rights through phishing, credential theft, exploitation of exposed services, or purchased access from an initial access broker.
• The attacker drops a signed-but-vulnerable kernel driver (.sys) and often a small companion loader into writable locations (for example, C:\Windows\Temp or C:\Users\Public).
• The driver is registered and loaded with legitimate OS mechanisms — typically via the Service Control Manager (sc.exe create / sc.exe start) or programmatically through NtLoadDriver.
• Once loaded into kernel space, the driver’s exposed IOCTLs or device interfaces are invoked (DeviceIoControl), leveraging unsafe input handling to perform arbitrary kernel memory read/write or to execute privileged kernel functions.
• With arbitrary kernel read/write (or targeted functions like ZwTerminateProcess), attackers disable EDR/AV callbacks, remove tamper protections, kill security processes, modify process/EPROCESS structures, or hide malicious objects.
• The payload (ransomware, RAT, credential stealers) proceeds with far less risk of interruption.

This sequence is mechanically simple but effective because kernel privileges remove almost all userland protections. Once in Ring 0, attackers can surgically remove the defenders’ ability to detect or block their actions while leaving security software appearing nominally installed.

---

Anatomy of common BYOVD primitives​

• Unsafe IOCTLs: Drivers exposing IOCTLs that accept user‑mode pointers without validating buffer sizes, access rights, or caller context. These become primitives for arbitrary kernel read/write.
• Physical memory mapping: Drivers that allow user mode to map or read physical memory directly are a short path to kernel manipulation.
• Privilege escalation APIs: Some drivers expose functionality originally intended for vendor utilities (e.g., remote device control, monitoring) which can be redirected to perform privileged actions.
• Process termination / ZwTerminateProcess: Abusing kernel privileges to abruptly stop protected security services is a common BYOVD effect used to create a “quiet” window for payload delivery.

---

Case studies: real attacks that moved BYOVD from theory to practice​

Several observed campaigns and high‑profile incidents demonstrate how BYOVD can be used by both mid‑level criminal groups and sophisticated APTs.

Genshin Impact anti‑cheat (mhyprot2.sys) abused in ransomware​

An anti‑cheat kernel driver from the Genshin Impact ecosystem, historically known as mhyprot2.sys, was discovered by defenders being packaged alongside ransomware loaders. The malicious package installed the signed anti‑cheat driver and invoked a companion executable to issue a crafted control code that instructed the driver to terminate antivirus/EDR processes. Because the driver executed at kernel level it was able to call ZwTerminateProcess and other privileged functions, successfully neutralizing protections and clearing the path for mass encryption activities.
This example is emblematic because the anti‑cheat driver was legitimately distributed and signed, and its presence on many systems (gaming installs, preinstalled driver stores) created a widespread, reusable primitive for attackers.

“Silver Fox” and the WatchDog driver (amsdk.sys) used to deliver ValleyRAT​

Security researchers identified a campaign where an operator tracked as Silver Fox embedded a Microsoft‑signed driver (a WatchDog Antimalware module named amsdk.sys) into a loader that disabled security products and deployed a modular backdoor (ValleyRAT). In that case the abused driver was not previously flagged in standard vulnerable‑driver blocklists, and the adversary used a dual‑driver approach — a legacy Zemana driver for older systems and the Microsoft‑signed WatchDog driver for modern Windows 10/11 hosts — to maximize reach.
Notably, researchers observed the attackers adapting to vendor patches by modifying driver timestamps and minimal bytes in a way that preserved Microsoft digital signatures while altering file hashes, undermining simple hash‑based blocklisting. That kind of agility emphasizes how reactive blocklists alone are insufficient for sustained protection.

---

Why Windows’ driver trust model enables BYOVD​

Microsoft’s driver signing and compatibility rules were designed to balance security and ecosystem compatibility. But several structural realities create exploitable gaps:

• Legacy compatibility exceptions: To support legacy drivers and upgraded systems, Windows retains pathways (under certain conditions) that permit older cross‑signed or timestamp‑signed drivers to load — particularly if Secure Boot is disabled or systems were upgraded rather than clean-installed.
• Reactive blocklisting: The Microsoft Vulnerable Driver Blocklist is a defensive control, but it’s inherently reactive: drivers are added only after vulnerabilities are discovered and disclosed, and remediation timelines vary. Attackers exploit that window.
• Signed-but-broken drivers: A valid digital signature assures provenance, not correctness. A signed driver that implements unsafe IOCTLs is still trusted by the OS loader.
• Patch and vendor lag: Even when vendors issue patches or Microsoft adds drivers to blocklists, distribution and adoption lag leave many endpoints exposed for extended periods.

Collectively, these factors let attackers "weaponize" trust instead of subverting it.

---

Defending against BYOVD — layered controls that matter​

BYOVD is a kernel‑level problem and therefore requires defense in depth. There is no single silver‑bullet setting; instead, organizations should adopt a layered strategy that reduces driver attack surface, hardens privilege boundaries, and improves detection.
Key defensive controls:

• Enable Virtualization‑Based Security (VBS) and Hypervisor‑Protected Code Integrity (HVCI)
  VBS/HVCI raises the bar by isolating critical parts of the kernel and protecting code integrity checks within a hypervisor. When configured correctly, HVCI limits the ability of drivers to tamper with protected kernel objects and can prevent some forms of arbitrary kernel patching.
• Enforce Windows Defender Application Control (WDAC) / Application Control Policies
  WDAC (or AppLocker where appropriate) can be used to restrict which drivers and signed packages can be installed. Restrictive policies prevent arbitrary drivers from being accepted simply because they are signed.
• Use and monitor Microsoft’s Vulnerable Driver Blocklist
  Keep the OS and blocklist up to date. Recognize that blocklists are a last line — adopt other controls so you aren’t solely reliant on reactive lists.
• Keep Secure Boot enabled and enforce driver installation policies
  Secure Boot helps prevent the loading of legacy unsigned boot components; retaining it as a default configuration reduces compatibility exceptions that attackers exploit.
• Harden privileged access and reduce administrator use
  BYOVD begins after an attacker obtains local admin rights. Removing unnecessary local admin privileges, enforcing least privilege, and requiring multi‑factor authentication for administrative accounts dramatically reduce the probability that an attacker can bring a driver to disk and register it.
• Audit and remove unnecessary or legacy third‑party drivers
  Periodic driver inventory, removal of unused drivers, and engagement with vendors to confirm driver security posture reduce available primitives.
• Monitor driver load and kernel service creation events
  Instrumentation matters: enable Sysmon driver load event collection (Sysmon Event ID 6), Windows Event ID 7045 (service creation), and other AV/EDR kernel notifications. Create alerts for unexpected driver registration, unusual driver file locations, and creation of unknown kernel services.
• Endpoint controls that detect BYOVD behaviors
  Modern EDR/XDR products are increasingly adding BYOVD detection logic (for example, heuristics to spot suspicious driver loads or attempts to remove kernel callbacks). Work with vendors and configure sensors to apply protections and visibility specifically for driver abuse.
• Continuous validation / breach & attack simulation
  Test your controls actively. Simulating driver‑load abuse and BYOVD techniques in isolated (non‑production) environments highlights gaps and ensures incident playbooks are practical.

---

Practical, prioritized actions for teams (quick checklist)​

• Immediately: Ensure Secure Boot is enabled and local admin accounts require MFA. Inventory currently loaded drivers and triage any known vulnerable drivers (e.g., WinRing0, mhyprot2 variants).
• Within 30 days: Implement Sysmon (or equivalent) with driver-load and service-creation logging enabled. Create alerts for driver loads from non‑standard locations.
• Within 90 days: Deploy WDAC policies for servers and critical endpoints; enable VBS/HVCI on platforms that support it and where compatibility has been validated.
• Ongoing: Maintain vendor engagement, automate driver inventory and patching, and run periodic breach & attack simulation tests covering BYOVD techniques.

---

Detection signals and investigation playbook​

BYOVD exhibits distinct telemetry patterns defenders can hunt for:

• Unexpected driver files in writable or transient locations (Temp, Public folders, user profiles).
• New kernel services registered via Service Control Manager followed by unusual process terminations.
• Sudden disappearance of EDR/AV callbacks or services without corresponding product uninstall events.
• DeviceIoControl calls from userland processes to a kernel device object that weren’t present historically.
• LSASS cloning or credential dumping shortly after a driver load event.
• EDR sensors reporting kernel callback removal or unusual kernel memory writes.

When these signals appear, follow a concise investigative path:

• Quarantine the host from network and isolate to prevent lateral movement.
• Capture kernel and userland forensic artifacts (driver lists, running service list, event logs, Sysmon streams, memory image).
• Identify the driver file hash, file origin, and whether it matches known vendor packages in the driver store.
• Examine the driver for known vulnerable IOCTLs or patterns (if you have binary analysis capability).
• Reconstruct the pre‑ and post‑driver‑load process list to identify killed services and the sequence of operations.
• Hunt for secondary payloads (ransomware encryptors, RAT implants) and credential theft signs.
• If you confirm abuse, remove the driver, restore tamper protections, and remediate credentials and impacted systems.

Be mindful that removing a driver is necessary but rarely sufficient; attackers with kernel access may have installed persistent hooks or modified the system state. Full rebuilds are often the only way to guarantee system integrity after kernel compromise.

---

Limitations and operational tradeoffs​

No mitigation is without cost. Teams must weigh the following tradeoffs:

• Compatibility vs. security: Enabling HVCI and WDAC can break legacy drivers and hardware utilities. Prioritize critical systems and test broadly before enterprise‑wide enablement.
• Performance and manageability: VBS and hypervisor defenses carry CPU/memory overhead and require modern firmware/platform support.
• Reactive nature of blocklists: Relying on signature or hash‑based controls is brittle; attackers can preserve signatures while changing file attributes to evade hash checks.
• Operational burden: Tight driver policies increase helpdesk calls and require an established vendor intake and driver validation process.

Accepting these tradeoffs is part of moving away from implicit trust. The safest posture reduces implicit kernel trust, enforces verification, and accepts that some older vendors will require replacement or strict isolation.

---

The attacker advantage, and how it’s evolving​

The BYOVD threat is maturing. Observed trends include:

• Dual‑driver loaders to reach both legacy and modern Windows builds.
• Timestamp and minimal‑byte mutations that preserve publisher signatures but alter file hashes to evade hash‑based blocklists.
• Tooling that automates driver selection based on host telemetry (OS version, Secure Boot state).
• Integration into commodity ransomware loaders so that even low‑skill operators can neutralize endpoint defences reliably.

Because driver vendors rarely anticipate hostile use cases for privileged interfaces, the long‑term solution must be systemic: better vendor engineering hygiene, stronger driver signing policies combined with proactive vetting, and accelerated sharing of driver hazards across the ecosystem.

---

Policy and procurement recommendations for organizations​

Security teams should treat driver trust like supply‑chain risk. Recommended procurement and policy changes:

• Add driver‑security requirements into vendor contracts: require secure coding practices for kernel code, regular third‑party audits of driver code, and a rapid patching SLA for vulnerability disclosures.
• Maintain a centrally‑managed driver whitelist and prevent ad hoc driver installations via group policy.
• Require driver vendors to publish minimal, well‑documented IOCTL interfaces and to avoid excess privileged functionality where possible.
• Avoid installing consumer‑grade or gaming utilities on enterprise devices; enforce device configuration baselines that exclude unnecessary kernel‑mode components.
• Incorporate driver security checks into onboarding and patch management workflows.

---

Conclusion: defend the kernel as you defend the perimeter​

Bring Your Own Vulnerable Driver attacks expose a hard truth: the kernel is as vulnerable as the code that runs in it, and a valid signature is not a guarantee of safety. As threat actors shift toward re‑using legitimate components, defenders must shift toward assumed untrusted kernels and layered controls. That means enabling virtualization‑backed protections where possible, enforcing strict driver whitelisting, eliminating unnecessary admin privileges, and instrumenting for driver load and kernel tampering events.
BYOVD will remain a practical technique so long as legacy drivers, permissive OS compatibility settings, and reactive blocklists exist. The best defense is a combination of engineering (vendor and platform hardening), policy (least privilege and procurement safeguards), and detection (telemetry‑driven hunting and validation). Treat every signed driver as a potential weapon until proven safe — and continuously test those assumptions through simulation and incident‑response rehearsals.
The attackers brought the drivers; defenders must bring the layering, the telemetry, and the discipline to make those drivers a non‑viable attack vector.

---

Source: eSecurity Planet BYOVD Turns Trusted Drivers Against Windows Security | eSecurity Planet