EDR killers explained: Beyond the drivers

In recent years, EDR killers have become one of the most commonly seen tools in modern ransomware intrusions: an attacker acquires high privileges, deploys such a tool to disrupt protection, and only then launches the encryptor. Besides the dominating Bring Your Own Vulnerable Driver (BYOVD) technique, we also see attackers frequently abusing legitimate anti-rootkit utilities or using driverless approaches to block the communication of endpoint detection and response (EDR) software or suspend it in place. These tools are not just plentiful, but also behave predictably and consistently, which is precisely why affiliates reach for them.

In this blogpost, we present our view of EDR killers, grounded in ESET telemetry and incident investigations. The research is based on the analysis and tracking of almost 90 EDR killers actively used in the wild. Our focus goes beyond the vulnerable drivers that dominate most discussions: we document how affiliates select, adapt, and operate EDR killers across real intrusions, and what that means for attribution and defense.

We explain why driver-centric analysis often misleads group attribution, show concrete cases of driver reuse and switching across unrelated codebases, and highlight the growth of driverless disruption alongside commercialized, hardened kits. The result is a clear, evidence-based picture of how EDR killers function as a predictable stage in modern ransomware operations.

Key points of this blogpost:

• EDR killers are a fundamental part of modern ransomware intrusions; affiliates prefer a short, reliable window to run encryptors rather than constantly modifying payloads.
• Affiliates, not operators, pick the EDR killers; larger affiliate pools lead to greater tooling diversity.
• The same driver appears in unrelated tools, and the same tool can migrate between drivers. Consequently, driver-based attribution to groups is often misleading.
• Packer as a service and “EDR killer as a product” increase availability, muddy attribution, and add defense complexity.
• EDR killers implement defense evasion techniques, while encryptors focus purely on encryption.
• We strongly suspect that AI assisted with the development of some EDR killers, and we provide a concrete example with the Warlock gang.
• While BYOVD dominates, custom scripts, anti-rootkits, and driverless EDR killers are utilized as well.

The EDR killer landscape

ESET researchers focus beyond the vulnerable drivers so often abused by these tools. As we will demonstrate, drawing any connections solely based on the misused drivers is insufficient and can lead to incorrect assumptions.

The landscape this research unveils is massive, ranging from endless forking of proofs of concept (PoCs) to complex professional implementations. Focusing on commercial EDR killers (advertised on the dark net) allows us to gain a better understanding of their customer base and spot otherwise hidden affiliations. In-house developed EDR killers offer insights into the inner workings of closed groups. Furthermore, vibe coding is making matters even more complicated. We provide a technical overview of EDR killers, including vulnerable drivers, in the The technology behind EDR killers section.

At the time of writing, our insight into the EDR killer landscape is based on the following:

• We detect a total of almost 90 EDR killers actively used in the wild by basically any ransomware gang, big or small:

  ○  54 of these are BYOVD-based, abusing a total of 35 vulnerable drivers,

  ○  7 of these are script-based, and

  ○  15 of these are anti-rootkits or other freely available software.

• For 24 of the BYOVD-based EDR killers, we are not aware of a publicly available PoC they are based on; we assess that their developers implemented these tools from scratch and were inspired only by the driver exploitation code.

Throughout this blogpost, we refer to entities forming the ransomware-as-a-service model as follows:

• Operators, who develop the ransomware payload, manage decryption keys, maintain the dedicated leak site, often negotiate the ransom payment with victims, and offer other tooling and services for a monthly fee or a percentage from the ransom payment (typically 5–20%).
• Affiliates, who rent ransomware services from operators, deploy encryptors to victims’ networks, and exfiltrate data from victims’ machines.

Why are EDR killers so popular?

To successfully encrypt data, ransomware encryptors need to evade detection. Nowadays, a wide range of mature evasion techniques is available, ranging from packing and code virtualization to sophisticated injection. However, we rarely see any of these implemented in encryptors. Instead, ransomware attackers opt for EDR killers to disrupt security solutions right before encryptor deployment. This different approach naturally raises the question: why not rather invest into making encryptors undetected?

Reliability and operational simplicity for encryptor developers

Ransomware gangs, especially those with ransomware-as-a-service (RaaS) programs, frequently produce new builds of their encryptors, and ensuring that each new build is reliably undetected can be time-consuming. More importantly, encryptors are inherently very noisy (as they inherently need to modify a large number of files in a short period); making such malware undetected is rather challenging. EDR killers provide a cleaner alternative. Instead of burying detection-evading logic inside every encryptor update, attackers simply rely on an external tool to disrupt or disable security controls immediately before execution, keeping encryptors simple, stable, and easy to rebuild.

Low cost, high power

As shown throughout this blogpost, EDR killers are extremely accessible. Not all intruders or affiliates have the skill set to develop their own defense evasion strategies. But thanks to large collections of public PoCs, EDR killers have essentially become “plug-and-play”.

At the same time, EDR killers often rely on legitimate yet vulnerable drivers, making defense significantly more difficult without risking disruption of legacy or enterprise software. The result is a class of tools that offers kernel-level impact with minimal development effort, making these tools disproportionately powerful given their simplicity.

Predictability and repeatability during intrusions

Packing or injecting code may help an implant slip past detection, but it doesn’t ensure the long-term stability of the ransomware payload during the final phase of the intrusion. Due to the layered protection provided by security products, packed encryptors may still be detected in memory or at other stages of execution. EDR killers, on the other hand, provide a predictable and repeatable step in the attack chain, giving attackers a more deterministic workflow. Furthermore, EDR killers aim to disrupt the security solution as a whole, effectively getting rid of all protection layers.

The technology behind EDR killers

Scripts

The simplest EDR killers don’t rely on vulnerable drivers or other advanced techniques. Instead, they abuse built-in administrative tools and commands such as taskkill, net stop, or sc delete to tamper with security product processes and services. These crude approaches still appear occasionally but are now mostly associated with low-skill ransomware threat actors and commodity malware.

Slightly more sophisticated variants combine scripting with Windows Safe Mode. Since Safe Mode loads only a minimal subset of the operating system, and security solutions typically aren’t included, malware has a higher chance of disabling protection. At the same time, such activity is very noisy, as it requires a reboot, which is risky and unreliable in unknown environments. Therefore, it is seen only rarely in the wild.

Gray zone: Anti-rootkits

Years ago, before Microsoft enforced kernel-mode driver signing, rootkits flourished in the cybercrime ecosystem, hiding malicious activity by manipulating kernel structures. Their prevalence led to the development of specialized anti-rootkit tools designed to detect and remove them. Because rootkits operate in kernel mode, such tools naturally require high privileges and their own drivers to discover, enumerate, and neutralize the rootkits.

Today, ransomware affiliates frequently abuse these same anti-rootkit tools: not to remove rootkits, but to cripple security solutions. Many anti-rootkits offer a user-friendly GUI that allows users (including attackers with little technical capability) to terminate protected processes or services. In other words, legitimate remediation tools have become convenient EDR killers when misused. Such tools include GMER (see Figure 1), HRSword, and PC Hunter.

Rootkits

Although rootkits are largely rare in modern cybercrime, notable exceptions still surface. One example from last year is ABYSSWORKER, a kernel-mode rootkit that drew attention after its creators managed to sign it using certificates stolen from Chinese companies. These certificates had also been used to sign other malware and are therefore not specific to ABYSSWORKER. Since the stolen certificates belong to a trusted certificate chain, such a driver is still allowed to run in the kernel. And, to make matters more complicated, even certificate revocation is not a bulletproof option, as recently demonstrated by Huntress.

Vulnerable drivers

The BYOVD technique has become the hallmark of modern EDR killers: dominant, reliable, and widely used. In a typical scenario, an attacker drops a legitimate but vulnerable driver onto the victim machine, installs the driver, and then runs malware that abuses the driver’s vulnerability. The goal is to terminate protected processes or disable callbacks that security products rely on.

Although there are thousands of legitimate vulnerable drivers, only a comparatively small subset is actively exploited in ransomware incidents. However, the availability of public PoCs means that there is effectively no limit on the number of threat actors that can adopt or adapt exploits for these vulnerabilities. Some attackers reuse existing codebases with minimal or no changes, others change no logic but reimplement them in their preferred programming language, and some even develop entirely new EDR killers (keeping only a small portion of the original code responsible for driver exploitation) that they either use on their own or offer as a service.

Driverless EDR killers

Finally, a smaller but growing class of EDR killers achieves its goals without touching the kernel at all. Instead of terminating EDR processes, these tools interfere with other critical features. Examples include tools like EDRSilencer, which blocks communication between an endpoint and its security backend, and EDR-Freeze, which causes EDR processes to “hang” or become unresponsive. These driverless techniques are popular because their unconventional approach makes detection and mitigation more challenging, and they are publicly available. Indeed, ESET researchers have seen quick adoption of these tools in a matter of days by ransomware threat actors.

Who develops EDR killers?

In 2025, ESET researchers published an analysis of EDRKillShifter, an EDR killer developed by RansomHub operators and offered directly to their affiliates. At the time of writing, we are not aware of any other RaaS programs whose operators provide their own proprietary EDR killers. This makes the now-defunct RansomHub a notable exception in the ransomware landscape.

Instead, most threat actors fall into one of the following categories:

• non-RaaS gangs developing their own EDR killers,
• attackers forking and slightly modifying public proof-of-concept code, or
• attackers purchasing an EDR killer from underground marketplaces.

Let’s break these situations down in more detail.

Closed groups

Non-RaaS gangs usually operate as fully closed ecosystems: no affiliates, no initial access brokers, and no external partners. These groups maintain tight control over their intrusion workflows and typically rely on a repeatable, internally consistent set of TTPs. Given this level of operational discipline, developing their own EDR killers becomes a natural extension of their toolset.

ESET researchers highlighted an early example of this in-house development model in 2024 with the Embargo gang. At the time, Embargo relied on two EDR killers:

• a custom Safe Mode script, leveraging the technique already described earlier, and
• MS4Killer, a tool inspired by the publicly available s4killer PoC.

Although MS4Killer was based on an available PoC, its developers made significant changes: they added parallelism, modified the code flow, and encrypted strings and the embedded driver. Since the publication of that research, Embargo has shifted to yet another public PoC, evil‑mhyprot‑cli, this time with minimal code modifications.

A second, more recent, example is the DeadLock gang. DeadLock maintains a low profile by avoiding having a dedicated leak site and conducting all negotiations through Session, a popular alternative to the more common Tox. ESET researchers have observed DeadLock using two EDR killers, DLKiller (also mentioned as an unnamed loader by Cisco Talos) and Susanoo, and anti-rootkits such as GMER and PC Hunter. ESET researchers believe with low confidence that DLKiller and the DeadLock encryptor are the work of the same developer due to notable, but on its own inconclusive, code similarities. Interestingly, Susanoo provides a loading screen and a GUI, both presented in Figure 2, allowing for manual interaction and expecting the attacker to have interactive access to the victim’s machine.

As the screenshot clearly demonstrates, Susanoo offers buttons to pre-load the list of monitored processes – a dedicated one targeting Sophos-related processes and a “TNT” one targeting all processes known to Susanoo.

The third and final example is Warlock. Although the Warlock leak site has been silent since November 6^th, 2025, the group remains operational and keeps expanding its technical arsenal. The gang is known for its willingness to experiment: it adapted the VS Code abuse technique for stealthy remote access, previously documented in September 2024 and used by the Mustang Panda APT group, while also pioneering the malicious use of Velociraptor. Ever since, Warlock has consistently relied on these techniques. Its approach to encryptors mirrors this pattern as well – Warlock has employed multiple different encryptors over time, ranging from custom ones to variants based on Babyk or generated using the leaked LockBit Black builder.

Given all that, Warlock’s experimentation with EDR killers is not surprising. Since the gang first appeared, it has routinely deployed multiple EDR killers per intrusion, sometimes even dozens during recent operations, effectively brute-forcing its way to a working solution. Warlock’s tooling is diverse not only in quantity but also in technical depth: the gang does not limit itself to a single vulnerable driver and has abused at least nine different drivers to date, including some without any publicly available PoC (at least to our knowledge); a detail that underscores the group’s technical proficiency and its ability to adapt offensive tools beyond what is readily publicly available.

Modification of a PoC

This is by far the most common approach observed in ransomware intrusions. Threat actors frequently take an existing, well-tested PoC, and adjust only the noncritical components before deploying it in real attacks. These modifications typically include:

• removing or altering debugging messages,
• adding code obfuscation,
• adjusting the list of targeted security products, and
• rewriting the tool in a different programming language.

The crucial point, however, is that the core exploitation logic, especially the part that interacts with the vulnerable driver, almost never changes. This logic is often as simple as calling the Windows API DeviceIoControl with a “correct” dwIoControlCode value and the name of the process to terminate in lpInBuffer. While renaming strings, restructuring the codebase, or reimplementing the tool in another language are operations that don’t require deep technical knowledge, modifying the exploitation logic certainly is and therefore is typically avoided.

While there are many publicly available PoCs for EDR killers, one repository stands out: BlackSnufkin’s BYOVD. Regularly updated, it contains (at the time of writing) PoCs for exploiting 10 vulnerable drivers, each implemented following the same modular template. The implementation allows for easy modifications, extensions, and new driver support. Furthermore, the code is well documented (see Figure 3), making this repository the most frequently used one in ransomware activity in the wild.

We detected one of BlackSnufkin’s EDR killers, TfSysMon-Killer, deployed during a Monti ransomware attack in February 2025; the deployed variant was identical functionality-wise, but was reimplemented from Rust to C++, likely to align with other tools of the threat actor. Another example of language switching is dead-av, which its author openly describes as a Go rewrite of GhostDriver, another PoC created by BlackSnufkin.

A more extensive modification effort can be seen in SmilingKiller, an EDR killer recently observed by ESET researchers during LockBit and Dire Wolf intrusions. Its developer was inspired by kill-floor, an EDR killer PoC that abuses Avast’s aswArPot.sys. Besides modifying debug messages and adding control-flow flattening obfuscation (see Figure 4), the author also switched the abused driver to K7RKScan.sys, the same driver abused by K7Terminator, another of BlackSnufkin’s PoCs.

EDR killer as a service

Given the strong and growing demand for EDR-disruption tools, it is no surprise that a parallel marketplace for commercial EDR killers has emerged. The range of offerings is wide: some advertisements provide only vague promises with no technical details, while others include extensive feature lists, usage instructions, and even video demonstrations. Below are three notable examples.

One such advertisement, disclosed by Flare in October 2025, originated from a threat actor using the moniker Бафомет. The threat actor advertised an EDR killer that ESET researchers later named DemoKiller. ESET telemetry confirms that DemoKiller has been used by affiliates of the Qilin, Akira, and Gentlemen gangs, and we also observed it deployed once during a RansomHouse intrusion. The advertisement is shown in Figure 5.

Another paid EDR killer revolves around the ABYSSWORKER rootkit, previously discussed in this blogpost. When paired with its HeartCrypt-packed loader component, which ESET researchers named AbyssKiller, this EDR killer has become one of the most commonly observed commercial ones in the wild. ESET researchers have seen AbyssKiller used by affiliates of the Medusa, DragonForce, and the now-disrupted BlackSuit gangs.

The final noteworthy example is an EDR killer that we call CardSpaceKiller. This tool is consistently packed using VX Crypt, a relatively new packer as a service analyzed by Sophos in late 2025. VX Crypt is not unique to this EDR killer; it has also been used to protect other malware families such as BumbleBee. According to Sophos, CardSpaceKiller has appeared in intrusions involving Akira, Medusa, Qilin, and Crytox. ESET telemetry aligns with these findings and additionally shows deployment during MedusaLocker incidents. Analyzing the unpacked payload, it is immediately clear that this EDR killer comes from a commercial offering, where the developer tries to handle edge cases with a warning (see Figure 6).

The nature and price of such commercially advertised tools vary. Some claim to sell source code, others only individual builds. The price is often a matter of individual negotiation; when disclosed publicly, the price has varied from hundreds to thousands of US dollars.

EDR killers and AI

While the set of abused vulnerable drivers remains relatively small, the number of distinct user-mode components that are part of modern EDR killers in the wild is growing rapidly. Given this surge in volume and variety, it is natural in 2026 to ask: is AI contributing to this proliferation?

Determining whether AI directly assisted in producing a specific codebase is often practically impossible. There is no definitive forensic marker that reliably distinguishes AI-generated code from human-written code, especially when attackers post-process or obfuscate it. However, ESET researchers assess that at least some recently observed EDR killers exhibit traits strongly suggestive of AI-assisted generation.

A clear example appears in an EDR killer recently deployed by Warlock. The tool contains a section of code that not only prints a list of Possible fixes, a pattern typical for AI-generated boilerplate, but also, instead of exploiting a specific driver, implements a trial-and-error mechanism that cycles through several unrelated, commonly abused device names until it finds one that works. The corresponding code is shown in Figure 7.

Beyond the drivers

Fully understanding the EDR killer ecosystem requires looking far beyond vulnerable drivers. While driver exploitation remains a dominant pillar of many tools, it is only one part of a much broader landscape. Our research shows that focusing on drivers alone obscures meaningful relationships between tools, affiliates, and activity clusters.

A key observation is the division of labor in RaaS ecosystems. Operators typically supply the encryptor and supporting infrastructure, but EDR killer selection is left to affiliates. This means that the larger the affiliate pool, the more diverse the EDR killer tooling becomes. At the same time, the consistent reuse of specific tools inside particular clusters can help identify new affiliations, strengthen infrastructure linkages, and reveal operator-affiliate relationships that would remain invisible if one looked only at encryptor families.

Driver reuse and switching

Public PoCs have made driver exploitation widely accessible, but this has created a misleading situation: the same vulnerable driver is often reused across unrelated EDR killers, and the same EDR killer can utilize different drivers over time. As a result, driver-based attribution alone is error-prone.

A clear example is the Baidu Antivirus driver BdApiUtil.sys, which appears in multiple independent projects, including:

• dead-av,
• BdApiUtil-Killer,
• DLKiller,
• HexKiller, one of Warlock’s EDR killers, and
• SevexKiller, a recent EDR killer detected during Akira deployments.

The same pattern appears with the TfSysMon.sys driver (ThreatFire System Monitor). It is abused by TfSysMon-Killer, Susanoo, and EDRKillShifter – three codebases with distinct implementations and development histories.

Driver switching is equally common. CardSpaceKiller, for example, initially relied on HwRwDrv.sys, but later variants migrated to ThrottleStop.sys with minimal changes to the remaining logic. The driver is interchangeable; the exploitation layer remains largely the same.

This illustrates the broader point: drivers are a commodity resource, and their presence alone provides little insight into threat actor sophistication or relationships.

Detection evasion

Attackers aren’t putting much effort into making their encryptors undetected. Rather, all the sophisticated defense-evasion techniques have shifted to the user-mode components of EDR killers. This trend is most visible in commercial EDR killers, which often incorporate mature anti-analysis and anti-detection capabilities. Notable recurring techniques include:

• Driver decoupling. The killer and the driver are often delivered separately. Affiliates manually install the driver first, verifying that it loads successfully before executing the actual EDR-killing component.
• Use of commercial packers. Packers such as VX Crypt (as used with CardSpaceKiller) and HeartCrypt (as used with AbyssKiller) provide structure-level obfuscation, anti‑VM behavior, and continuous repacking to evade static signatures. Popular code virtualization protectors like VMProtect and Themida are also favored.
• Encrypted embedded drivers. When a driver is bundled with an EDR killer, it is frequently stored in encrypted form.
• External encrypted payloads. Some EDR killers store encrypted shellcode or auxiliary components in separate files. This approach effectively hides crucial parts of the killer from being easily accessible to defenders.
• Code obfuscation. Common techniques include control-flow flattening (SmilingKiller), call-by-hash resolution (CardSpaceKiller), and string obfuscation
• Password protection. EDRKillShifter is a perfect example of using this technique. Protecting a crucial part of the EDR killer with a password creates detection challenges, but also provides research opportunities.

Defending against ransomware and EDR killers

Defending against ransomware requires a fundamentally different mindset than defending against automated threats. Phishing emails, commodity malware, and exploit chains stop once detected and neutralized by security solutions; ransomware intrusions do not. They are interactive, human-driven operations, and intruders continually adapt to detections, tool failures, and environmental obstacles. As a result, even when individual steps are detected, they only have defensive value if defenders – whether an internal SOC team, an MSSP, or an MDR provider – respond correctly, immediately, and with sufficient decisiveness.

Most EDR killers rely on legitimate but vulnerable drivers, which is why defenders often instinctively focus on driver blocking. Blocking the driver from loading is a crucial step and does indeed neutralize the EDR killer, but only at the very last possible moment. By the time an affiliate attempts to install the driver, they typically already have high privileges and are seconds away from launching the encryptor. If the EDR killer fails, they will simply try another tool.

Because these drivers are legitimate, overly aggressive blocking risks disrupting business-critical software, complicating incident handling. Targeted blocking also faces challenges. In February 2025, Check Point showed that threat actors were able to create over 2,500 samples of Truesight.sys, all of them remaining validly signed due to a weakness in the signature validity checking process. Truesight.sys is also one of many examples of a weakness in Microsoft’s driver signing policy. A year later, in February 2026, Huntress analyzed an intrusion where EnPortv.sys was abused despite its certificate being expired and explicitly revoked.

This is why a prevention-first strategy is essential. Blocking commonly misused drivers from loading is an effective and necessary defense mechanism, but it shouldn’t be the only one. Studying EDR killers allows defenders to come up with a multilayered strategy that expands the horizons; the goal is to stop the EDR killer before execution. After all, when it comes to ransomware, the most effective defense strategy is to have methods in place to detect, contain, and remediate the threat at every possible step.

Conclusion

EDR killers endure because they’re cheap, consistent, and decoupled from the encryptor – a perfect fit for both encryptor developers, who don’t need to focus on making their encryptors undetectable, and affiliates, who possess an easy-to-use, powerful utility to disrupt defenses prior to encryption.

Our research presents telemetry-backed insights into the EDR killer ecosystem that move past the commonly seen driver-centric approach. We document how affiliates, not operators, shape tooling diversity, and how codebases routinely reuse and swap drivers. We outline how the past year saw increasingly commercialized offerings for EDR killers, and showcase how commercial EDR killers especially can supply the defense evasion techniques commonly missing in encryptors.

We emphasize that while preventing vulnerable drivers from loading is a crucial step in the line of defense, it may also lead to potential business disruptions, which is why one should not rely only on that and aim to disrupt EDR killers before they even get a chance to load the driver. Furthermore, we demonstrated that driverless approaches, whether script- or vulnerability-based, are a favored addition to any ransomware threat actor’s arsenal.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

A comprehensive list of indicators of compromise (IoCs) and samples can be found in our GitHub repository.

Files

MITRE ATT&CK techniques

This table was built using version 18 of the MITRE ATT&CK framework.