54 EDR Killers: Why Attackers Target Security Before Ransomware

What happens when cybercriminals stop trying to hide ransomware and instead focus on disabling the security software meant to catch it?

That is the troubling direction highlighted in research published by ESET in March 2026. Researchers tracked nearly 90 tools designed to interfere with endpoint detection and response (EDR), including 54 tools that abused 35 vulnerable signed Windows drivers.

For business owners and MSPs, the implication is significant: installing endpoint protection does not necessarily mean that protection will remain operational when attackers need it disabled most.

Key Takeaway: Cybercriminals increasingly treat disabling endpoint protection as a specialized stage of ransomware attacks. Businesses and MSPs need to evaluate not just whether their EDR detects threats, but whether Windows endpoints can resist tampering and destructive actions when detection is disrupted.

So what exactly did researchers discover?

ESET found an established ecosystem of tools developed to interfere with security products before ransomware executes.

Its March 2026 research documented nearly 90 EDR-killer tools, including 54 using Bring Your Own Vulnerable Driver (BYOVD) techniques involving 35 vulnerable drivers. It also described script-based tools and attackers' use of existing anti-rootkit utilities.

These numbers describe researchers' observed tooling, not the number of organizations compromised or successful attacks.

The research suggests that disabling endpoint protection has become a specialized cybercriminal capability rather than an unusual feature of a single ransomware family. Read the original ESET research and The Hacker News coverage.

Why would attackers disable security software before launching ransomware?

Disabling security software can create an opportunity for ransomware to execute with fewer active defenses.

Modern EDR products monitor processes, suspicious behavior, and other indicators of compromise. Rather than only changing their ransomware to evade detection, criminals may use a separate tool to interfere with security first.

For businesses, this challenges an important assumption. Endpoint security may be functioning during normal operations, yet an attacker may deliberately attempt to compromise that protection before beginning the most destructive phase of an intrusion.

How can a legitimate Windows driver become an attack weapon?

A digitally signed driver can still contain vulnerabilities that attackers exploit to obtain privileged access to Windows.

BYOVD attacks involve introducing a legitimate but vulnerable driver, then exploiting its weakness to interfere with protected processes or security functions. Because drivers operate close to the operating system's core, the resulting access can be powerful.

Not every EDR killer uses a vulnerable driver. Attackers may also abuse administrative commands, legitimate utilities, or other mechanisms that interfere with endpoint monitoring.

Blocking a particular driver is valuable, but it cannot eliminate every method of disabling security.

Could AI make these attacks harder to defend against?

AI may lower the effort needed to modify attack tools, but identifying whether a specific malicious program was developed using AI remains difficult.

Researchers have described characteristics consistent with AI assistance in some malicious tooling, but these observations should not be treated as proof of how every tool was developed.

The business concern is broader: attackers can change code, switch drivers, reuse exploits, and experiment with new techniques. Maintaining detection for every possible variation becomes difficult.

Changing the attack does not necessarily change the endpoint actions the attacker ultimately needs in order to succeed.

Whether created with AI or traditional methods, an EDR killer still needs a way to manipulate processes, exploit privileged components, change system behavior, or disrupt security communications. Those actions can be constrained independently of knowing the attacker's particular tool.

What should MSPs test beyond whether EDR detects malware?

MSPs should test whether endpoint defenses remain effective when adversaries attempt to disable, bypass, or disconnect security software.

A successful ransomware detection demonstration does not, by itself, establish endpoint resilience. Practical evaluation should include:

• Tamper resistance: Can compromised accounts stop protection services or change security settings?
• Driver protection: Are vulnerable-driver blocking and supported Windows memory-integrity controls enabled and validated?
• Connectivity: What happens when an endpoint loses communication with the EDR management platform?
• Alerting: Does the MSP receive actionable notifications when protection becomes unhealthy or goes offline?
• Behavior restrictions: Can out-of-bounds endpoint actions still be prevented when detection is disrupted?
• Recovery: Can the MSP promptly isolate affected devices and restore trusted protection?

Microsoft provides guidance on vulnerable-driver block rules. Driver restrictions and related Windows defenses need compatibility testing, and no blocklist can be assumed comprehensive.

Can an attack be stopped without first identifying it?

Yes. Preventive endpoint controls can restrict certain dangerous actions without requiring the specific attack tool to be recognized as malicious.

What if you did not have to detect the attack in order to stop it?

This is where Isolation and Containment add an important layer. Instead of relying entirely on recognizing malicious files, scripts, or behavior, they establish guardrails around what applications and processes can do.

Depending on configuration, such controls can restrict application execution, access to sensitive memory, modification of protected resources, and other actions attackers need to advance an intrusion.

AppGuard is a proven endpoint protection solution with more than a decade of production history focused on prevention through Isolation and Containment. It restricts out-of-bounds endpoint behavior without requiring every attack to be identified first.

AppGuard does not replace EDR, guarantee prevention of every attack, or remove the need for driver hardening and monitoring. The point is to add prevention layers that reduce the usable Windows endpoint attack surface.

The attack may be new. The actions it needs to perform on a Windows endpoint often are not.

What Should Businesses Do Next?

Businesses and MSPs should treat deliberate attacks against endpoint protection as a realistic scenario in their security planning.

• Verify endpoint health. Monitor tamper events, missing telemetry, and unexpected security-service changes.
• Harden Windows driver protection. Evaluate vulnerable-driver blocking, memory integrity, and related Microsoft security settings.
• Test controlled EDR-failure scenarios. Validate alerting, isolation, and recovery using authorized nonproduction environments.
• Reduce execution freedom. Constrain unnecessary application privileges and out-of-bounds behavior.
• Add Isolation and Containment where appropriate. Evaluate prevention that works independently of identifying the threat.
• Review privileged access and recovery. Make it harder for one endpoint compromise to become widespread administrative control.

These checks should become part of ongoing endpoint resilience assessments, not one-time product evaluations.

The Bottom Line: Protect the Endpoint, Not Just the Security Tool

ESET's research shows that defeating security software has become a specialized attack capability in its own right.

Detect and Respond remains essential. But an effective strategy should not assume detection will always be operational or that every attacker technique will be recognized in time.

Unknown does not automatically mean unstoppable. The objective is not to predict every attack. It is to restrict the actions an attacker needs in order to succeed.

For a related discussion, listen to the CHIPS Cybersecurity Podcast: The Detect and Respond Mirage.