Listen to this Post
Introduction:
The Bring Your Own Vulnerable Driver (BYOVD) technique is a sophisticated post‑exploitation method where attackers load a legitimate but flawed kernel driver onto a system to gain Ring‑0 privileges, disable security software, and take full control. On May 8, 2026, security researcher Michael H. reported that a vulnerable Lenovo driver—CVE‑2025‑8061—had been added to the LOLDrivers database, reigniting concerns about how easily a signed driver can become an attacker’s weapon. This article explores the anatomy of BYOVD attacks, practical hardening techniques for both Windows and Linux, and how to turn intelligence into effective enforcement.
Learning Objectives:
- Understand the BYOVD attack chain and why it represents the escalation phase of an intrusion, not the beginning
- Learn to detect and block vulnerable driver loads using native Windows tools, WDAC policies, and Sysmon
- Implement prevention engineering strategies—including Linux system hardening and application whitelisting—to reduce the execution surface before attackers can deploy a malicious driver
You Should Know:
- Understanding the BYOVD Attack Chain: From Execution to Kernel Abuse
BYOVD is often misunderstood as the initial breach, but in reality, it typically occurs after an adversary has already achieved code execution, established persistence, and moved laterally. As Michael H. points out, by the time an attacker loads a vulnerable driver to kill security tooling, they have usually already landed execution, abused scripting primitives (LOLBINs), dropped RMM tooling, and moved toward hands‑on‑keyboard operations. The vulnerable driver is the final piece that disables the defenses keeping them out.
Step‑by‑step guide explaining what this does and how to use it:
A typical BYOVD attack unfolds as follows:
- Initial Access: The attacker gains a foothold via phishing, stolen credentials, or a software vulnerability.
- Persistence & Recon: They install backdoors, create scheduled tasks, and map the environment.
- Lateral Movement: Using tools like PsExec or WinRM, they spread across the network.
- Abusing Trusted Utilities: They run PowerShell scripts, WMI commands, or MSBuild to avoid detection (LOLBINs).
- Deploying the Vulnerable Driver: They drop a signed but vulnerable driver (e.g.,
LnvMSRIO.sys) and load it using `sc.exe` or a custom service. - Kernel‑Level Takedown: Exploiting the driver (e.g., via a crafted IOCTL), they terminate EDR processes, unload security hooks, and gain full SYSTEM access.
What does this look like in practice? The vulnerable Lenovo driver (LnvMSRIO.sys version 3.1.0.36) exposed physical memory read/write and MSR manipulation primitives, allowing an attacker to disable core protection mechanisms like HVCI and PPL, and even load an unsigned rootkit via reflective driver loading. The proof‑of‑concept for CVE‑2025‑8061 chains arbitrary physical memory read and write primitives to execute shellcode that steals the SYSTEM token.
Linux/Windows command examples:
Windows: Check which drivers are loaded
driverquery /v
Windows: Load a driver manually (requires elevated privileges)
sc create MyDriver binPath= C:\path\driver.sys type= kernel
sc start MyDriver
Windows: Enumerate loaded modules (PowerShell)
Get-WindowsDriver -Online | Where-Object {$_.Driver -like "LnvMSRIO"}
Linux: List loaded kernel modules
lsmod | grep -i vulnerable
Linux: Check module dependencies
modinfo suspicious_driver.ko
- Detecting Vulnerable Driver Loads with Native Windows Tools
Before you can block BYOVD, you must detect it. Windows offers several built‑in mechanisms to monitor driver loads, and combining them with community‑sourced blocklists dramatically improves your visibility.
Step‑by‑step guide explaining what this does and how to use it:
Enable Sysmon to Log Driver Loads
Sysmon event ID 6 records every driver load, including the driver’s hash, signature, and path. Deploy Sysmon with a configuration that logs all driver loads to your SIEM.
Example Sysmon config snippet (XML):
<Sysmon> <EventFiltering> <DriverLoad onmatch="include"> <Condition>any</Condition> </DriverLoad> </EventFiltering> </Sysmon>
Audit Driver Loads via Group Policy
Navigate to Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → System Audit Policies → System → Audit Driver Load. Enable both success and failure audits. Events appear in the Security log (Event ID 4657 for registry modifications, 5038 for driver load failures).
Query Event Logs for Known Vulnerable Drivers
Use PowerShell to check for any driver that matches the LOLDrivers database:
Get list of known vulnerable drivers from LOLDrivers (requires internet)
$vulnDrivers = Invoke-RestMethod -Uri "https://loldrivers.io/api/drivers.json"
Compare against loaded drivers
Get-WindowsDriver -Online | ForEach-Object {
if ($<em>.Driver -in $vulnDrivers.filename) {
Write-Warning "Vulnerable driver loaded: $($</em>.Driver)"
}
}
Monitor Registry for New Service Installations
Attackers often install a driver as a kernel service. Watch for new entries under `HKLM\SYSTEM\CurrentControlSet\Services` and correlate with driver loads.
Real‑time registry monitoring (PowerShell) Register-WmiEvent -Query "SELECT FROM RegistryKeyChangeEvent WHERE Hive='HKLM' AND KeyPath='SYSTEM\CurrentControlSet\Services'"
- Blocking Unauthorized Drivers with WDAC and Microsoft’s Vulnerable Driver Blocklist
Prevention engineering starts with enforcing “what is allowed” rather than “what is blocked.” Windows Defender Application Control (WDAC) and the Microsoft Vulnerable Driver Blocklist are your frontline defenses.
Step‑by‑step guide explaining what this does and how to use it:
Enable Microsoft’s Vulnerable Driver Blocklist (Windows 11 22H2+)
Open Windows Security → Device Security → Core Isolation → turn on Microsoft Vulnerable Driver Blocklist. This list is updated automatically and prevents known vulnerable drivers from loading even if they have valid signatures.
Create a WDAC Policy to Allow Only Approved Drivers
WDAC can enforce a whitelist of allowed drivers, effectively blocking any driver not explicitly trusted.
1. Build a baseline policy from a clean reference machine New-CIPolicy -Level Publisher -FilePath C:\WDAC\BasePolicy.xml <ol> <li>Convert to binary format for deployment ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\BasePolicy.xml -BinaryFilePath C:\WDAC\BasePolicy.bin</p></li> <li><p>Deploy the policy (requires reboot) Copy-Item C:\WDAC\BasePolicy.bin -Destination $env:windir\System32\CodeIntegrity\SiPolicy.pdb Then reboot
Leverage Microsoft’s Recommended Driver Block Rules
For environments where WDAC is not feasible, download Microsoft’s driver blocklist and deploy it via Intune or Group Policy. The blocklist contains hashes and certificates of known malicious and vulnerable drivers.
Linux Equivalent – Kernel Module Signing Enforcement
On Linux, enforce signed kernel modules only:
Enable module signature enforcement (requires kernel compiled with CONFIG_MODULE_SIG_FORCE=y) echo 1 > /proc/sys/kernel/modules_disabled Prevent any module loads Alternatively, lock down module loading with a kernel lockdown (integrity or confidentiality) Edit /etc/default/grub: GRUB_CMDLINE_LINUX="lockdown=integrity" Then update-grub and reboot.
- Reducing the Attack Surface: Blocking LOLRMM and LOLBINs
The BYOVD attack does not happen in isolation. Attackers first use Living‑Off‑the‑Land (LotL) techniques—LOLBINs for scripting, LOLRMM for remote control—to gain a foothold. Blocking these primitives shrinks the attack surface before the kernel driver is ever needed.
Step‑by‑step guide explaining what this does and how to use it:
Block Unauthorized RMM Tools with WDAC
LOLRMM provides a curated list of remote monitoring tools that attackers often abuse, including ScreenConnect, AnyDesk, and TeamViewer. Use WDAC to block any executable that matches the hashes or publishers of these tools.
Create AppLocker Rules to Disable LOLBIN Execution
AppLocker can block script engines like PowerShell, MSBuild, and Regsvr32 from running unsigned code.
PowerShell: Set execution policy to AllSigned (blocks unsigned scripts) Set-ExecutionPolicy AllSigned -Scope LocalMachine Group Policy: Disable PowerShell v2 (often abused to bypass logging) Disable-WindowsOptionalFeature -Online -FeatureName "MicrosoftWindowsPowerShellV2"
Use Sigma Rules to Detect LOLRMM in Your Environment
LOLRMM provides Sigma rules that detect common RMM tool artifacts, such as installation directories, registry keys, and network traffic patterns.
Example Sigma rule snippet for AnyDesk title: AnyDesk Execution via LOLRMM logsource: product: windows service: security detection: selection: EventID: 4688 CommandLine|contains: 'anydesk.exe' condition: selection
Linux Alternative – Restricting Dynamic Scripts
On Linux, control script interpreters using AppArmor or SELinux policies, and set `noexec` mounts for user‑writable directories:
Mount /tmp with noexec to prevent script execution from temporary storage mount -o remount,noexec /tmp Set up AppArmor profile for bash to restrict its capabilities aa-genprof /bin/bash
- Hardening Windows and Linux Systems to Make BYOVD Exploitation Harder
Ultimately, the best defense is to make it impossible for a vulnerable driver to cause damage even if it does load. This requires layered hardening at the OS and hypervisor level.
Step‑by‑step guide explaining what this does and how to use it:
Enable Hypervisor‑Protected Code Integrity (HVCI)
HVCI runs the kernel and its drivers in a virtualized, isolated environment. Even if a vulnerable driver is loaded, HVCI can prevent exploitation of memory corruption bugs.
Enable HVCI via Registry Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 1 -Type DWord Reboot to apply
Activate Virtualization‑Based Security (VBS)
VBS creates isolated regions of memory that protect critical processes like LSASS and the kernel.
Enable VBS via Registry Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -Value 1 -Type DWord Reboot
Linux Hardening – Locking Down the Kernel
While Linux does not suffer from the same BYOVD ecosystem, kernel modules can still be abused. Use these commands to harden your Linux kernel:
Enable kernel lockdown (integrity mode)
Edit /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="lockdown=integrity"
Then:
sudo update-grub && sudo reboot
Restrict kernel module loading to root only
sudo sysctl -w kernel.modules_disabled=1
Make permanent:
echo "kernel.modules_disabled=1" | sudo tee -a /etc/sysctl.conf
Use eBPF to monitor and block suspicious kernel events
sudo bpftrace -e 'kprobe:do_init_module { printf("Module %s loading\n", str(arg1)); }'
Apply Principle of Least Privilege (PoLP)
Ensure that no user account has unnecessary administrator rights. Use Windows LAPS for local admin password rotation and remove “Local Administrator” from daily‑use accounts.
Linux Hardening – Restricting User Capabilities
On Linux, use `capabilities(7)` to reduce the attack surface:
Remove CAP_SYS_MODULE from all non‑root processes (prevents kernel module loads) setcap cap_sys_module=ep /usr/bin/insmod Only allow specific tools Use seccomp to block system calls related to module loading sudo docker run --security-opt seccomp=block-modules.json your_image
6. Simulating BYOVD Attacks with Atomic Red Team
You cannot defend against what you cannot test. Atomic Red Team provides small, portable tests that simulate BYOVD techniques without requiring full adversary emulation.
Step‑by‑step guide explaining what this does and how to use it:
Install Atomic Red Team on Windows
Install the module Install-Module -Name AtomicRedTeam -Force Import and list all available tests Import-Module "C:\AtomicRedTeam\atomics\AtomicRedTeam.psd1" Get-AtomicTechnique -Name "T1068" Run the BYOVD test (requires admin) Invoke-AtomicTest -TechniqueName "T1068" -TestGuid "e3f4c6b0-1a2b-4c5d-9e8f-0a1b2c3d4e5f"
Run the Linux‑specific tests
Clone the Atomic Red Team repository git clone https://github.com/redcanaryco/atomic-red-team.git cd atomic-red-team/atomics/T1068 Run a test that simulates a vulnerable driver loading via insmod sudo ./T1068.sh
Integrate with your SIEM
After running the tests, verify that your detection rules (Sysmon, Sigma, etc.) fired as expected. Any gap is a gap in your defense.
What to look for during simulation
Ensure that your EDR alerts on:
- Driver load events (Sysmon ID 6)
- Registry changes under `Services`
– `SeLoadDriverPrivilege` being enabled for non‑administrators - Process creation from `cmd.exe` or `powershell.exe` with arguments like `sc.exe start`
7. Prevention Engineering: Turning Intelligence into Enforcement
The defenders who win are those who turn threat intelligence into enforceable policy faster than attackers can pivot. This means proactively blocking the primitives attackers rely on—RMM tools, scripting engines, and vulnerable drivers—before any malicious payload arrives.
Step‑by‑step guide explaining what this does and how to use it:
Automate Blocklist Updates Using LOLDrivers and LOLRMM APIs
Retrieve the latest vulnerable driver signatures and RMM tool information programmatically:
Python script to fetch and deploy new blocklists
import requests
Fetch LOLDrivers JSON
drivers = requests.get("https://loldrivers.io/api/drivers.json").json()
Extract SHA256 hashes
hashes = [d['sha256'] for d in drivers if 'sha256' in d]
Deploy to Windows Defender Application Control
... (implementation specific to your management tool)
Create a Continuous Integration Pipeline for Security Policies
Maintain your WDAC policies, AppLocker rules, and Sysmon configurations in a Git repository. Every time a new vulnerable driver is added to LOLDrivers, automatically regenerate and deploy your blocklists.
Use MITRE ATT&CK Mappings to Prioritize Defenses
Map the techniques used in your environment to the ATT&CK framework. BYOVD is mapped to T1068 – Exploitation for Privilege Escalation and T1562.001 – Impair Defenses: Disable or Modify Tools. Prioritize coverage for these techniques first.
Linux Example – Continuous Kernel Hardening
Implement a daily cron job that checks for new kernel updates and applies CIS benchmarks automatically:
!/bin/bash Daily hardening script apt update && apt upgrade -y lynis audit system > /var/log/lynis.log grep -i "vulnerable" /var/log/lynis.log | mail -s "Security Audit Report" [email protected]
Windows Example – Scheduled Task for WDAC Refresh
Create a scheduled task that runs every 24 hours to download the latest Microsoft driver blocklist and merge it into your existing WDAC policy.
Refresh WDAC policy script $url = "https://download.microsoft.com/download/.../DriverBlockList.p7b" $output = "C:\WDAC\DriverBlockList.p7b" Invoke-WebRequest -Uri $url -OutFile $output Merge-CIPolicy -OutputFilePath C:\WDAC\UpdatedPolicy.xml -PolicyPaths C:\WDAC\BasePolicy.xml, $output ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\UpdatedPolicy.xml -BinaryFilePath C:\WDAC\UpdatedPolicy.bin Copy-Item C:\WDAC\UpdatedPolicy.bin -Destination $env:windir\System32\CodeIntegrity\SiPolicy.pdb -Force
What Undercode Say:
- Key Takeaway 1: Detection alone is insufficient; attackers will always find a way to bypass it. The focus must shift to prevention engineering—blocking the primitives before they are ever needed.
- Key Takeaway 2: BYOVD is not the beginning of the attack; it is the escalation phase. If you are only looking for vulnerable driver loads, you have already missed the early indicators of compromise.
Analysis: The industry’s obsession with detecting BYOVD reflects a reactive mindset. Michael H.’s insight is that by the time a vulnerable driver is loaded, the adversary has already executed code, persisted, and likely moved laterally. The real win comes from hardening the environment so that initial execution is impossible or immediately caught. This requires a shift from “detect and respond” to “prevent by default.” Technologies like WDAC, HVCI, and rigorous application whitelisting are not optional extras; they are the baseline. Moreover, the LOLDrivers and LOLRMM projects demonstrate that community intelligence can be automated into enforcement. The defenders who will survive the next wave of BYOVD attacks are those who embed prevention into their CI/CD pipelines, turning every new driver discovery into an immediate block rule.
Prediction: As more organizations adopt HVCI and WDAC, attackers will move away from kernel‑based EDR killing and toward user‑land evasion, including remote access trojans (RATs) that abuse legitimate cloud APIs and living‑off‑the‑land binaries. The LOLDrivers database will grow beyond 1,000 entries within the next two years, and we will see the first major ransomware group using AI to automatically discover and weaponize new vulnerable drivers from signed, legitimate sources. Defenders will respond by implementing prevention‑as‑code—dynamic, policy‑driven environments that automatically adapt to new threat intelligence without human intervention. The arms race is not slowing down; it is accelerating. Only those who embrace proactive, automated hardening will stay ahead.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Michaelahaag Saw – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
