BYOVD Research: Bypassing Hardware-Gated Drivers – Detection & Mitigation | Security Arsenal

For years, security practitioners have operated under a reasonable assumption: if a vulnerable kernel driver requires specific hardware (e.g., a gaming motherboard controller, a specific Wi-Fi card) to function, the risk is effectively contained to environments possessing that hardware. New research titled "Making Vulnerable Drivers Exploitable Without Hardware" completely dismantles that defense-in-depth premise.

The analysis demonstrates a method to interact with Windows kernel mode drivers from user mode without the associated hardware present. This effectively removes the "hardware-gated" protection for countless drivers. For a Red Teamer or threat actor, this is a force multiplier for Bring Your Own Vulnerable Driver (BYOVD) attacks. They no longer need to hunt for a target with specific hardware; they simply need the driver file and a mechanism to load it.

Defenders must immediately shift their posture. We cannot rely on hardware absence as a mitigation. If a vulnerable signed driver exists in your environment or can be dropped and loaded, it is exploitable.

Technical Analysis

The Mechanics of the Bypass

Windows kernel drivers communicate with user-mode applications via Input/Output Controls (IOCTLs). Historically, researchers deemed many IOCTLs "unreachable" because the driver's DriverEntry or subsequent initialization routines would fail if they could not detect the specific physical device (e.g., via ACPI or PCI queries).

This research highlights a flaw in that assumption:

Driver Loading Persistence: Even if the hardware is missing, many drivers still load into memory and create device objects (\Device\DriverName).
IOCTL Handling: The handlers for the vulnerable IOCTLs often exist in memory and are callable, regardless of the hardware initialization state.
User-Mode Interaction: By leveraging the Windows API CreateFile to open the device handle and DeviceIoControl to send specific buffers, an attacker can trigger the vulnerable code path directly.

Affected Products and Platforms

Platform: Microsoft Windows (Kernel Mode)
Scope: Affects a wide range of 3rd party kernel drivers previously thought "safe" due to hardware dependencies.
Attack Vector: BYOVD (Bring Your Own Vulnerable Driver)

Exploitation Status

Status: Theoretical/PoC Stage (based on recent publication)
Impact: High. This technique lowers the barrier to entry for kernel-level exploitation, allowing attackers to disable security controls (EDR/AV) by leveraging any vulnerable signed driver, not just those compatible with the target's existing hardware.

Detection & Response

Detecting BYOVD attacks is notoriously difficult because the drivers are often legitimately signed by trusted vendors (e.g., Dell, ASUS, MSI). However, the behavioral context—loading a driver without associated hardware or a legitimate installer—provides high-fidelity detection logic.

SIGMA Rules

The following Sigma rules focus on detecting the loading of known vulnerable drivers frequently used in these research contexts and the anomalous loading of drivers by non-system processes.

YAML

---
title: Potential BYOVD - Loading of Known Vulnerable Drivers
id: 8a4c3f12-1b2d-4a5e-9c6d-1e2f3a4b5c6d
status: experimental
description: Detects the loading of kernel drivers known to be used in BYOVD attacks and recent vulnerability research. While signed, these are often loaded by adversaries to disable security controls.
references:
 - https://github.com/magicsword-io/LOLDrivers
 - https://thehackernews.com/2026/05/making-vulnerable-drivers-exploitable.html
author: Security Arsenal
date: 2026/05/15
tags:
 - attack.privilege_escalation
 - attack.t1068
 - attack.defense_evasion
 - attack.t1562.001
logsource:
  category: image_load
  product: windows
detection:
  selection:
    ImageLoaded|endswith:
      - '\RTCore64.sys'
      - '\dbutil_2_3.sys'
      - '\AsIO3.sys'
      - '\AsIO2.sys'
      - '\gdrv.sys'
      - '\mhyprot2.sys'
  condition: selection
falsepositives:
  - Legitimate use of hardware utilities (e.g., MSI Afterburner) by administrators
level: high
---
title: Anomalous Kernel Driver Load by User Process
id: 9b5d4e23-2c3e-5b6f-0d7e-2f3a4b5c6d7e
status: experimental
description: Detects when a kernel driver (.sys) is loaded by a process that is not a standard service host (services.exe) or installer (msiexec.exe), indicating potential manual BYOVD exploitation.
references:
 - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/05/15
tags:
 - attack.privilege_escalation
 - attack.t1068
logsource:
  category: image_load
  product: windows
detection:
  selection:
    ImageLoaded|endswith: '.sys'
    Image|endswith:
      - '.exe'
    Signed: 'false'
  filter:
    Image|endswith:
      - '\services.exe'
      - '\svchost.exe'
      - '\msiexec.exe'
      - '\dllhost.exe'
      - '\rundll32.exe'
  condition: selection and not filter
falsepositives:
  - Rare custom driver installations
level: medium

KQL (Microsoft Sentinel / Defender)

This KQL query hunts for driver load events where the signer is a known hardware vendor, but the loaded driver is a known vulnerable LOLBin (LOLDriver) or loaded by a suspicious parent process.

KQL — Microsoft Sentinel / Defender

DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName endswith ".sys"
| where isnotempty(Signer)
// Focus on 3rd party non-Microsoft drivers
| where Signer !contains "Microsoft Windows"
// Look for known vulnerable drivers often cited in BYOVD research
| where FileName in~ ("RTCore64.sys", "dbutil_2_3.sys", "AsIO.sys", "gdrv.sys", "mhyprot2.sys")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFolderPath, FileName, FolderPath, SHA256, Signer
| order by Timestamp desc

Velociraptor VQL

Use this artifact to hunt for the presence of these vulnerable driver files on the endpoint filesystem, even if they are not currently loaded.

VQL — Velociraptor

-- Hunt for known vulnerable driver files on disk
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs="C:/Windows/System32/drivers/**/*")
WHERE Name =~ "(RTCore64|dbutil_2_3|AsIO|gdrv|mhyprot2)"
  OR Name =~ "(.*\.sys)"
-- Add additional logic here to check specific hashes if available

Remediation Script (PowerShell)

This script checks the registry for the presence of known vulnerable services (drivers) and disables them if found. It acts as a temporary remediation while vendor patches are sought.

PowerShell

# Remediation Script: Disable Known Vulnerable Drivers
# Run as Administrator

$VulnerableDrivers = @(
    "RTCore64",
    "dbutil_2_3",
    "AsIO3",
    "AsIO2",
    "gdrv",
    "mhyprot2"
)

$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Services"

Write-Host "[+] Scanning for vulnerable drivers..." -ForegroundColor Cyan

foreach ($Driver in $VulnerableDrivers) {
    $Path = Join-Path -Path $RegistryPath -ChildPath $Driver
    
    if (Test-Path $Path) {
        Write-Host "[!] Found vulnerable driver service: $Driver" -ForegroundColor Red
        
        # Get current Start value
        $StartValue = (Get-ItemProperty -Path $Path -Name "Start" -ErrorAction SilentlyContinue).Start
        
        if ($null -ne $StartValue) {
            Write-Host "    Current Start Type: $StartValue" -ForegroundColor Yellow
            
            # Disable the driver (Start = 4)
            try {
                Set-ItemProperty -Path $Path -Name "Start" -Value 4 -Force
                Write-Host "    Action Taken: Driver Disabled (Start set to 4)." -ForegroundColor Green
            } catch {
                Write-Host "    Error: Failed to disable driver. $_" -ForegroundColor Red
            }
        }
    } else {
        Write-Host "[-] Driver $Driver not found." -ForegroundColor Gray
    }
}

Write-Host "[+] Scan complete." -ForegroundColor Cyan
Write-Host "[!] Recommendation: Reboot the system to unload active vulnerable drivers." -ForegroundColor Yellow

Remediation

Driver Blocklisting: Ensure the "Vulnerable Driver Blocklist" feature is enabled in Windows (controlled via CI/Policy). This is Microsoft's primary defense against known vulnerable drivers.
HVCI (Hypervisor-Protected Code Integrity): Enable Memory Integrity (Core Isolation) on all endpoints. HVCI prevents the loading of vulnerable drivers that fail Microsoft's signing requirements, even if they possess a valid signature.
Vendor Coordination: Identify specific vulnerable drivers in your environment using the script above. Reach out to the respective hardware vendors for updated, fixed versions.
Application Control: Implement Microsoft Defender Application Control (WDAC) policies that strictly forbid the loading of non-whitelisted drivers.
Remove Unnecessary Hardware Drivers: Audit driver stores and remove drivers for hardware no longer present in the environment to reduce the attack surface.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub

BYOVD Research: Bypassing Hardware-Gated Drivers – Detection & Mitigation