The BYOVD Epidemic: How Attackers Are Weaponizing Trusted Windows Drivers to Kill Security
BYOVD (Bring Your Own Vulnerable Driver) attacks have become a standard component of ransomware operations, allowing attackers to exploit signed kernel drivers for kernel-level access and subsequently disable AV/EDR products. The technique involves dropping a legitimate but vulnerable signed driver, loading it via a Windows service, and sending crafted IOCTL commands to terminate, blind, or strip privileges from security software. Microsoft's kernel hardening features and Vulnerable Driver Blocklist provide insufficient protection, as data-only kernel attacks bypass hardening and the blocklist has significant update lag. Behavioral monitoring of anomalous driver IOCTL interactions is the most effective defensive approach, as it is driver-agnostic and does not depend on prior driver identification.
- filenametruesight.sysVulnerable signed kernel driver abused by TrueSightKiller tool to gain kernel access and terminate security product processes. Dropped to disk by attacker and loaded via a Windows service.
Detection / Hunteropenrouter
What Happened
Attackers are increasingly using a technique called Bring Your Own Vulnerable Driver (BYOVD) to disable security software on Windows computers. They do this by placing a legitimate, digitally signed but flawed driver file onto a victim's machine, then exploiting the flaw to gain the highest level of control over the operating system. Once in control, they can turn off antivirus and security monitoring programs, making it easier to deploy ransomware undetected. This affects all Windows users and organizations, particularly those targeted by ransomware groups who now routinely bundle these tools into their attack kits. It matters because traditional security measures like Microsoft's driver blocklist and built-in kernel protections are not enough to stop these attacks, as they only react to known threats and can be bypassed by modifying data the operating system already holds. Organizations should consider using endpoint security products that monitor the actual behavior of driver interactions in real-time, rather than relying solely on lists of known-bad files, and should ensure the Microsoft Vulnerable Driver Blocklist is enabled on all endpoints.
Key Takeaways
- BYOVD has evolved from a niche tactic to a standard component of ransomware-as-a-service (RaaS) playbooks, with ready-made tools openly traded and bundled into payloads.
- Attackers exploit digitally signed but vulnerable kernel drivers to gain kernel-level access, then terminate, blind, or strip privileges from AV/EDR products.
- Microsoft's kernel hardening features (KASLR, HVCI, KCFG) do not stop data-only attacks that modify kernel data structures such as process protection fields and callback registrations.
- The Microsoft Vulnerable Driver Blocklist has significant update lag (days to weeks) and only covers a subset of known vulnerable drivers, leaving a window for exploitation.
- Behavioral monitoring of anomalous driver IOCTL interactions is the most effective defense, as it is driver-agnostic and can catch previously unknown vulnerable drivers on first appearance.
Affected Systems
- Windows operating systems (all versions using NT kernel with third-party driver support)
- Endpoint security products (AV/EDR) running on Windows
- Systems relying on Protected Process Light (PPL) for security agent protection
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker gains administrator privileges on the target machine through prior intrusion steps
- Drop: Attacker drops a legitimate, digitally signed but vulnerable kernel driver to disk
- Register: Attacker creates a Windows service pointing to the dropped driver file
- Load: Attacker starts the service, causing Windows to load the driver into the kernel
- Command: Attacker sends a specially crafted IOCTL command to the driver exploiting its vulnerability
- Execute: Driver performs privileged action without access checks, terminating, blinding, or stripping defenses from security software
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Symantec and Carbon Black endpoint products (behavioral monitoring)
The article describes behavioral detection capabilities in Symantec and Carbon Black endpoint products that monitor anomalous IOCTL traffic between processes and kernel drivers, flagging process termination requests directed at security products, handle stripping, and callback removal. No specific detection rules (YARA, Sigma, Snort/Suricata, KQL, SPL, EQL) are provided in the article itself. A companion whitepaper titled 'Lights Out: Defense Evasion in the Age of BYOVD' may contain additional detection details.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR products can observe service creation, driver loading events, and process termination targeting security products. However, the core attack occurs at the kernel level via IOCTL commands, and if the EDR itself is the target of the attack, it may be blinded or terminated before it can report. Behavioral monitoring of driver IOCTL interactions as described in the article would require specific EDR capabilities not universally available. |
| Network Visibility | Low | BYOVD attacks are primarily local, involving driver loading and kernel-level interactions. Network telemetry would only capture upstream activity such as C2 communications or data exfiltration that occurs after defenses are disabled, not the BYOVD attack itself. |
| Detection Difficulty | Hard | Signature-based detection is insufficient as attackers rapidly re-implement BYOVD tools in different languages. The Microsoft Vulnerable Driver Blocklist has significant lag. Effective detection requires behavioral monitoring of driver IOCTL interactions, which is not a standard capability across all EDR products. The attack uses legitimately signed drivers, reducing suspicion from file reputation systems. Additionally, if the EDR is the target, it may be disabled before generating alerts. |
Required Log Sources
- Windows System Event ID 7045 (Service Creation)
- Windows Security Event ID 4688 (Process Creation)
- Windows System Event ID 6 (Driver Loading)
- EDR process ancestry and command-line telemetry
- EDR driver loading and IOCTL interaction telemetry if available
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for Windows service creation events (Event ID 7045) where the binary path points to a .sys file in a non-standard location such as temp directories or user-writable paths, which may indicate a BYOVD drop. | Windows System Event ID 7045, EDR service creation events, driver load events | Persistence/Load | Medium - legitimate software installations may create services pointing to driver files in non-standard locations during installation. |
| Consider hunting for processes that enumerate running processes (T1057) and subsequently issue IOCTL commands to kernel drivers, particularly when the enumerated processes include known security product names. | EDR process telemetry, API call monitoring for process enumeration, driver IOCTL interaction logs | Discovery/Execution | Medium - legitimate administrative tools may enumerate processes and interact with drivers, but targeting security products specifically is anomalous. |
| Consider hunting for security product processes that transition to a suspended state rather than being terminated, as attackers may suspend PPL-protected processes to evade detection while still disabling protection. | EDR process state monitoring, Windows process lifecycle events | Defense Evasion | Low - security products being suspended is highly unusual and rarely occurs during normal operations. |
| Consider hunting for driver loading events where the driver file was recently written to disk by a non-system process, indicating a potential BYOVD drop-and-load pattern. | Windows System Event ID 6 (driver load), file write events, EDR file creation telemetry | Execution | Medium - legitimate driver installations during software updates may exhibit similar patterns. |
| Consider hunting for anomalous IOCTL traffic patterns directed at kernel drivers, particularly process termination requests, handle stripping operations, or callback removal targeting security product processes. | EDR behavioral monitoring of driver IOCTL interactions, kernel callback telemetry if available | Defense Evasion | Low - IOCTL commands requesting termination of security products from third-party drivers are highly anomalous regardless of driver identity. |
Control Gaps
- Microsoft Vulnerable Driver Blocklist has significant update lag (days to weeks) and only covers a subset of known vulnerable drivers
- Signature-based detection is defeated by rapid re-implementation of BYOVD tools in different programming languages
- Windows PPL mechanism does not prevent process suspension, leaving security products vulnerable to being paused rather than killed
- Kernel hardening features (KASLR, HVCI, KCFG) do not prevent data-only attacks that modify kernel data structures
- Microsoft's servicing criteria explicitly state that admin-to-kernel is not a security boundary for the NT kernel, meaning fixes arrive without CVEs and outside standard security response
- EDR products that lack behavioral IOCTL monitoring cannot detect novel vulnerable drivers on first appearance
Key Behavioral Indicators
- Service creation with binary path pointing to a .sys driver file in a non-standard or user-writable directory
- Process enumeration followed by IOCTL commands sent to a kernel driver targeting security product processes
- Security product processes transitioning to suspended state without corresponding service stop events
- Driver file written to disk by a non-system process immediately before being loaded via a newly created service
- Anomalous IOCTL traffic patterns from user-mode processes to kernel drivers, especially process termination or handle manipulation requests directed at security products
- Security product processes terminating shortly after a new driver is loaded into the kernel
- Removal or modification of kernel callback registrations that security products depend on for event notifications
False Positive Assessment
Medium - Behavioral detection of anomalous IOCTL traffic and driver loading from non-standard paths may generate false positives during legitimate software installations, driver updates, or administrative tasks. However, specific patterns such as IOCTL commands targeting security product processes or driver files written by non-system processes immediately before service creation are highly indicative of BYOVD activity. The driver-agnostic behavioral approach described in the article reduces false positives by focusing on the operational pattern rather than specific driver signatures.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing endpoints for the presence of known vulnerable drivers such as truesight.sys and other drivers listed in Microsoft's Vulnerable Driver Blocklist.
- If your environment supports it, consider verifying that the Microsoft Vulnerable Driver Blocklist is enabled and up to date on all Windows endpoints, particularly those running older Windows versions where it may not be enabled by default.
- Consider reviewing recent service creation events (Windows Event ID 7045) for services with binary paths pointing to .sys files in non-standard locations, as these may indicate prior BYOVD activity.
- If your EDR supports behavioral monitoring of driver interactions, consider verifying that this capability is enabled and alerting on anomalous IOCTL traffic directed at security product processes.
Infrastructure Hardening
- Consider enabling Hypervisor-Protected Code Integrity (HVCI) and Kernel Control Flow Guard (KCFG) on supported hardware, while recognizing these do not fully prevent data-only kernel attacks.
- Evaluate whether hardware-enforced stack protection can be deployed across your Windows fleet as an additional kernel hardening layer.
- If your endpoint security product supports it, consider enabling driver-agnostic behavioral monitoring of IOCTL interactions rather than relying solely on driver blocklists or signature-based detection.
- Consider implementing application control policies (e.g., WDAC) that restrict which drivers can be loaded, reducing the attack surface for BYOVD techniques.
- Evaluate whether network segmentation can limit the impact of security product cloud connectivity being severed, as attackers may cut off EDR from vendor cloud services to degrade detection accuracy.
User Protection
- Consider ensuring all endpoint security products are running the latest versions with tamper protection features enabled, where supported by the vendor.
- If your EDR product supports Protected Process Light (PPL) integration, consider verifying it is configured to run at the highest available protection level, while being aware that PPL does not prevent process suspension.
- Consider deploying endpoint products that provide behavioral monitoring of driver IOCTL interactions, as described in the article, to detect both known and novel BYOVD attacks.
- Evaluate whether your security products can alert on their own suspension or loss of cloud connectivity, as these may indicate active defense evasion attempts.
Security Awareness
- Consider incorporating BYOVD threat awareness into existing security team training programs, emphasizing that administrator-level compromise can lead to kernel-level attacks that disable security tools.
- If applicable to your awareness program, consider educating IT staff that installing unsigned or untrusted drivers poses significant risk, and that even legitimately signed drivers can be vulnerable to exploitation.
- Consider adding BYOVD detection scenarios to existing tabletop exercises or purple team engagements to validate that detection and response capabilities can identify driver-based defense evasion.
- Where relevant to your organization, consider briefing leadership on the limitations of kernel hardening and driver blocklists, and the importance of behavioral detection capabilities for defense against modern ransomware operations.
MITRE ATT&CK Mapping
Execution
Privilege Escalation
Defense Evasion
Additional IOCs
- Command Lines:
- Purpose: Create a Windows service to register and load the dropped vulnerable kernel driver | Tools:
sc.exe| Stage: Persistence/Load |sc.exe create <servicename> binpath= <driver_path> - Purpose: Start the newly created service to load the vulnerable driver into the Windows kernel | Tools:
sc.exe| Stage: Execution |sc.exe start <servicename>
- Purpose: Create a Windows service to register and load the dropped vulnerable kernel driver | Tools: