TL;DR
Two active ransomware groups — Qilin and Warlock — have industrialized Bring Your Own Vulnerable Driver (BYOVD) into a reliable, automated pre-encryption kill chain. Before a single file is touched, their tooling silently terminates over 300 endpoint security products by exploiting legitimate, Microsoft-trusted kernel drivers to achieve Ring 0 access. From the EDR's perspective, the host looks quiet. From the attacker's perspective, the security stack is dark. Standard blocklist-based defenses are failing because these groups actively rotate drivers faster than Microsoft updates DriverSiPolicy.p7b. This article breaks down the full attack chain, the architectural reason it works, and a concrete 10-control defensive playbook every security team can act on now.
Background: BYOVD Is No Longer an Edge Case
Bring Your Own Vulnerable Driver has existed as a theoretical threat since at least 2018, when researchers first documented abuse of signed kernel drivers to bypass security controls. For most of that period it remained a niche technique — difficult to weaponize reliably, quickly burned once the driver hash made it onto a blocklist.
That calculus changed in 2026.
Research from Cisco Talos and Trend Micro published in early April confirmed that Qilin and Warlock — two operationally mature ransomware-as-a-service groups — have embedded BYOVD not as an occasional exploit edge case but as a mandatory, automated pre-encryption step in their standard deployment playbook. Every victim encounter. Every time. The industrialization is the news.
Qilin has been active since at least 2022 and is linked to attacks against healthcare systems, logistics operators, and critical infrastructure in Europe and North America. Warlock, a newer entrant believed to operate as a splinter from a legacy RaaS network, adds a double-extortion twist: it executes credential harvesting and data exfiltration before the destructive payload runs, ensuring leverage even if the victim restores from backup.
Together they represent a threat vector that is presently defeating the EDR-centric security model that most mid-to-large enterprises have spent the last six years building.
Technical Analysis: The Five-Stage Kill Chain
Understanding why BYOVD works at scale requires briefly reviewing how Windows driver security is architected — and where the trust model breaks.
The Kernel Trust Problem
Windows requires all drivers to carry a valid digital signature before they can load into kernel space (Ring 0). This policy exists to prevent arbitrary malicious code from running at the highest privilege level. The intent is sound. The flaw is the implementation: Windows verifies that the signature is valid, not that the driver is unexploitable. If a vendor shipped a kernel driver with a memory corruption bug five years ago and that driver is still signed, it still loads.
Microsoft maintains a Driver Vulnerable Block List (DriverSiPolicy.p7b) that catalogs known-dangerous drivers. This list is distributed via Windows Update. The problem: the list is months behind active exploitation. Attackers have learned to search for signed-but-not-yet-blocklisted drivers and build operational pools of viable candidates, rotating to new ones as old entries get blocked.
Stage 1 — Initial Access and Staging (T1566 / T1574.002)
Qilin typically enters via phishing or purchased initial access broker credentials. Once a foothold is established, a malicious msimg32.dll is dropped and sideloaded via a legitimate host process — a signed Windows binary that the OS trusts implicitly. No UAC prompt. No suspicious parent-child process relationship. The staging is clean.
Stage 2 — Vulnerable Driver Deployment (T1068)
The staged loader writes an exploitable but legitimately signed kernel driver to disk. It is then loaded via NtLoadDriver. The OS kernel loads it without complaint. The driver appears in process listings as a legitimate component. In most environments, this stage generates zero alerts.
Stage 3 — Ring 0 Escalation (T1543.003)
With kernel-mode execution, the attacker gains full read/write access to kernel memory structures. Critically, this includes EPROCESS — the kernel data structure for every running process — and the kernel callback tables through which EDR products receive notifications about process creation, thread injection, and image loads. PPL (Protected Process Light), the mechanism EDR vendors use to prevent their processes from being killed by userland attackers, provides no protection once an adversary has Ring 0 access.
Stage 4 — Security Stack Termination (T1562.001)
Qilin and Warlock maintain an actively curated list targeting over 300 endpoint security products by name. The tooling enumerates running processes, matches against the list, and forcibly terminates them. More critically, it zeroes out kernel callbacks registered by AV/EDR products. The security tools continue running as processes — their heartbeat remains — but they receive no events. No process creation notifications. No image load notifications. No thread injection alerts. The EDR is clinically alive but operationally blind. Detection gaps arising from this state are virtually indistinguishable from a genuinely quiet host.
This distinction matters enormously for threat hunters: absence of alerts is not evidence of absence of compromise once a BYOVD stage has executed.
Stage 5 — Payload and Exfiltration
Warlock exfiltrates credential stores and target data directories before detonating. Qilin proceeds directly to encryption. VSS shadow copies are deleted. The ransom note drops. By this point the entire sequence from initial driver load to first encrypted file can occur in under four minutes at observed breakout speeds.
Why Blocklist-Only Defense Is Failing
The standard Microsoft guidance — enable Driver Block Rules, deploy DriverSiPolicy.p7b, configure Hypervisor-Protected Code Integrity (HVCI) — remains correct but insufficient in isolation.
The core problem: Qilin and Warlock operate driver pool rotation as an intelligence discipline. They monitor blocklist updates, identify newly blocked entries, and pre-qualify replacement drivers before the old ones burn out. This is not ad hoc — it is supply chain management for kernel-level weapons.
Independent research has identified that the average lag between a driver being exploited in a campaign and appearing on Microsoft's blocklist is 47–90 days. For a RaaS group rotating pools monthly, that lag is a comfortable operational window.
IOCs and MITRE ATT&CK Mapping
| MITRE Technique | ID | Notes |
|---|---|---|
| Phishing | T1566 | Primary initial access for Qilin |
| DLL Sideloading | T1574.002 | msimg32.dll via trusted host process |
| Exploitation for Privilege Escalation | T1068 | Vulnerable driver kernel exploit |
| Modify System Process | T1543.003 | NtLoadDriver abuse |
| Impair Defenses — Disable or Modify Tools | T1562.001 | 300+ product process kill list |
| Inhibit System Recovery | T1490 | VSS deletion pre/post encryption |
| Data Encrypted for Impact | T1486 | Final ransomware payload |
| Exfiltration Over C2 | T1041 | Warlock double-extortion phase |
Known vulnerable drivers abused in 2025–2026 campaigns (partial — actively rotated):
mhyprot2.sys(miHoYo anti-cheat) — older, widely blocklistedgdrv.sys(GIGABYTE) — revoked but still loads on unpatched systemsATSZIO64.sys(ASRock) — blocklisted Q1 2026HW64.sys(Highpoint RAID) — seen in Warlock deployments April 2026dbutil_2_3.sys(Dell) — still observed in some environments despite extended blocklist coverage
Detection hashes: Consult Cisco Talos and Trend Micro's April 2026 joint advisory for current Qilin/Warlock driver SHA256s (updated as groups rotate).
Lyrie Take
The uncomfortable truth this campaign surfaces is that the EDR-centric security model has a structural floor. EDR is exceptionally good at detecting userland malice. It is completely blind once its kernel callback infrastructure has been zeroed. The attack surface here isn't a bug in any particular product — it is the architectural gap between the operating system's driver trust model and the realities of a threat landscape where that trust model is actively catalogued and weaponized.
The CI Fortify initiative CISA launched on May 6 — directing critical infrastructure to build isolation and offline-operation capabilities in the face of nation-state intrusions like Volt Typhoon — implicitly acknowledges the same problem at a strategic level: you cannot rely solely on detection and response; you must architect for operations when detection has already failed. BYOVD is the ransomware world making the same point operationally.
Qilin's industrialization of BYOVD is also a signal about the economics of the RaaS market. When a technique becomes reliable enough to automate into every deployment, it means the expected value of the capability has been validated at scale. Security teams should not treat this as a sophisticated nation-state edge case — it is now a commodity tool in mid-tier criminal infrastructure.
The good news: BYOVD is detectable and preventable with the right controls layered below the EDR, not alongside it. The playbook below focuses specifically on controls that survive a compromised EDR.
Defender Playbook: 10 Controls That Survive a Blind EDR
Control 1 — Enable HVCI (Hypervisor-Protected Code Integrity) Universally
HVCI enforces kernel code integrity from a hypervisor layer, meaning kernel memory pages cannot be made executable even by Ring 0 code that bypasses the kernel itself. This is the single highest-impact BYOVD countermeasure. Many organizations have not deployed it due to compatibility concerns — 2026 hardware has largely resolved these. Audit your fleet and require HVCI on all Tier 0 and Tier 1 endpoints immediately.
Control 2 — Deploy WDAC (Windows Defender Application Control) Deny Policies for Drivers
WDAC operating in deny-list mode blocks specific vulnerable driver hashes at the policy level, independent of Microsoft's blocklist update cadence. Maintain your own fast-update driver hash block list fed by threat intel (Sigma rules, CISA advisories, Talos) and push updates via Intune/SCCM with a sub-24-hour SLA. Don't wait for Windows Update.
Control 3 — Audit and Restrict NtLoadDriver Privilege
NtLoadDriver requires SeLoadDriverPrivilege. Audit which accounts and processes hold this privilege in your environment. On endpoint workstations, virtually no process should hold this right. Strip it from all non-essential accounts and monitor for privilege escalation attempts at the API call level (Sysmon Event ID 6 for driver loads).
Control 4 — Network Detection and Response as EDR Shadow
NDR sees traffic that a kernel-blinded EDR cannot. Instrument all segments — east-west especially — for anomalous beacon patterns, SMB traversal, and large outbound transfers. When EDR telemetry goes quiet on a host that was previously chatty, NDR should raise an alert. Silence is a signal.
Control 5 — Absence Monitoring
Instrument your SIEM to alert when an endpoint stops sending EDR telemetry unexpectedly. A host whose security agent heartbeat flatlines without a scheduled maintenance window or decommission event is a high-confidence BYOVD indicator. This is a simple detection that many organizations still lack.
Control 6 — Immutable Backup With Isolated Network Egress
Ensure backup infrastructure operates on a network segment that is never accessible from user/workstation VLANs. Warlock's double-extortion depends on threatening the backup as leverage. If backups are isolated and immutable (WORM storage, air-gapped replication), the extortion half of the attack collapses.
Control 7 — Constrain VSS Access via WDAC and Auditing
Implement WDAC rules blocking untrusted binaries from invoking vssadmin.exe or wmic shadowcopy delete. Log all VSS deletion events (Event ID 7036, VSSVC events). Many organizations still have no alerting on shadow copy deletion — this is a ransomware pre-detonation signal with very low false positive rates.
Control 8 — Kernel Callback Integrity Monitoring
Deploy tooling that can detect when kernel notification callbacks have been zeroed or manipulated — PatchGuard in modern Windows detects this but is bypassable; dedicated solutions like Microsoft Defender for Endpoint's kernel tamper protection and third-party solutions (e.g., Carbon Black's kernel sensor telemetry, Trellix) add additional visibility layers below where standard EDR hooks operate.
Control 9 — Enforce Tiered Administration and Privileged Access Workstations
BYOVD can only execute on a host where the attacker already has local administrator (or higher) privilege. Enforcing tiered administration — where privileged accounts are never used on general workstations, and Domain Admin activity is restricted to PAWs with hardware-enforced isolation — significantly raises the cost of reaching a position where driver loading is possible.
Control 10 — Tabletop Exercise: EDR-Blind Scenario
Run a tabletop or purple team exercise where the assumed starting condition is EDR fully blinded on a subset of endpoints. Most incident response plans assume EDR telemetry is available. Practice the degraded-detection scenario: how does your team detect lateral movement, identify patient zero, and contain a ransomware event when endpoint telemetry has been zeroed? This exercise will expose procedural gaps before an adversary does.
Sources
1. Druva Research: "Weaponizing Trust — How BYOVD Tactics Silently Bypass EDR Defenses" (April 2026) — https://www.druva.com/blog/weaponizing-trust-byovd
2. Cymulate Threat Research: "Defending Against BYOVD Attacks" (May 2026) — https://cymulate.com/blog/defending-against-bring-your-own-vulnerable-driver-byovd-attacks/
3. Dark Reading: "EDR-Killer Ecosystem Expansion Requires Stronger BYOVD Defenses" (April 2026) — https://www.darkreading.com/vulnerabilities-threats/edr-killer-ecosystem-expansion-requires-stronger-byovd-defenses
4. Cisco Talos / Trend Micro: Joint Qilin/Warlock Campaign Analysis (April 2026) — referenced via Druva/Cymulate secondary reporting
5. CISA CI Fortify Initiative — https://www.cisa.gov/topics/industrial-control-systems/ci-fortify (May 6, 2026)
6. The Record: "New CISA initiative aims for critical infrastructure to operate offline during cyberattacks" (May 2026) — https://therecord.media/cisa-initiative-aims-for-critical-infrastructure-to-operate-during-cyberattacks
7. Vectra AI: "EDR Evasion: Techniques, Real-World Breaches, and Defenses" (May 2026) — https://www.vectra.ai/topics/edr-evasion
8. Microsoft HVCI Documentation: https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity
9. Microsoft Vulnerable Driver Blocklist: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules
Lyrie.ai Cyber Research Division — Senior Analyst Desk
Lyrie Verdict
Lyrie's autonomous defense layer flags this class of exposure the moment it surfaces — no signature update required.