Qilin Found a Way to Blind Your EDR Before You Know They're Inside
The most active ransomware group on the planet is now deploying a signed Windows driver to kill your entire security stack from the kernel level.

Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Cisco Talos and Trend Micro have published coordinated intelligence confirming that threat actors behind both the Qilin and Warlock ransomware operations are actively deploying a technique called Bring Your Own Vulnerable Driver (BYOVD) to systematically disable endpoint security tooling before their ransomware payload ever runs.
This is not a proof-of-concept. It is in-production tradecraft, observed across live intrusions. The objective is simple and devastating: arrive in your environment via stolen credentials, load a legitimate signed Windows driver, use that driver's kernel-level trust to kill every security process watching your endpoints, then detonate ransomware into a blind environment with no telemetry, no alerts, and no automated response capability.
For defenders who have staked their ransomware resilience on EDR, this is the threat that turns that bet against you.
The attack chain, step by step
Talos researchers Takahiro Takeda and Holger Unterbrink published a detailed technical teardown of the infection chain. Here is what the kill sequence actually looks like inside your environment:
Initial Access
Stolen credentials. No zero-day required. A single compromised account is the entire entry vector. Qilin prioritizes credential theft and reuse across enterprise environments before any other activity.
DLL Side-Loading
A malicious msimg32.dll is placed alongside a legitimate app such as FoxitPDFReader.exe. When the trusted app launches, it loads the malicious DLL instead. Execution triggers inside DllMain at load time, before anything can intervene.
Stage 1: PE Loader
The DLL contains an encrypted embedded PE loader. It allocates a heap buffer, neutralizes user-mode hooks that EDR products rely on for telemetry, and suppresses execution visibility through exception-handler abuse.
Stage 2: Vulnerable Driver Load
Two vulnerable drivers drop and load: rwdrv.sys (modified ThrottleStop.sys) grants direct physical memory access; hlpdrv.sys handles process termination. Both are legitimately signed. Windows trusts them.
Stage 3: EDR Callback Unregistration
Before any process is terminated, the EDR killer unregisters monitoring callbacks that EDR products have registered with the Windows kernel. This eliminates the telemetry pipeline itself, not just the processes.
Stage 4: Mass EDR Termination
With callbacks unregistered and kernel privileges established, the component terminates drivers from over 300 security products spanning virtually every major vendor on the market. The environment is security-dark.
Stage 5: Ransomware Deployment
With the defensive layer eliminated and telemetry suppressed, ransomware deploys into an environment with no detection, no automated response, and no meaningful response window remaining.
Why BYOVD is so hard to stop
The core problem is architectural. Windows enforces a protection boundary between user-space (Ring 3) and kernel-space (Ring 0). Your EDR lives in user-space. To have visibility at the kernel level, it registers callbacks with the OS, hooks that notify it when processes launch, memory is written, or drivers load.
BYOVD attacks this model at its foundation. By loading a legitimate, digitally signed driver, the attacker obtains kernel-level access through a channel that Windows explicitly trusts. From that position, they can reach directly into the kernel callback table and remove the registrations your EDR depends on. By the time your security tool would normally generate an alert, its entire notification infrastructure has been surgically removed.
What makes the Qilin implementation particularly concerning is the depth of the evasion layering. The loader neutralizes user-mode hooks before the driver is even introduced, suppresses telemetry through exception-handler manipulation, and keeps the most sensitive payload components encrypted in memory until the moment of execution.
“The EDR killer unregisters monitoring callbacks before loading the second driver, ensuring that process termination proceeds without interference.”
Talos Researchers, Direct Finding
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
This is now standard ransomware tradecraft
BYOVD has been a known technique for years. What has changed is its operational status. It is no longer a niche capability reserved for nation-state actors or red teams. The same vulnerable drivers abused in the Qilin chain, rwdrv.sys and hlpdrv.sys, have also appeared in Akira and Makop ransomware intrusions.
Warlock has its own BYOVD implementation documented by Trend Micro. In December 2025, Cisco Talos documented a DeadLock ransomware campaign using a BYOVD loader against a vulnerable Baidu Antivirus driver to terminate EDR processes and disable Windows Defender entirely.
The pattern is unmistakable: the criminal ransomware ecosystem has converged on EDR elimination as a standardized pre-encryption phase. These are not boutique capabilities. They are operationalized, reusable components being applied at scale across the entire ransomware-as-a-service economy.
Qilin, also tracked as Agenda, Gold Feather, and Water Galura, operates as a ransomware-as-a-service platform. That means BYOVD capability is now available to any affiliate who rents access, no specialized kernel engineering required.
The strategic consequence: compressed response windows
In a normal Qilin intrusion, attackers rely on stolen credentials for initial access and often delay ransomware deployment by days. Under standard circumstances, that dwell time is an opportunity, a window during which a properly staffed security team might detect post-compromise activity and contain the intrusion before encryption begins.
BYOVD directly destroys that opportunity. By targeting the EDR tooling and kernel callbacks a SOC team depends on for visibility, attackers can extend their operational window while simultaneously eliminating the defender's ability to capitalize on it. When encryption finally starts, the security stack has already been dark for some time.
For CISOs and security architects, the implication is direct: EDR is no longer sufficient as a primary ransomware defense layer. Any architecture that relies on EDR as the last line of defense has a gap that Qilin already knows about and is actively exploiting.
IOCs: hunt for these now
The following indicators have been confirmed by Cisco Talos across observed Qilin intrusions. Any instance of the malicious DLL outside its legitimate system path warrants immediate host isolation.
Subscribe to unlock Indicators of Compromise
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
What to do right now
Immediate remediation steps for your security team:
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
Qilin is not doing anything fundamentally new. BYOVD has existed for years. What Qilin has done is operationalize it into a polished, multi-stage attack chain that is actively deployed against enterprise targets at scale, through a RaaS platform available to affiliates without kernel engineering expertise.
The security industry spent years building EDR into the cornerstone of enterprise endpoint defense. Ransomware groups spent years finding the seam where that cornerstone can be pulled. That seam is the kernel trust boundary, and it is now being exploited in production attacks by the most active ransomware group on the planet.
The correct response is not to abandon EDR. It is to stop treating EDR as a complete solution and to build architectures that assume it can be blinded. That means HVCI enforcement, driver governance, identity hardening, and network-level controls that operate independently of endpoint agents.
The question for every security team this week is not whether Qilin's technique works. Talos has confirmed that it does. The question is whether HVCI is enabled across your fleet right now, and if not, what your plan is to get there before Qilin gets there first.
This analysis is generic — the platform version scores threats like this against your own stack.
Frequently asked questions
What is the Qilin BYOVD attack technique?
Qilin ransomware uses Bring Your Own Vulnerable Driver (BYOVD) to load a legitimately signed but vulnerable Windows driver (rwdrv.sys) that grants kernel-level access. The driver is then used to kill over 300 EDR and security products before ransomware is deployed, leaving the environment completely blind.
How do I defend against BYOVD attacks?
Enable Hypervisor-Protected Code Integrity (HVCI) across your fleet. HVCI prevents unsigned or vulnerable drivers from loading at the kernel level, breaking the BYOVD kill chain. Also enforce Microsoft's vulnerable driver blocklist and implement identity hardening since Qilin enters via stolen credentials.
Is my EDR vulnerable to Qilin's technique?
Cisco Talos confirmed Qilin's BYOVD technique can disable 300+ EDR products. If HVCI is not enabled on your endpoints, your EDR is potentially vulnerable to this kill chain regardless of vendor. Check HVCI status via System Information > Device Security > Core Isolation.
What is rwdrv.sys and why is it dangerous?
rwdrv.sys is a legitimately signed but vulnerable Windows kernel driver used by Qilin in its BYOVD attacks. Because it carries a valid Microsoft-accepted signature, Windows loads it without complaint even with standard driver signing enforcement enabled. Once loaded, it grants kernel-level privileges that Qilin uses to enumerate and terminate security processes across the system. The driver itself is not malware; it is an old, unpatched legitimate tool repurposed as a weapon. Microsoft's vulnerable driver blocklist should flag it, but only if HVCI is enforcing the blocklist at the kernel level.
How do I enable HVCI on Windows endpoints?
HVCI (Hypervisor-Protected Code Integrity) can be enabled via Group Policy (Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, set Credential Guard and HVCI to enabled), via Microsoft Intune (Endpoint Security > Account Protection or Device Configuration profile), or via the Windows Security app (Device Security > Core Isolation > Memory Integrity toggle). Enabling HVCI requires a reboot and may cause compatibility issues with older drivers. Test on a representative subset of endpoints before fleet-wide deployment and check the Microsoft HVCI compatibility list.
Sources & references
- Cisco Talos
- Trend Micro
- CYFIRMA
- Cynet
- UltraViolet Cyber
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.

Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.
