SURIQ
A code signature tells you who wrote something. It has never told you whether that thing is safe to run. GodDamn, a ransomware family that Symantec's Threat Hunter Team flagged this week, is the latest reminder of the gap between those two ideas. It ships with a kernel driver named PoisonX (g11.sys) that, according to the reporting, carries a valid Microsoft signature. Windows loads it without complaint. Once it is resident in the kernel, it goes to work switching off the security software that was supposed to catch the ransomware.
We wrote in June that the endpoint detection and response (EDR) killer had become a shipped product, packaged and sold with ransomware kits. That was a user-mode tool. PoisonX is the same idea moved one privilege tier up, into the kernel, behind a signature the operating system trusts. The arms race did not change direction. It climbed the stack.
What GodDamn actually does
The mechanics are ordinary until the driver loads. Symantec, as reported by The Hacker News and Dark Reading, assesses GodDamn as a rebrand of the Beast ransomware, which itself grew out of the Delphi-based Monster family from early 2022. The developer group is tracked as Hyadina. The ransomware was first seen publicly on May 21, 2026, with a campaign following in early June.
The intrusion chain reads like most hands-on-keyboard ransomware. Operators use AnyDesk for remote access, a NirSoft-based toolkit to harvest credentials, and PsExec to move laterally. One user-mode component masquerades as symantec.exe to blend in. None of that is novel, and none of it is the point.
The point is PoisonX. Because the driver is signed, Windows accepts it into the kernel. From there it does what kernel-mode EDR killers do: it terminates the processes belonging to antivirus and EDR products, and it tampers with the kernel's internal notification records so the security product stops receiving the events it relies on. Your agent does not crash with an error. It simply goes silent, still installed, still reporting healthy, no longer seeing anything.
A signature is an identity claim, not a safety claim
This is the part worth sitting with. Code signing was built to answer one question: did this come from who it says it came from. It was never designed to answer the question defenders actually care about, which is whether the code is hostile. Those two questions only line up as long as an attacker cannot get hostile code signed. That assumption has been eroding for years. Malicious drivers pushed through Microsoft's own driver-signing programs have surfaced repeatedly since 2022, and PoisonX is the same category of problem: not a legitimate driver with a bug in it, but a driver built to do harm that nonetheless holds a signature the platform honors.
That distinction matters for how you defend against it, because the two flavors of driver abuse fail differently.
| Approach | Bring your own vulnerable driver | Signed malicious driver (PoisonX) |
|---|---|---|
| What is signed | A legitimate third-party driver with an exploitable flaw | A driver purpose-built to kill security tools |
| How the kill happens | Attacker exploits the flaw to reach the kernel | The driver already runs in the kernel by design |
| Does a blocklist catch it | Yes, once the vulnerable driver is known and listed | Only after Microsoft revokes it and the block propagates |
| Reliable detection signal | The driver load plus a known-bad hash | The driver load plus the EDR going quiet |
The vulnerable-driver route leaves a hash you can blocklist. The signed-malicious route does not give you that, at least not until the signature is revoked and the revocation reaches your fleet. In the window before that happens, and it is often a long window, the driver looks clean to every signature check you own.
Enforce the blocklist you assume is already on
Microsoft maintains a Vulnerable Driver Blocklist that stops known-bad drivers from loading. It is the right control, and most people assume it is running. On a lot of Windows Server builds it is not enforced unless memory integrity, also called hypervisor-protected code integrity (HVCI), is turned on, and HVCI is off by default in many environments. Check the actual enforcement state on your servers rather than assuming the default protects you, and turn it on where your hardware supports it.
Understand the limit, though. A blocklist is reactive by construction. It catches the driver you already know is bad. A freshly signed driver like PoisonX is not on the list on day one, so blocklist enforcement raises the floor without closing the door. That is exactly why the detection has to move off the file and onto the behavior.
Watch the load, then watch the silence
There are two moments to catch a kernel EDR killer, and you want both.
The first is the driver load itself. A new kernel-mode service or driver appearing on a server that has not changed in months is an event, not noise. We made this same point about a backdoor that moved into the Windows kernel: the detection window opens at load and closes fast. Alert on new driver and kernel-service creation, correlate it against your change records, and treat an unexplained one on a production server as an incident until proven otherwise. This is the earlier of the two signals and the one that buys you time.
The second is the silence. When PoisonX unhooks the kernel callbacks, your EDR stops sending telemetry while still appearing online. A gap in the event stream from a host that is clearly still running is itself the alarm. Build the detection that fires when an agent goes quiet, not just the one that fires when it reports something bad. An endpoint that suddenly has nothing to say is the loudest thing in your threat hunt that night.
Both of these are behavioral, host-centric signals that no signature check will ever produce, which is the whole argument for pairing endpoint prevention with monitored detection. Managed detection and response earns its keep on the second event: an analyst watching for the agent that went dark, the alert mapped to the technique rather than the file. Suriq's endpoint and cross-layer detection and its monitored response are built on that assumption, that prevention will occasionally be blinded and something still has to be watching the gap.
Assume your next EDR killer will be signed too
GodDamn is not a special case. It is where this class of attack has been heading since custom EDR killers started shipping with ransomware kits, and the signed kernel driver is the logical next rung. Plan for it. Enforce driver blocklisting where you can, alert on every new kernel driver load, and build the detection that treats a silent agent as an active incident. The signature on the driver will keep lying to you. The silence after it loads will not.