Qilin and Warlock Use Vulnerable Drivers to Blind EDR

If you only read one thing: Ransomware crews are using vulnerable drivers to shut off endpoint defenses before encryption starts.

As of April 6, 2026: As of April 6, 2026, Cisco Talos and Trend Micro have tied BYOVD activity to Qilin and Warlock intrusions.

Executive summary

Qilin and Warlock operators used BYOVD ransomware tactics to disable endpoint detection and response tools on infected systems. That matters because once EDR is blinded, the attacker can move faster, stay quieter, and raise the odds of a successful encryption event.

The core reporting comes from The Hacker News, with technical context from Cisco Talos and Trend Micro. The pattern is familiar. An attacker gains a foothold, then loads a signed but vulnerable driver to interfere with security software already present on the host.

Confirmed reporting indicates the groups targeted hundreds of EDR detections and protections, not just a single vendor or a single process. In practice, that broadens the blast radius. If the driver load succeeds, the host can lose visibility right before encryption, lateral movement, or credential theft.

Qilin’s activity, as described by Talos, also included the use of a malicious DLL named msimg32.dll to support execution on the compromised machine. Warlock’s tradecraft appears aligned in spirit, even if the exact tooling and sequence vary by campaign. The common thread is simple: use trusted code paths to break trusted defenses.

Interpretation, not hype: this is a strong reminder that EDR presence alone is not enough. If an environment allows vulnerable drivers to load, the attacker may not need to “hack” the security stack at all. They can just turn it off from the inside.

That makes driver control a practical control point, not a niche hardening task. Signed-driver abuse has become a repeatable route for ransomware crews, and this case fits that pattern closely. Defenders should treat driver allowlisting, blocklists, and tamper protection as first-class controls.

Timeline and verified facts

Cisco Talos and Trend Micro were the first reported sources in this chain. Their findings tied Qilin and Warlock activity to bring your own vulnerable driver, or BYOVD, ransomware tradecraft. The reports describe a sequence where attackers used trusted-looking components to interfere with endpoint security on compromised hosts.

Talos said the Qilin side of the activity involved a malicious DLL named msimg32.dll. That file name matters because Windows includes a legitimate system library with the same name pattern, which can make the malicious version easier to blend into normal process loading. The report placed the DLL in the execution flow observed on affected machines. ransomware incident response

Trend Micro separately reported the use of vulnerable drivers in the broader campaign set. Those drivers were used to disable or weaken endpoint detection and response, or EDR, tools after initial access. The method fits the BYOVD model. Attackers load a signed but flawed driver, then use it to issue privileged actions that security software cannot easily block.

Practical takeaway: the reported sequence is not just malware execution. It is execution plus driver abuse, which can shut down security tools from inside the host.

The reports also said more than 300 EDR tools were disabled. That figure appears in the vendor findings as a campaign-level claim, not as a universal count for every victim. Still, it gives a sense of scale. The observed activity was not limited to one product family or one vendor’s stack.

Here is the catch: the timeline points to a layered approach. First comes execution, then the malicious DLL, then the vulnerable driver, and then the security-control disruption. The order matters because it shows how the attackers moved from access to suppression.

The verified facts stop there. Cisco Talos reported the Qilin-linked DLL activity. Trend Micro reported the vulnerable-driver abuse and the wider EDR disruption claim. Both point to the same core pattern: attackers using signed, vulnerable code to interfere with defensive software.

Last reviewed: April 6, 2026

How the BYOVD chain works

The appeal is simple. A signed driver has already cleared Microsoft’s code-signing checks, so it often looks safer to the operating system than a random executable. That does not make it safe. If the driver contains a flaw, an attacker can use that flaw to read memory, kill processes, change kernel settings, or tamper with security products that depend on normal system behavior.

That matters because EDR tools are built to observe from the endpoint itself. They watch process creation, file changes, registry edits, and kernel-level activity. If a hostile driver gets into that same trust zone, it can blind the sensor, break its callbacks, or make its service look unhealthy. The result is not always a clean shutdown. Sometimes the tool is still present, but it stops seeing the attack.

The BYOVD pattern usually has a few stages. First, the operator gets code execution on the host. Next, they drop or stage a vulnerable driver that is signed and therefore easier to load. Then they use a known weakness in that driver to gain kernel-level influence. After that, they target the EDR process, its driver, or the telemetry path it depends on. That sequence is attractive because it turns one trusted component into a weapon against another.

Windows driver trust is the key piece here. Signed code is not the same as secure code. A signature only says who published it and that the binary has not changed since signing. It does not guarantee the driver is free of bugs. Security teams often track this through allowlists, blocklists, and Microsoft’s vulnerable-driver protections, but those controls only help if the driver is known and the policy is current.

Where do DLL sideloading and loader abuse fit? They are often the delivery layer, not the end goal. A malicious DLL can be named to match a legitimate library that a trusted application loads first. If the application searches the wrong path, the attacker’s DLL gets loaded instead. That DLL can then unpack the driver, launch the exploit, or stage the next component with less noise than a direct dropper.

Loader abuse is broader. It covers any trick that uses a legitimate executable to start hostile code under a trusted process tree. On a busy endpoint, that can help the attacker blend in long enough to place the driver and trigger the vulnerable code path. The driver does the heavy lifting. The loader just gets it there without drawing attention.

There is a practical defense lesson in that sequence. Blocking one malicious file is not enough if the operator can swap in another signed driver or use a different loader. Teams need visibility on driver loads, unusual parent-child process chains, and abrupt EDR service failures. The pattern is noisy once you know what to watch for. The hard part is catching it before the sensor goes dark.

Last reviewed: April 6, 2026

What this changes for security teams

The immediate problem is not just “EDR bypass.” It is time. When a vulnerable driver can mute endpoint controls, detection slows down exactly when attackers need a clear run at the host. That affects IT admins, SOC analysts, incident responders, remote workers, and any organization that assumes endpoint telemetry will stay intact during an intrusion.

For IT teams, the first pain point is trust in the machine itself. A blocked alert may still mean the attacker is already inside the process tree, moving from execution to persistence to lateral movement. BYOVD ransomware changes the meaning of a successful stop event: the malware may be contained on one alert path, while the broader intrusion keeps going elsewhere.

Practical takeaway: if the sensor goes quiet, do not assume the host is clean. Treat missing telemetry as a possible compromise signal.

SOC analysts feel this most during triage. They may lose process visibility, file events, or driver-load telemetry right when the operator is staging payloads or probing for adjacent systems. That creates blind spots during lateral movement, which is where ransomware crews often earn their real leverage. This is the most dangerous part of the technique. It turns a detection problem into an access problem.

Incident responders also get a harder job. If the endpoint agent is blinded, they need alternate evidence fast: memory captures, network logs, authentication events, and host artifacts that survive the attack path. The gap between a blocked alert and a fully stopped intrusion can be wide. Sometimes it is minutes. Sometimes it is long enough for the attacker to reach backup systems or domain-level credentials.

Remote workers are exposed too, especially when they sit outside the office network and depend on endpoint controls as the main line of defense. A laptop with weakened telemetry can become a quiet bridge back into internal resources. That matters because the attacker does not need every endpoint. One unmanaged or partially blinded device can be enough to open the door.

BYOVD

Bring your own vulnerable driver. The attacker loads a legitimate but flawed driver to gain kernel-level control or suppress security tools.

EDR

Endpoint detection and response. This software watches hosts for suspicious behavior and helps teams investigate and contain attacks.

Lateral movement

The stage where an intruder moves from one system to another after the first compromise. It is often quieter than the initial breach.

Telemetry

The logs and signals a security tool sends back. If telemetry drops, defenders lose visibility into what the host is doing.

Organizations of any size should read this as a control gap, not a niche ransomware trick. A single compromised endpoint can still matter if it sits near identity systems, file servers, or admin consoles. The lesson is plain: endpoint controls need backup detection paths, driver monitoring, and a response plan that assumes the agent itself may be under attack.

Assessment: the threat is less about one malware family and more about a repeatable method for blinding security layers. The data suggests defenders should expect partial failures, not clean stops, when vulnerable drivers enter the picture.

Last reviewed: April 6, 2026

Mitigation and diligence checks

The first control to check is the vulnerable driver blocklist. Microsoft maintains a blocklist for known-bad kernel drivers, and it matters here because BYOVD ransomware depends on loading signed but unsafe code into kernel space. If that list is stale, the rest of the stack starts from behind. See Microsoft’s guidance on block rules for vulnerable drivers.

Do not stop at “enabled.” Verify where the policy is enforced, how it is distributed, and whether endpoints actually received the latest rules. In our assessment, that last step is where many environments fail. A policy that exists in documentation but not on the host is just paperwork.

Attack surface reduction helps too, especially rules that limit script abuse, child process spawning, and unsigned or suspicious binary activity. Pair that with kernel protection features such as HVCI, also known as Memory Integrity, where hardware and driver support allow it. The goal is simple: make it harder for a malicious driver to load, persist, or interfere with security tools.

EDR tamper protection needs the same scrutiny. Check whether local users, even admins, can disable the agent, stop services, or alter exclusions without a separate control path. Test it. Then test it again after a reboot. If an attacker can turn off visibility before encryption starts, the incident becomes much harder to contain.

Logging should cover driver installation, module loads, service creation, and suspicious DLL placement in writable paths. Watch for names that appear in unexpected directories, especially when a DLL is dropped beside a trusted process to influence loading order. Qilin activity has included msimg32.dll placement, which is a reminder to hunt for DLL hijacking patterns, not just obvious ransomware filenames.

Useful hunts are boring on purpose. Look for recent driver loads from nonstandard paths, signed drivers with odd parent processes, and kernel events that line up with EDR failures or sudden telemetry gaps. Also check for repeated attempts to install the same driver across multiple hosts. That can signal a failed BYOVD campaign, not a one-off mistake.

For deeper validation, map your checks to known bad-driver patterns and vendor advisories. CVE records for abused drivers often show a familiar shape: a legitimate signing chain, a privileged load path, and a flaw that lets attackers disable protections or read/write kernel memory. The exact CVE will vary, but the operational test does not. Can your team spot the load, block it, and keep logging intact?

Last reviewed: April 6, 2026

Readers often ask

Readers often ask: What is BYOVD ransomware, in plain terms?

Readers often ask: How does vulnerable driver abuse disable EDR?

Readers often ask: Why does BYOVD ransomware matter for remote work and IT?

Readers often ask: Is a system safe when EDR is installed?

Readers often ask: What should IT teams verify first regarding BYOVD ransomware?

Last reviewed: April 6, 2026