EDR & AV defenses aren’t dying, they are being turned off!
For two decades we built security that assumed the endpoint could be trusted long enough to detect, alert, and remediate. Today adversaries are doing something simpler and much more effective: they turn off the endpoint’s defenses at kernel level, then run ransomware. This is not a corner-case — multiple vendor reports and national advisories show entire ransomware ecosystems are shipping tools that neutralize top commercial EDRs and Microsoft Defender before the encryptor even touches files. If your protection can be switched off, detection becomes useless.
What happened
Security vendors and incident responders have observed ransomware operators using shared “EDR-killer” tooling and BYOVD techniques to disable antivirus and endpoint agents, then deploy encryption and exfiltration in the same kill chain. As Trend Micro summarized for RansomHub: “the ransomware’s attack chain includes tools that disable EDR and AV protections as a deliberate step.”
Technically — what happened
What the update/tool does:
Writes or installs a legitimate (signed) but vulnerable kernel driver (or a trojanized pair of drivers). The vulnerable driver is used to escalate to kernel privileges (BYOVD).
From kernel space, the attacker either removes/overrides kernel hooks used by EDR or terminates/unloads security drivers and services — effectively “blinding” endpoint protections. Researchers describe tools that search for known vendor signatures in driver metadata and then strip or disable their kernel-level hooks.
Once protections are removed, the standard follow-on actions occur: credential theft, lateral movement and fast encryption/exfiltration.
How was this possible (root causes):
Signed drivers and legacy kernel drivers remain an available attack vector; attackers prefer legally signed drivers because the OS allows them to load into kernel space.
Vendors historically focused on detection/response rather than absolute prevention in kernel space; many EDR models trust the kernel stack at least long enough to get telemetry. That trust model is broken when adversaries get kernel privileges.
Tool re-use and sharing among ransomware affiliates (tooling commoditization) makes sophisticated techniques accessible at scale. Sophos and others have observed the same tamper tools used by multiple gangs.
What’s flawed about current defenses:
Reactive alerts require humans; encryption and exfiltration can happen in minutes. If the agent that raises alerts can be killed, detection comes too late. Vendors selling “better telemetry” don’t solve the fundamental problem that the process doing telemetry can be terminated or blinded.
Examples of attacks (verified reports)
RansomHub / EDRKillShifter — Trend Micro documented RansomHub using tooling (EDRKillShifter variants) to disable endpoint and AV protections as part of its attack chain.
Akira / RWDRV.SYS BYOVD — GuidePoint reported Akira affiliates abusing a legitimate Intel/ThrottleStop driver (rwdrv.sys) and loading a secondary malicious driver to disable Microsoft Defender (modify registry
DisableAntiSpyware) — a classic BYOVD pattern.Crypto24 / RealBlindingEDR — Reported by Trend Micro and echoed in industry press: Crypto24 uses bespoke tools to find EDR/AV kernel hooks and disable them prior to payload execution.
Multiple gangs re-using the same tooling — Sophos and Security Boulevard reported the same “EDR killer” families appearing with Blacksuit, Medusa, Qilin and others — indicating sharin/commoditization.
Risks to (who/what)
End users & desktops: Defender/EDR tampering leads to silent compromise and credential theft.
Server & domain controllers: Kernel access enables domain-wide damage, shadow copy deletion, and faster encryption.
Cloud workloads & hybrid environments: Endpoint disablement on hybrid hosts can be an entry for lateral movement into cloud management tools and data exfiltration (connects to risks CNAPP aims to govern).
Entire verticals: Manufacturing, finance, healthcare and critical infrastructure were called out in vendor analyses as targeted sectors.
Active threats (observed)
Akira (affiliates) — BYOVD with ThrottleStop driver (rwdrv.sys) observed.
RansomHub / Water Bakunawa — EDRKillShifter variants in use.
Crypto24 — custom EDR-blinding tooling, living-off-the-land.
Blacksuit, Medusa, Qilin, INC — reported using shared tools in some vendor writeups.
Criticality score (CISO scale 1–10): 9 / 10
Why 9: multiple reputable vendors and a national advisory report real, in-the-wild use of tools that neutralize endpoint defenses (Sophos, Trend Micro, ESET, GuidePoint, CSA Singapore). The technique directly undermines the primary control used by most organizations to detect/respond on host endpoints; it’s fast, repeatable, being reused across gangs, and leverages legitimate OS behavior (driver loading) — all factors that increase impact and reduce easy mitigations. The only reason not a 10: there are effective mitigations (WDAC driver blocklist, tamper protections, HVCI, kernel-level containment), but they are not universally implemented
Why it matters (impact)
Loss of visibility: killing EDR removes telemetry and hides the attack.
Speed of destruction: modern ransomware and exfiltration chains often complete in minutes once protections are disabled. Detection-only models fail.
Consolidated ROI for attackers: shared tooling means less technical barrier and higher campaign velocity.
Regulatory & reputational fallout: encrypted customer data, breached backups, and delayed reporting create legal and brand consequences. (Ransomware guidance from CISA/NIST applies.)
Organizational response (immediate playbook items)
Assume compromise for hosts that show indicators — isolate, capture forensic images, preserve logs. CISA
Enable tamper protection tenant-wide (e.g., Microsoft Defender tamper protections) and ensure policies can’t be overridden by deprecated configuration channels.
Enable the Microsoft Vulnerable Driver Blocklist (WDAC rules) and test for compatibility. Block known risky drivers at the OS level where possible.
Use verified backups & air-gapped recovery plans — follow CISA/NIST ransomware response checklists.
Engage incident response and law enforcement if impacted; follow the CISA ransomware checklist.
What you can do now — prioritized
Hard emergency settings: turn on tamper protection; apply Vulnerable Driver Blocklist/WDAC; enable HVCI / Memory Integrity & Secure Boot where supported.
Reduce admin blast radius: remove local admin rights, enforce least privilege, strengthen service account protections.
Allow-list critical processes & adopt default-deny policies: application allow-listing prevents unexpected binary execution even if kernel tricks are attempted. (WDAC / AppLocker / commercial allow-listers.)
Hunt for Indicators of BYOVD: known driver names, unexpected signed drivers, registry keys toggling Defender settings, abnormal kernel driver load events. Use vendor IoCs when available (GuidePoint published YARA/IoCs for Akira).
Test restore & run tabletop exercises that assume EDR is offline to validate backups and manual recovery. CISA
Mitigation strategies (technical, defensive, vendor choices)
Kernel-level prevention / containment (why it helps): Kernel API virtualization (the model Warden claims) intercepts kernel calls and provides a virtualized interface so untrusted code cannot directly call sensitive kernel APIs. That stops code which gains kernel privileges from doing dangerous OS operations in the normal kernel path — it enforces prevention rather than telemetry. Cyber Strategy Institute’s Warden pages and buyer guides describe this approach as default-deny kernel API virtualization and run-time containment. Use this as an additional layer — not a silver bullet.
Harden drivers/OS policy (why it helps): Microsoft’s vulnerable driver blocklist/WDAC and HVCI make it much harder to load legacy/signed vulnerable drivers. Enforce the blocklist, keep HVCI and Secure Boot enabled, and apply vendor guidance.
EDR tamper-resilience & vendor criteria (what to demand):
• Strong tamper-protection that cannot be disabled by local admins without MDM. Microsoft Learn
• Kernel-level self-defense that prevents hooks from being trivially removed (ask vendors for technical details; prefer vendors publishing architecture for tamper-resilience).
• Ability to detect driver-loading anomalies and provide telemetry even when parts of agent are disrupted. Red CanaryCNAPPs for cloud: CNAPPs (Cloud-Native Application Protection Platforms) don’t directly stop host BYOVD attacks, but they prevent code from moving to cloud controls and help detect anomalous cloud actions, risky configurations, and credential abuse that follow a host compromise. Use CNAPPs to close the cloud side of the attack surface while you harden endpoints.
Why Warden (kernel-level containment) + CNAPP is a reasonable architecture
Warden (kernel API virtualization): Prevents unauthorized kernel operations by intercepting and virtualizing OS calls so that even if a driver is loaded, the kernel APIs the attacker expects to use are mediated — default-deny reduces the attacker’s ability to neutralize protections. This directly addresses the problem where attackers obtain kernel access and then disable the EDR stack. (See Warden product pages and buyer guide for architecture/claims.)
CNAPP (cloud-side): After an endpoint is compromised, attackers often pivot to cloud assets or abuse cloud credentials. CNAPP reduces lateral movement and data exfiltration risk in cloud environments by surfacing misconfigurations, risky permissions, and runtime attacks across cloud apps and workloads. In other words: Warden reduces host-level success; CNAPP reduces the blast radius in cloud.
Practical note: Do not rip out your EDR and replace with a single vendor claim. Adopt layered controls: driver blocklist & HVCI, tamper protection, kernel containment (Warden or equivalent), strict identity controls, and CNAPP for cloud visibility.
Strategic truths
Detection without enforced prevention at kernel/runtime is brittle.
Attackers prefer reuse — when a credible tool works it spreads fast.
Signed drivers are a double-edge sword: they enable hardware/OS functionality but are attractive vectors if legacy or vulnerable. CrowdStrike
True resilience combines prevention at host kernel, identity + privilege hygiene, and cloud posture/runtime protection. Palo Alto Network
Summary wrap up (TL;DR)
EDR-killer tooling and BYOVD attacks are real, in-the-wild, and have been observed across multiple ransomware families. Sophos News
They exploit the fundamental assumption many defenses make: that the endpoint agent can be relied upon to report and block. That assumption no longer holds universally.
Short term: enable tamper protection, block vulnerable drivers, reduce admin rights, harden backups, and activate IR playbooks (CISA/NIST guidance).
Medium term: adopt kernel-level containment (e.g., Warden style kernel API virtualization) and CNAPPs for cloud control to shift from detection to prevention.
1) Are EDRs dead?
No. But many EDR agents can be neutralized in production. Attackers increasingly use kernel-level techniques or signed vulnerable drivers to disable EDR/AV before running ransomware — which makes detection-first models brittle. The right response: don’t rip out EDR; layer prevention (driver blocklists, HVCI, kernel containment) on top of it.
2) What exactly is an “EDR-killer” or BYOVD attack?
An “EDR-killer” is tooling that disables or blinds endpoint defense (EDR/antivirus) — often by loading a legitimate but vulnerable driver (BYOVD: Bring-Your-Own-Vulnerable-Driver) to gain kernel privileges and remove kernel hooks or stop security services. Result: no telemetry, then fast payload execution.
3) Which ransomware gangs are using this technique?
Multiple ransomware families and affiliates have been reported re-using EDR-killer tooling. Examples flagged by vendors include RansomHub, Crypto24, Akira (affiliates), Blacksuit, and Medusa. The key point: tooling is being shared, so the technique spreads fast.
4) How fast can attackers disable EDR and cause damage?
Very fast — in many observed incidents the kill/disable step and payload execution happen in minutes, sometimes seconds. Detection that depends on humans reacting will likely be too slow.
5) If my EDR is disabled, how can I still detect the attack?
You need defense-in-depth telemetry: network IDS/flow logs, EDR telemetry forwarded to an external immutable location, SIEM ingestion from sources outside the host, cloud audit logs, and endpoint boot/firmware telemetry. Also hunt for driver load events and registry changes associated with tampering.
6) Can signed drivers be trusted?
No — signing is not a guarantee of safety. Attackers intentionally reuse legitimately signed but vulnerable drivers because the OS allows them into kernel space. Block or control which drivers can load (WDAC/driver blocklist).
7) What are the highest-impact mitigations I can apply immediately?
Turn on tamper protection tenant-wide; enable Microsoft’s Vulnerable Driver Blocklist (WDAC) and App Allow-listing; enforce HVCI/Memory Integrity and Secure Boot where supported; remove unnecessary local admin rights; ensure immutable, tested backups.
8) What should I require from EDR vendors now?
Demand tamper-resilience documentation, kernel-level protection details, proof they can preserve telemetry when partially disabled, and transparency about how they handle driver/hook tampering. If they can’t explain kernel-level defenses, push harder or add compensating controls.
9) Will kernel-level containment (like Warden’s kernel API virtualization) fix this?
Kernel API virtualization addresses the problem class: it mediates sensitive kernel calls so untrusted code can’t perform dangerous operations even with kernel privileges. It’s not a silver bullet — use it as a prevention layer alongside driver blocklists, HVCI, least privilege, and CNAPPs for cloud containment.
10) What role does CNAPP play?
CNAPPs won’t stop a host BYOVD event, but they reduce blast radius if attackers pivot to cloud: they find misconfigurations, risky permissions, and anomalous cloud behaviors that follow a compromise. In short: host prevention + cloud posture = less lateral movement and exfil.
11) If we’re hit, what is the immediate IR checklist?
Isolate affected hosts, preserve forensic images and any external logs, enable incident response playbooks, notify legal/management/law enforcement as required, restore from immutable backups if needed, and hunt for indicators (driver names, reg changes, disabled services) across your estate.
12) How do I hunt for BYOVD indicators?
Search for unexpected signed drivers, unusual driver load events, registry edits disabling Defender or tamper protections, sudden unloads of security drivers, and telemetry gaps. Vendor IoCs (YARA/Sigma) for known gangs are helpful — but assume attackers reuse tooling and look for anomalies.
13) Should I change EDR vendors now?
Only if a vendor cannot demonstrate effective tamper-resilience, kernel-level protections, or the ability to harden telemetry. Don’t change for marketing claims — change based on technical evidence and how the vendor fits into your layered prevention strategy.
14) How do we test our defenses without causing harm?
Run tabletop exercises that assume EDR is offline, test backup restores from immutable snapshots, validate WDAC/App Allow-listing in a controlled pilot, and conduct purple-team tests focusing on driver load and tamper scenarios. Validate recovery time objectives (RTOs) under EDR-down assumptions.
15) What are realistic expectations for prevention vs. detection?
Detection still matters, but prevention must be first class: stop or contain high-impact kernel actions before they can disable security. Aim for layers that prevent rapid destructive actions (driver blocklist, kernel containment, least privilege) and detection layers that don’t rely solely on host agents.
16) Will reducing admin rights and better identity hygiene help?
Yes — significantly. Removing local admin rights and tightening service account permissions reduces the attacker’s ability to load drivers, install services, or change tamper settings. Combine with strong identity controls and MFA for cloud/privileged accounts.
17) What should my board/C-suite hear about this right now?
Say this plainly: “Attackers can and do disable endpoint defenses. Detection-only buys time we may not have. We must invest in prevention and recovery: block risky drivers, enable kernel-level containment, harden identity, and verify immutable backups. We’re treating this as a critical operational risk.” Back that with a plan, timeline, and measurable KPIs.
