Ransomware gangs are moving beyond vulnerable drivers to kill EDR faster

Ransomware crews are no longer relying only on vulnerable drivers to disable endpoint security before launching encryption. New research from ESET shows that attackers now use a broader mix of EDR killers, including script-based tools, legitimate anti-rootkit software, and fully driverless techniques that suspend protections or block their communication without loading a vulnerable driver at all.

That shift matters because it changes how defenders need to think about ransomware intrusions. Blocking a bad driver still helps, but ESET says that approach now catches only one part of a much larger toolset. In many attacks, affiliates already hold high privileges by the time they try to kill EDR, which means defenders need earlier detection and layered controls instead of one last-minute block.

The sample you shared captures the same central trend: modern ransomware actors want a short, reliable window to run encryptors, so they focus their technical effort on disabling security products first rather than making encryptors invisible.

What ESET found

ESET says it tracks almost 90 EDR killers used in the wild across ransomware operations of all sizes. Of those, 54 are based on BYOVD tactics, abusing 35 distinct vulnerable drivers, while 7 are script-based and 15 rely on anti-rootkits or other freely available software. ESET also says 24 of the BYOVD tools do not appear to come from public proof-of-concept code, which suggests some developers built them from scratch.

That is the key change in the market. Attackers still like vulnerable drivers, but they no longer need to stop there. The ecosystem now includes commercial kits, packer-as-a-service tooling, driver swaps across unrelated codebases, and more portable methods that work even when a known driver gets blocked.

Why ransomware actors care so much about EDR killers

ESET describes EDR killers as a predictable stage in modern ransomware operations. Attackers first gain high privileges, then deploy a tool to disrupt protection, and only after that launch the encryptor. That sequence makes sense operationally because it is easier to break security software than to constantly redesign encryptors to evade detection.

The research also says affiliates, not ransomware operators, usually pick the EDR killer. That helps explain why the same ransomware brand can show up with different defense-evasion tooling, and why the same vulnerable driver can appear across unrelated groups. Driver-based attribution alone can mislead investigators because the driver and the actual killer tool often move independently.

What the modern EDR killer landscape looks like

Category	What ESET found	Why it matters
BYOVD tools	54 active tools abusing 35 vulnerable drivers	Still the largest segment, but no longer the only one
Script-based tools	7 active tools	Lower barrier to entry and faster adaptation
Anti-rootkit and other legitimate tools	15 active tools	Abuse of trusted software complicates detection
Commercial offerings	Growing underground market	Makes advanced evasion easier to buy and reuse

ESET says this market now ranges from public proof-of-concept forks to more professional commercial products. That commercial layer matters because it lowers the skill needed for affiliates to deploy hardened EDR killers inside real intrusions.

Examples that stood out

One of the most widely seen commercial tools in ESET’s research is AbyssKiller, which pairs the ABYSSWORKER rootkit with a HeartCrypt-packed loader. ESET says it has observed AbyssKiller used by affiliates linked to Medusa, DragonForce, and the now-disrupted BlackSuit operation.

ESET also says some recently observed tools show traits that strongly suggest AI-assisted development. Its example is an EDR killer used by Warlock that cycles through several unrelated, commonly abused device names until one works, while also including a “Possible fixes” code pattern that ESET says resembles AI-generated boilerplate.

Why blocking vulnerable drivers is not enough anymore

Microsoft still recommends blocking vulnerable drivers, and that remains a necessary control. Microsoft says the vulnerable driver blocklist is designed to harden systems against drivers with known security flaws, malicious behavior, or other behaviors that attackers can exploit to gain kernel privileges. Microsoft also recommends enabling the Attack Surface Reduction rule called “Block abuse of exploited vulnerable signed drivers.”

But Microsoft also warns that the blocklist is not guaranteed to block every vulnerable driver. The company says some blocks may be held back to avoid breaking legitimate software and hardware, which means defenders should not treat the blocklist as a full answer to the problem.

That lines up with ESET’s conclusion. The company says blocking the driver is “a crucial step” but only at the last possible moment, because by then the affiliate often already has the privileges needed to keep trying other tools until one works.

What defenders should do now

• Enable Microsoft’s vulnerable driver blocklist where possible.
• Turn on the ASR rule that blocks abuse of exploited vulnerable signed drivers.
• Monitor for suspicious driver installation events and unexpected kernel-driver loads. This follows directly from both Microsoft’s and ESET’s guidance.
• Watch for anti-rootkit tools or unusual script activity on endpoints that do not normally use them. ESET says attackers now abuse these paths too.
• Reduce standing high-privilege access, because ESET says attackers often deploy EDR killers only after they already hold elevated rights.
• Build layered detection that can catch the intrusion before the encryptor stage, not only at execution time. That is the main defensive takeaway from ESET’s research.

What this means for ransomware defense

The bigger lesson is that ransomware defense now depends as much on stopping defense evasion as on spotting the encryptor itself. ESET says encryptors tend to focus purely on encryption, while EDR killers carry much of the real evasion logic. In practice, that means blue teams need visibility into privilege escalation, driver loads, suspicious admin tooling, script execution, and endpoint tampering long before file encryption begins.

For security teams, this changes the playbook. The old question was whether a malicious driver would get blocked. The newer question is whether the attacker can still silence security another way when that driver fails.

FAQ