BYOVD Explained: How Attackers Use Vulnerable Drivers to Bypass Endpoint Security

What Is BYOVD (Bring Your Own Vulnerable Driver)?

BYOVD is an attack technique where adversaries:

• Bring a legitimate but vulnerable kernel driver to a target system
• Load it into the operating system
• Abuse its flaws to perform privileged kernel-mode actions

Unlike traditional malware:

• The driver is real software, not malicious code
• It is often digitally signed, so Windows trusts it
• The vulnerability lies in poorly designed driver functionality, not in Windows itself

Once loaded, the driver runs at Ring 0 (kernel level), which is the highest privilege level in the operating system.

Why Drivers Are So Powerful

Operating systems like Windows separate privileges into layers:

EDR and antivirus products mostly run in user mode, even if they have self-protection mechanisms like:

• Protected Process Light (PPL)
• Tamper protection
• Anti-termination safeguards

A kernel-mode driver can bypass all of these protections.

Why Old or Vulnerable Drivers Still Load

1. Digital Signature Trust

Windows enforces Driver Signature Enforcement (DSE):

• Drivers must be digitally signed to load

However, many old drivers were signed before modern security standards existed. Some legacy drivers:

• Were signed before July 2015
• Have expired or revoked certificates
• Are still accepted by Windows for compatibility reasons

2. Backward Compatibility

To avoid breaking old hardware and enterprise software:

• Windows allows certain legacy signed drivers to load
• Certificate revocation checks are not always enforced at load time

Attackers exploit this trust model.

How Attackers Use BYOVD (Step-by-Step)

Step 1: Initial Access

BYOVD is not usually the first step of an attack. Attackers typically gain access via:

• Stolen VPN credentials
• Phishing
• Exploited remote services
• Weak MFA configurations

Once they have administrator access, they move to driver abuse.

Step 2: Bringing the Vulnerable Driver

The attacker includes a driver that is:

• Legitimate and signed
• Known to expose dangerous IOCTL functions
• Previously used by hardware vendors, forensic tools, or system utilities

Examples historically abused include: Forensic drivers, Hardware monitoring drivers, Debug or memory access drivers.

The driver is often:

• Embedded inside a malware loader
• Dropped to disk with benign-looking filenames
• Timestamped to look old and legitimate

Step 3: Loading the Driver

Attackers load the driver by:

• Writing it to disk (for example, C:\Windows\System32\drivers\)
• Creating a Windows service entry for the driver
• Starting the service, which loads the driver into kernel memory

This requires administrator privileges, which attackers typically already have at this stage. Because the driver is signed, Windows allows it to load.

Step 4: Abusing the Driver

Once loaded, attackers interact with the driver using IOCTL (Input/Output Control) requests. Poorly designed drivers may allow:

• Arbitrary process termination
• Kernel memory read and write
• Disabling callbacks and protections
• Access to physical memory
• Bypassing Protected Process Light (PPL)

Using these capabilities, attackers can:

• Kill EDR and AV processes
• Disable security services
• Blind monitoring and logging tools

This phase is often called an EDR killer stage.

Step 5: Follow-On Attack

With endpoint protection disabled, attackers can safely:

• Deploy ransomware
• Steal credentials and data
• Establish persistence
• Move laterally across the network

At this point, the attack becomes much harder to detect or stop.

Why BYOVD Is Increasing

Several factors have made BYOVD popular:

• High Reliability: Works across many Windows versions and does not rely on zero-day exploits.
• Low Detection: Uses legitimate signed drivers, so no exploit payloads or shellcode are required.
• Reusability: The same vulnerable driver can be reused in many campaigns.
• EDR Evasion: Directly targets security tools instead of trying to evade them.

As a result, BYOVD has been adopted by ransomware groups, initial access brokers, and advanced persistent threat (APT) actors.

Platforms Affected

Although most public cases focus on Windows, the concept applies broadly:

• Windows: Most common due to the size of the driver ecosystem
• Linux: Kernel module abuse is possible with misconfigurations
• macOS: Kernel extensions (KEXTs) have been abused historically, though protections have improved

How Organizations Can Defend Against BYOVD

1. Enable Vulnerable Driver Blocklists: Microsoft maintains a known vulnerable driver blocklist. Works best when Memory Integrity (HVCI) is enabled.
2. Enforce Driver Control Policies: Use Windows Defender Application Control (WDAC) to allow only approved drivers.
3. Monitor Driver Load Events: Watch for new or unexpected .sys files, drivers loaded outside normal software installations, and drivers associated with forensic or hardware tools not used in your environment.
4. Harden Initial Access: Enforce MFA on VPNs and remote access, patch internet-facing services, and monitor for credential abuse.
5. Defense in Depth: Combine endpoint security, identity protection, and logging. Monitor for signs of EDR tampering.
6. Add alerting for when an EDR solution stops sending telemetry. This is a critical signal that tampering may have occurred.

Key Takeaways

• BYOVD is not malware. It is abuse of trust.
• Old, signed drivers can provide attackers with kernel-level control.
• This technique allows attackers to disable EDR and AV reliably.
• BYOVD is now a mainstream tactic in ransomware and targeted attacks.
• Defense requires driver control, monitoring, and strong access security.

Vulnerable Drivers Seen in 2025–2026 Campaigns

This table provides a reference of vulnerable kernel drivers that were documented or observed as abused in 2025–2026 (BYOVD candidates and those seen in real attacks). This is not exhaustive, but it collects the drivers and CVEs that security reporting and incident responders called out during 2025–2026.

Hunting for Drivers

1. Start With the Attacker Kill Chain

BYOVD rarely happens in isolation. Most attacks follow this pattern:

1. Initial access (VPN, phishing, exposed service)
2. Privilege escalation to administrator
3. Suspicious driver dropped
4. Kernel driver loaded
5. Security tools disabled
6. Payload deployment (ransomware, C2, exfiltration)

Threat hunting should focus on steps 3–5, where mistakes are most visible.

2. Hunt for Suspicious Driver Files

What to Look For: Drivers (.sys files) appearing in unusual contexts:

• Written outside of standard installation workflows
• Dropped by scripting engines or unsigned binaries
• Copied into System32\drivers manually

High-Signal Locations:

• C:\Windows\System32\drivers\
• C:\Windows\Temp\
• C:\ProgramData\
• C:\Users\Public\

Suspicious Characteristics:

• Driver filenames mimicking legitimate vendors
• Very old compile timestamps (2005–2012)
• No associated installed software
• Drivers appearing shortly before EDR failures

Hunting Questions: Why was this driver installed? Which process wrote it to disk? Is it part of approved hardware or software?

3. Hunt for Unexpected Driver Loads

Windows Events to Monitor:

• Service creation events (new kernel driver services)
• Driver load events (kernel module loaded)
• Code integrity logs (blocked or audited driver loads)

High-Risk Indicators:

• Drivers loaded outside maintenance windows
• Forensic, debugging, or hardware drivers on endpoints
• Drivers loaded shortly after VPN logins or privilege escalation

Threat Hunting Tip: Create a baseline of normal drivers in your environment. Anything outside that list deserves investigation.

4. Hunt for Security Tool Tampering

BYOVD is often used as an EDR killer.

Indicators of Driver-Based EDR Killing:

• Multiple security services stopped in seconds
• AV/EDR processes terminated despite tamper protection
• Kernel callbacks suddenly disappearing
• EDR reporting “agent unhealthy” or “sensor offline”

Hunting Query Ideas:

• Security processes exiting with abnormal exit codes
• Service stop events for multiple vendors in short time windows
• Endpoint protection disabled without user interaction

These are late indicators, but still valuable for correlation.

5. Hunt for Driver Installation via Non-Standard Processes

High-Risk Parent Processes: Driver installation triggered by:

• powershell.exe
• cmd.exe
• wmic.exe
• mshta.exe
• Custom loaders or unknown executables

Why This Matters: Legitimate drivers are usually installed by vendor installers, Windows Update, or hardware setup utilities. Anything else is suspicious.

6. Hunt for Known Vulnerable Driver Artifacts

Common Patterns in BYOVD Campaigns: Reused vulnerable drivers, slightly renamed .sys files, vulnerable drivers embedded in malware loaders.

What to Do: Maintain a rolling list of known-abused drivers and hunt by original driver names, exported function names, IOCTL patterns, and file metadata, not just hashes.

7. Hunt for IOCTL Abuse (Advanced)

This is harder, but high value. BYOVD drivers expose IOCTL interfaces that kill processes, read/write kernel memory, or disable protections.

Detection Options: Kernel telemetry, driver communication anomalies, EDR kernel-level behavioral alerts, sudden termination of protected processes after driver load. This is typically Tier 3 / advanced hunting.

8. Correlate with Identity and Access Signals

BYOVD requires admin access.

High-Confidence Correlations: VPN login → admin token → driver load; Privilege escalation → driver install within minutes; Local admin account created shortly before driver load. If these appear together, escalate immediately.

9. Sample Hunting Hypotheses

Use hypotheses to guide hunts: “An attacker loaded a legacy signed driver to disable EDR,” “A driver was installed without a legitimate business purpose,” “A vulnerable driver enabled termination of protected processes.” Good threat hunting is question-driven, not alert-driven.

10. Detection vs. Prevention Reality

BYOVD often succeeds because prevention controls are misconfigured, not because they don’t exist.

11. When to Escalate Immediately

Escalate to incident response if you find: unknown driver loaded + security tools failing; driver loaded after VPN login + privilege escalation; legacy driver with process-kill capability; multiple endpoints showing similar driver artifacts. BYOVD usually indicates hands-on-keyboard activity, not commodity malware.

Final Takeaways for Threat Hunters

• Hunt the driver, not the malware
• Look for why a driver exists, not just what it is
• BYOVD leaves fewer artifacts but higher-impact ones
• Early detection is possible before ransomware deployment
• Driver telemetry is now a core hunting data source