Your EDR Is Dead — Now What? Why Deception Is the Detection Layer That Survives EDR Killers

In February 2026, Reynolds ransomware did something that reset the rules for endpoint security: it bundled a vulnerable kernel driver directly inside the ransomware payload. No separate EDR killer tool. No extra deployment step. The instant the ransomware executed, it loaded a signed NsecSoft NSecKrnl driver (CVE-2025-68947), used it to terminate processes for CrowdStrike Falcon, Palo Alto Cortex XDR, Sophos, Symantec, and Avast, then encrypted everything. Time from execution to EDR blindness: seconds.

I spend a lot of time reverse-engineering how these payloads actually get kernel access, and Reynolds isn't a one-off innovation. It's the culmination of a trend that's been accelerating for over two years. EDR killers — purpose-built tools that neutralize endpoint security before the real attack starts — have gone from advanced threat actor tradecraft to commoditized, affiliate-friendly tooling spread across the ransomware ecosystem.

The numbers tell the story. A single BYOVD (Bring Your Own Vulnerable Driver) campaign using the TrueSight driver deployed over 2,500 driver variants between mid-2024 and early 2025. EDRKillShifter, originally built for RansomHub, has been adopted by Play, BianLian, and Medusa operations. In August 2025, one custom EDR killer binary turned up in use by at least eight ransomware gangs at once: Blacksuit, RansomHug, Medusa, Qilin, Dragonforce, Crytox, Lynx, and INC. A Huntress investigation in February 2026 found attackers using compromised SonicWall VPN credentials and then deploying an EDR killer that abused a revoked EnCase forensic driver, which Windows still allowed to load despite its expired certificate.

The CrowdStrike 2026 Global Threat Report confirms that 82% of detections are now malware-free. When the 18% that does involve malware shows up, it increasingly arrives ready to kill your detection stack first.

If your security strategy treats EDR as the final line of defense, you've built a single point of failure. And ransomware operators know exactly how to exploit it.

How EDR killers actually work

Understanding the mechanics explains why these attacks succeed and why the usual countermeasures keep coming up short. This is the part I find defenders most often underestimate.

BYOVD: the dominant technique

The most prevalent EDR killer method is Bring Your Own Vulnerable Driver. The attacker drops a legitimate, digitally signed Windows kernel driver that happens to contain a known vulnerability. Because the driver carries a valid signature, Windows loads it with kernel-level privileges. The attacker then exploits the flaw in the driver to terminate EDR processes, unregister kernel callbacks, or suppress telemetry.

This is devastating because it turns the operating system's own trust model against the defender. Windows trusts the signed driver. The driver runs in kernel mode. From kernel mode, it can kill any process on the system, including your EDR agent. Symantec and Carbon Black researchers noted that Reynolds ransomware bundles the defense evasion component directly with the payload, erasing the detection window defenders used to get when EDR killers shipped as separate tools.

The list of vulnerable drivers being abused reads like a who's who of legitimate software: RTCore64.sys (MSI Afterburner), TrueSight.sys, PROCEXP.SYS (Process Explorer), aswArPot.sys (Avast anti-rootkit), the EnCase forensic driver, NSecKrnl.sys (NsecSoft), IMFForceDelete.sys (IObit Malware Fighter), BdApiUtil.sys (Baidu Antivirus), and GameDriverx64.sys (an anti-cheat driver). Each one is signed, legitimate, and trusted by Windows, and each contains vulnerabilities attackers exploit to gain kernel access.

EDR killer tooling goes mainstream

What used to belong to sophisticated APT groups is now commodity. EDRKillShifter uses BYOVD to terminate endpoint security processes and has been shared across competing ransomware operations. The Terminator tool and its variants abuse Zemana drivers. AuKill exploits the Process Explorer driver. The Singapore CSA issued an advisory specifically about a shared EDR killer framework that uses HeartCrypt packing, random driver name generation, and stolen code-signing certificates, a collaborative development model where multiple ransomware groups share and improve the same tool. We took apart that packer in our look at HeartCrypt as an EDR killer ransomware weapon.

The VEN0m ransomware project, openly published on GitHub in February 2026 and tested against Windows 11 Pro 24H2, shows how accessible this capability has become. It exploits CVE-2025-26125 in an IObit driver that still isn't on Microsoft's blocklist as of the test date. The barrier to entry has never been lower.

Beyond BYOVD: the expanding arsenal

BYOVD isn't the only play. EDR Silencer blocks EDR network traffic through the Windows Filtering Platform. Direct and indirect syscall techniques bypass user-mode API hooks entirely. On Linux, the RingReaper agent abuses the io_uring kernel interface to run operations invisible to traditional Linux EDR syscall monitoring. When Akira ransomware's payload was quarantined by EDR on a Windows endpoint, the attackers simply pivoted to an unmonitored Linux-based webcam on the same network and encrypted from there.

The message is clear: EDR evasion is no longer a specialized skill. It's a standard feature in the modern ransomware toolkit, and the techniques evolve faster than vendor mitigations can keep up.

Why deception survives when EDR dies

Here's the critical insight. EDR killers target one specific class of security tool: endpoint agents that run as processes on the operating system. They kill processes. They unregister callbacks. They suppress telemetry. They operate entirely inside the endpoint's OS.

Honeytokens and deception technology operate on a different plane. They don't depend on endpoint agents. They don't run as processes you can terminate. They don't rely on kernel callbacks you can unregister. A honeytoken is a piece of data: a fake credential, a decoy document, a bogus API key, planted in your environment. No agent. No process. No driver. There's nothing for an EDR killer to kill.

When an attacker fires Reynolds ransomware and the BYOVD driver terminates CrowdStrike, Sophos, and Cortex XDR in the first seconds, every honeytoken in the environment stays fully operational. Every decoy service keeps listening. Every fake credential keeps waiting. The detection layer that doesn't live on the endpoint is the one that survives.

Honeytokens detect what happens before EDR gets killed

EDR killers deploy mid-to-late in the intrusion chain, after initial access, after credential theft, after lateral movement. The attacker needs privileged access to load a kernel driver. That means an entire attack sequence precedes the EDR kill: phishing, credential harvesting, privilege escalation, network reconnaissance, lateral movement.

Mine2 honeytokens fire during those earlier phases. Credential honeytokens planted in browser stores, config files, and documentation catch the initial credential harvesting. MineField decoy services catch the network reconnaissance. Active Directory decoy accounts catch the privilege escalation probing. By the time the attacker is ready to deploy the EDR killer, the honeytokens have already triggered, handing your team the alert they need to contain the intrusion before the kill shot lands. Our walkthrough of stopping ransomware during lateral movement with deception maps those pre-kill phases in detail.

MineField decoy services operate at the network layer

Mine2's MineField deploys decoy TCP services across your network. These aren't endpoint processes. They're network-level tripwires that detect scanning, lateral movement, and service enumeration. An EDR killer that terminates processes on a compromised endpoint has zero effect on MineField decoys running elsewhere. When the attacker pivots from the blinded endpoint to the next target, MineField catches the movement.

Cloud Mines exist outside the endpoint entirely

Mine2's Cloud Mines — fake AWS resources, phantom S3 buckets, honeytoken IAM credentials — live in your cloud environment, not on any endpoint. They detect cloud credential abuse, resource enumeration, and cross-environment pivots. No BYOVD driver, however privileged, can touch cloud-based deception assets. When ransomware operators shift from on-prem targets to cloud storage (a trend Symantec researchers flagged with attacks on misconfigured S3 buckets), Cloud Mines are already in position.

Fortify hardens what EDR killers exploit

Mine2's Fortify goes after the root cause of BYOVD success: weak driver governance, unnecessary privileges, exposed attack surfaces. Fortify finds the misconfigurations that enable EDR killers — unsigned driver loading allowed, outdated vulnerable drivers present, service accounts with unnecessary kernel access — and gives you remediation guidance to close those gaps before attackers exploit them.

A practical playbook: surviving the EDR killer era

1. Layer deception behind your EDR

Don't wait for EDR to fail before you deploy detection alternatives. Plant honeytokens now: credential honeytokens in the places attackers harvest (browser stores, config files, environment variables), MineField decoys on critical network segments, and Cloud Mines in your cloud environments. While EDR is working, honeytokens add coverage. When EDR is killed, honeytokens become your primary detection layer.

2. Focus honeytokens on the pre-kill chain phases

EDR killers deploy after the attacker already has privileged access. That means credential theft, lateral movement, and privilege escalation have already happened. Deploy honeytokens aimed at those earlier phases: decoy domain admin credentials in LSASS-accessible locations, fake service accounts in Active Directory, honeytoken API keys in code repositories. Catch the attacker during the phases that precede EDR termination. The infostealer epidemic and MFA bypass shows how those credentials get harvested in the first place.

3. Deploy MineField on segments your EDR agents protect

Place decoy services on the same network segments where your endpoints run EDR agents. When an attacker kills EDR on a compromised host and starts lateral movement, MineField catches the scan. The blinded endpoint can't see the movement, but the network-level deception layer can.

4. Harden driver governance with Fortify

Use Fortify to enforce driver blocklists, enable HVCI (Hypervisor-Protected Code Integrity) where possible, restrict driver loading to signed and known-good drivers, and watch for suspicious .sys file creation in user-writable directories. Shrinking the BYOVD attack surface makes the EDR kill harder to pull off in the first place.

5. Treat EDR silence as a deception-validated signal

Configure your SIEM to alert on EDR agent silence, when an endpoint stops sending telemetry. Correlate that silence with honeytoken alerts: if an endpoint goes quiet at the same moment a honeytoken fires on the same segment, you have high-confidence evidence of an active intrusion with EDR-kill capability. That correlation turns the absence of EDR signal from a monitoring gap into an actionable indicator.

6. Test your deception layer against EDR kill scenarios

Run tabletop exercises and purple team drills that simulate EDR termination. Disable EDR agents on test endpoints and confirm that honeytoken and MineField alerts still fire when the simulated attacker performs post-compromise activities. Prove your deception layer works independently of your endpoint security stack.

Where this leaves your detection strategy

The EDR killer era is here. BYOVD is no longer an advanced technique. It's embedded directly in ransomware payloads, shared across competing affiliate programs, and available to anyone with a GitHub account. When a signed kernel driver can terminate CrowdStrike, Sophos, Cortex XDR, and Symantec in seconds, any strategy that leans solely on endpoint agents has a single point of failure.

Deception technology doesn't carry that weakness. Honeytokens aren't processes you can terminate. MineField decoys aren't kernel callbacks you can unregister. Cloud Mines don't run on endpoints you can wipe. They exist as data and network-level tripwires that operate completely independently of your endpoint security stack.

When Reynolds ransomware kills your EDR, your honeytokens are still watching. When EDRKillShifter terminates your endpoint agent, your MineField decoys are still listening. When a BYOVD driver blinds every endpoint in the domain, your Cloud Mines are still detecting.

When attackers routinely kill the security tools built to catch them, the detection layer that survives is the one with nothing to kill.

---

Don't let EDR killers blind your entire stack. Deploy Mine2's deception layer, the detection that survives when EDR doesn't →