GodDamn Ransomware PoisonX Driver Kills EDR
The GodDamn ransomware PoisonX driver is a Microsoft-signed kernel tool that ransomware operators use to silently kill EDR and antivirus processes before deploying encryption — and because the driver carries a legitimate Microsoft signature, standard driver-trust checks wave it straight through.
What Happened
Symantec disclosed on July 9, 2026 that a ransomware family called GodDamn — a rebrand in the same lineage as the earlier Beast and Monster strains, tracked to a developer identified as “Hyadina” who has rebuilt the same core operation for roughly four years — is using a malicious kernel driver called PoisonX as its primary defense-evasion tool. The GodDamn ransomware PoisonX driver carries a valid Microsoft code-signing certificate and exposes an undocumented IOCTL interface (observed at path 0x22E010) that accepts a target process ID and calls ZwOpenProcess and ZwTerminateProcess directly from kernel mode. That lets an attacker kill protected security processes — including, in an earlier documented case, the CrowdStrike Falcon service — without generating the alerts a user-mode kill attempt would trigger. In the intrusion Symantec investigated, operators used AnyDesk for remote access, PsExec for lateral movement, and a credential-theft toolkit built around Mimikatz and multiple NirSoft utilities, installing the driver itself via a tool disguised with a fake Symantec brand. Researchers have identified more than 15 signed variants of the driver.
Why It Matters
There is no CVE here and no patch to apply — the driver is not exploiting a software flaw, it is abusing the trust that a valid Microsoft signature is supposed to confer. That makes it a governance problem as much as a technical one: any organization whose compensating control for “unknown kernel drivers” is “check if it’s signed” has already lost. GodDamn’s initial infections concentrate on small and medium-sized Windows environments, which maps directly onto the DACH Mittelstand profile — organizations that typically run a single EDR/AV product as their primary control and have limited driver-level monitoring in place. This is the second distinct EDR-killing technique DIESEC has tracked in 2026, after the April 7 report on Qilin ransomware’s DLL side-loading approach — different actor, different mechanism, same underlying goal of blinding defenders before the encryption phase begins.
What You Should Do Now
- Enable and keep current Microsoft’s vulnerable/malicious driver blocklist (delivered via Windows Defender Application Control / HVCI-enforced blocklist updates) rather than assuming code-signing alone is a sufficient control.
- Alert on any new or rarely-seen kernel driver load event, especially drivers that were not part of a standard software deployment — this is a higher-signal detection point than trying to catch the ransomware payload itself.
- Treat unexpected termination or health-status changes in your EDR/AV service as a containment trigger, not a logging footnote — silent process termination is the entire point of this technique.
- Restrict and monitor AnyDesk and PsExec usage on servers and workstations that don’t have a documented business need for remote-access or admin-execution tooling; both were the delivery mechanism in the observed intrusion, not the driver itself.
DIESEC Perspective: We keep seeing the same governance gap across 2026’s EDR-killer cases — organizations verify that security tooling is installed, but few verify that it’s still functioning at the moment an incident starts. A signed driver silently killing your EDR process is invisible to a dashboard that only checks “is the agent deployed,” not “is the agent currently reporting.”
Not sure whether your driver-signing policy and kernel-level monitoring would catch something like this? Contact DIESEC for a rapid endpoint security control verification.
Sources: The Hacker News | Symantec
Published: 2026-07-16 | Category: Ransomware & Extortion | ~4 min read
