Understanding BYOVD (Bring Your Own Vulnerable Driver) Attacks

During a recent incident response engagement, I observed a sophisticated threat actor utilizing a signed Dell driver (dbutil_2_3.sys) to terminate an EDR agent's kernel-mode callbacks. This was not a zero-day exploit in the traditional sense; the driver was legitimate and digitally signed by a trusted vendor. However, it contained a known vulnerability (CVE-2021-21551) that allowed the attacker to write to arbitrary kernel memory. This technique, known as Bring Your Own Vulnerable Driver (BYOVD), has become a primary choice for ransomware groups and APTs like Lazarus and BlackByte.

What is BYOVD and Why is it Rising?

BYOVD is a post-exploitation technique where an attacker, having already gained administrative privileges, installs a legitimate but vulnerable third-party driver. Because the driver is signed by a valid Certificate Authority (CA), Windows Kernel Mode Code Signing (KMCS) allows it to load without suspicion. Once loaded, the attacker exploits the driver's vulnerabilities to execute code with Ring 0 privileges. This bypasses the security boundaries between user mode and kernel mode, rendering many user-mode security products ineffective.

We are seeing a surge in BYOVD attacks because modern EDR and XDR solutions have become highly effective at detecting user-mode activity. To evade detection, attackers must go "underneath" the security software. By operating in the kernel, they can disable filesystem filters, process notification callbacks, and registry filters that security tools rely on for telemetry. In the Indian context, we have noted that many manufacturing units using legacy industrial controllers are particularly vulnerable, as their systems often require older, vulnerable drivers to interface with hardware.

How Attackers Exploit Legitimate Signed Drivers

The exploitation process usually involves a driver that exposes a "Mapping IOCTL" (Input/Output Control) or a "Memory Read/Write IOCTL" to user-mode applications without proper access control. I have analyzed several samples where the driver didn't check if the calling process had appropriate permissions, a risk often mitigated by implementing secure SSH workflows to prevent initial unauthorized access. An attacker can send a specially crafted IOCTL request to the driver's device object, instructing it to overwrite a specific kernel address. This is often used to nullify the PspSetCreateProcessNotifyRoutine array, effectively blinding the EDR to new process creations.

The Impact of Kernel-Level Compromise

A kernel-level compromise is the "game over" scenario for Windows security. Once an attacker has stable execution in Ring 0, they can:

• Disable PatchGuard (Kernel Patch Protection) temporarily to modify kernel structures.
• Directly manipulate the EPROCESS structures to hide processes from the Task Manager and security APIs.
• Modify the access tokens of their own processes to escalate to NT AUTHORITY\SYSTEM.
• Inject code into protected processes like lsass.exe to dump credentials without triggering standard alerts.

---

The Mechanics of a BYOVD Attack Vector

Bypassing Windows Kernel Mode Code Signing (KMCS)

KMCS is designed to ensure that only signed drivers can be loaded into the kernel. However, KMCS only validates the digital signature's integrity; it does not validate the driver's security posture. Attackers leverage this by bringing a driver that was signed years ago but never revoked. Since the signature is still valid, the Windows loader (ntoskrnl.exe) accepts it. This effectively turns a security feature into a delivery mechanism for kernel exploits.

Escalating Privileges from User Mode to Kernel Mode

The transition from user mode to kernel mode is the critical step. In the case of CVE-2024-21338, which I monitored closely during its exploitation by the Lazarus Group, the attackers targeted the appid.sys driver. By exploiting a 0-day in this specific driver, they achieved an arbitrary pointer decrement. This allowed them to manipulate kernel objects and gain a kernel-mode execution primitive. The shift from an admin-level user to a kernel-level operator is often achieved in milliseconds, leaving little time for automated response.

Common Vulnerable Drivers Used in Recent Campaigns

Several drivers have become "staples" in the attacker's toolkit. We frequently see the following in forensic images:

• RTCore64.sys (MSI Afterburner): Used by the "EDRSandblast" tool to map kernel memory into user space.
• dbutil_2_3.sys (Dell): Exploited by the "Terminator" tool to kill protected security processes.
• GDRV.sys (Gigabyte): Frequently used in ransomware deployments (e.g., RobinHood) to bypass driver signature enforcement.
• ene.sys (Ene Technology): Often found in gaming laptops, used for RGB control but contains read/write primitives.

---

Primary BYOVD Defense: Prevention and Hardening

Defending against BYOVD requires a shift from reactive detection to proactive hardening. The goal is to prevent the vulnerable driver from ever reaching the "Running" state.

Enabling Hypervisor-Protected Code Integrity (HVCI)

HVCI, often referred to as "Memory Integrity" in the Windows UI, is the most robust defense against kernel-mode exploits. HVCI uses the Windows Hypervisor to create an isolated environment (VBS - Virtualization-based Security). It ensures that kernel memory pages are only made executable if they have passed integrity checks. This prevents an attacker from using a driver exploit to write code into a kernel page and then executing it. I recommend verifying HVCI status via PowerShell across the fleet:

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName MSFT_DeviceGuardState | Select-Object -ExpandProperty SecurityServicesRunning

If the output does not include the value "2", HVCI is not active. You can force-enable it via the registry, though I caution that this may cause BSODs on older Indian manufacturing hardware that relies on non-compliant drivers. Use the following command for targeted testing:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 1

Implementing the Microsoft Vulnerable Driver Blocklist

Microsoft maintains a blocklist of drivers known to have vulnerabilities. In Windows 11 and recent versions of Windows 10, this is enabled by default if HVCI is on. However, for many enterprise environments I have audited, this feature was manually disabled or remained inactive due to legacy group policy settings. You must ensure the blocklist is enforced at the kernel level. Use this command to verify or enable the blocklist:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable /t REG_DWORD /d 1 /f

This registry key instructs the Code Integrity (CI.dll) module to check the hash and attributes of every driver against the internal Microsoft blocklist before allowing it to load.

Configuring Windows Defender Application Control (WDAC)

WDAC is the "gold standard" for driver control. Unlike AppLocker, which primarily targets user-mode binaries, WDAC can enforce strict policies on which drivers are allowed to load. I recommend a "Default Deny" posture where only drivers signed by Microsoft or your organization's internal CA are permitted. Below is a simplified workflow for generating a WDAC policy that includes the vulnerable driver blocklist:

# Generate a new policy based on the Default Windows template
New-CIPolicy -FilePath "C:\Windows\Schemas\CodeIntegrity\ExampleProtocol.xml" -Level Publisher -Fallback Hash
Merge with the Microsoft Vulnerable Driver Blocklist
Merge-CIPolicy -OutputFilePath "C:\WDAC\FinalPolicy.bin" -PolicyPaths "C:\WDAC\BasePolicy.xml","C:\WDAC\VulnerableDriverBlocklist.xml"

For Indian enterprises, particularly those in the BFSI sector compliant with RBI guidelines or the DPDP Act 2023, implementing WDAC is a critical step toward "Reasonable Security Practices." It provides a verifiable audit trail of every driver load attempt, which is invaluable during regulatory audits.

---

Detection Strategies for Driver-Based Threats

Prevention is not foolproof. Attackers may use a "zero-day" vulnerable driver that is not yet on any blocklist. In these cases, we must rely on behavioral detection and telemetry.

Monitoring for Unusual Driver Load Events

Every time a driver is installed or loaded, Windows generates specific event logs. I focus on Windows System Event ID 7045 (A service was installed in the system) and Security Event ID 4697. These events contain the service name, image path, and service type. I look for drivers being loaded from C:\Users\*\AppData\Local\Temp\ or other non-standard locations, which is a common indicator of a BYOVD attack. You can use the pnputil command to audit currently loaded third-party drivers:

pnputil /enum-drivers | findstr /I "Published Name Original Name Provider"

Leveraging EDR and XDR Behavioral Analytics

Modern EDRs should be configured to alert on specific kernel-mode behaviors. I look for "Call Trace" anomalies where a user-mode process directly opens a handle to a driver device object (e.g., \\.\NTPNP_PCI0002) and immediately starts issuing IOCTLs. If the process is cmd.exe or a renamed PowerShell binary, it is highly suspicious. We also monitor for "EDR Unhooking" attempts, where kernel callbacks are removed or patched in memory.

Identifying Indicators of Compromise (IoCs) in System Services

Attackers often give their vulnerable drivers generic or misleading names to blend in. I have seen RTCore64.sys renamed to win_driver.sys or vbox_support.sys. When performing a forensic sweep, I prioritize drivers where the "Original Name" in the version resources does not match the actual filename on disk. This is a classic indicator of masquerading.

---

Proactive Management and Governance

Managing the driver attack surface is an ongoing governance task, not a one-time configuration.

Utilizing the LOLDrivers Project for Threat Intelligence

The Living Off the Land Drivers (LOLDrivers) project is an excellent community-driven resource. I integrate their drivers.json feed into our internal scanning tools. This allows us to identify vulnerable drivers that Microsoft might not have added to their official blocklist yet. We use a simple Python script to compare the hashes of all drivers in C:\Windows\System32\drivers\ against the LOLDrivers database.

import hashlib
import json
def get_file_hash(filepath):     hasher = hashlib.sha256()     with open(filepath, 'rb') as f:         for chunk in iter(lambda: f.read(4096), b""):             hasher.update(chunk)     return hasher.hexdigest()
Example logic to check against a local copy of LOLDrivers
def check_drivers(driver_path, loldrivers_db):     current_hash = get_file_hash(driver_path)     if current_hash in loldrivers_db:         print(f"[!] Warning: Vulnerable driver detected: {driver_path}")

Automating Driver Audits Across the Enterprise

In large-scale environments, manual audits are impossible. We utilize a combination of Osquery and FleetDM to query the driver state across thousands of endpoints. This allows us to identify outliers—drivers that appear on only one or two machines—which often turn out to be the entry point for a BYOVD attack.

Applying the Principle of Least Privilege (PoLP) to Reduce Attack Surface

Loading a driver requires SeLoadDriverPrivilege, which is typically restricted to Administrators. By strictly enforcing the Principle of Least Privilege and removing local admin rights from standard users, you significantly increase the cost of an attack. Utilizing a browser based SSH client for remote server management can help enforce these boundaries by centralizing access without exposing local credentials. An attacker must first find a privilege escalation vulnerability to gain the rights needed to load their vulnerable driver. In India, where "Standard User" accounts are often ignored for the sake of convenience, this single change can reduce the attack surface by 80%.

---

The Future of BYOVD Defense

Microsoft's Evolving Stance on Driver Security

Microsoft is moving toward a model where drivers must be "Windows Hardware Quality Labs" (WHQL) certified and undergo more rigorous automated scanning, aligning with broader OpenSSH security principles of verified code execution. We are also seeing the introduction of "Configurable CI" which allows for more granular control. The long-term goal is to make HVCI a non-negotiable requirement for all hardware, effectively killing the BYOVD technique for older, unpatched drivers.

The Role of AI in Detecting Zero-Day Driver Exploits

I am currently experimenting with machine learning models that analyze the IOCTL traffic patterns of drivers. Most legitimate drivers have a predictable "fingerprint" of IOCTL codes they receive. BYOVD exploits often involve "fuzzing" or sending high-frequency, anomalous IOCTLs. AI can help identify these patterns in real-time, providing a layer of defense even when the driver itself is unknown to blocklists.

Building a Multi-Layered Defense-in-Depth Architecture

No single tool will stop BYOVD. A successful defense-in-depth strategy must include:

• Hardware Level: TPM 2.0 and Secure Boot enabled to ensure boot-time integrity.
• OS Level: HVCI and the Microsoft Vulnerable Driver Blocklist enabled via GPO/Intune.
• Application Level: WDAC policies to restrict driver loading to trusted publishers.
• Monitoring Level: SIEM ingestion of Event IDs 7045 and 4697 with behavioral alerting.
• Regulatory Level: Compliance with DPDP Act 2023 requirements for securing "Critical Information Infrastructure."

For organizations operating in India, the financial implications of a kernel-level breach are significant. Beyond the immediate recovery costs, which can exceed ₹50 Lakhs for a medium-sized enterprise, the legal ramifications under the new data protection laws make BYOVD defense a boardroom priority. We must move away from the mindset that "if it's signed, it's safe."

Next technical step: Execute the following to check for drivers that are currently running but not signed by Microsoft, which often helps identify candidates for your initial WDAC blocklist:

Get-WindowsDriver -Online -All | Where-Object { $_.ProviderName -ne "Microsoft" } | Select-Object ClassName, ProviderName, Driver