Researchers are tracking a ransomware family calling itself GodDamn, and while the name is new, almost nothing else about it is. GodDamn is the latest rebrand of a long-running lineage: it shares strong code overlap with Beast — itself the 2024 rebrand of the Monster ransomware — and its operational playbook mirrors earlier Hyadina campaigns. First spotted in the wild on May 21, 2026 and detailed by Symantec’s threat researchers and reported by The Hacker News on July 9, GodDamn is currently focused on U.S. companies.

The rebrand cycle is background noise in ransomware; groups shed names the way they shed infrastructure. What makes GodDamn worth writing about is its defense-evasion component: a signed kernel driver named PoisonX that represents a genuinely dangerous evolution of a technique the industry thought it understood.

BYOVD, But Worse

For several years the dominant kernel-level evasion technique has been BYOVD — bring your own vulnerable driver. The idea is straightforward: attackers ship a legitimate driver that happens to contain an exploitable flaw, load it (Windows trusts it because it’s properly signed), then exploit the flaw to gain kernel-level code execution and tear down security software from below. The signed component is real and benign; the abuse is in exploiting its bug.

PoisonX inverts that model. According to the analysis, PoisonX is not a legitimate driver being abused — it appears to be a malicious driver that nonetheless obtained a valid signature. It carries a legitimate-looking signature attributed to the “Microsoft Windows Hardware Compatibility Publisher” — the exact trust anchor Windows uses to decide a kernel driver is safe to load.

This is a categorical step up. With classic BYOVD, defenders can build detections around a known-bad list of vulnerable-but-legitimate drivers and block them by hash. With a purpose-built malicious driver that is itself validly signed, there is no legitimate version to distinguish it from. The malware doesn’t borrow trust from someone else’s buggy code — it carries its own.

What PoisonX Does From the Kernel

Once loaded, PoisonX operates as a neutralization layer sitting beneath the operating system’s own defenses. Per the research, it can:

  • Terminate security processes outright
  • Remove user-mode hooks that EDR products rely on to observe process behavior
  • Intercept system calls to filter what the OS reports upward
  • Mask process activity so malicious operations never surface to monitoring tools

The net effect is that endpoint detection and response tooling is blinded before the ransomware payload ever reaches the file system. By the time anything writes encrypted files to disk, the sensors that would have screamed have already been silenced from a layer they cannot see into.

PoisonX is not brand new to 2026. It was first documented earlier this year when an attacker used it to kill the CrowdStrike Falcon service by sending a crafted IOCTL to the driver’s undocumented interface. GodDamn adopting it as a standard component signals that the driver has graduated from a bespoke tool to shared tradecraft — the same commoditization pattern that turned Cobalt Strike and Mimikatz into ransomware staples.

The Full Attack Chain

PoisonX is the standout, but it’s one stage in a conventional-looking human-operated ransomware intrusion. The GodDamn attack chain runs roughly:

  1. Stealthy foothold — initial access established quietly, consistent with the Beast/Monster lineage’s tradecraft.
  2. Credential harvesting — operators deploy NirSoft utilities, a suite of legitimate password-recovery tools frequently repurposed to dump stored credentials from browsers, mail clients, and the OS.
  3. Kernel-level defense subversion — the operators drop a file impersonating a Symantec binary, which installs the signed PoisonX driver into the system driver store and blinds endpoint security.
  4. Remote access tooling — legitimate remote-management software is installed for persistence and hands-on control.
  5. Lateral movement via PsExec — the Sysinternals tool is used to spread across the network to additional hosts.
  6. Encryption — with defenses neutralized and reach established, the ransomware payload executes.

Every stage after the driver is standard-issue human-operated ransomware. The driver is what makes the rest of it invisible while it happens.

The Signing-Abuse Problem

The uncomfortable core of this story is the signature. Windows’ kernel-mode code signing requirements exist precisely to stop unsigned malicious drivers from loading. A malicious driver carrying a valid Microsoft-attributed signature means one of a few things happened: a signing certificate was stolen or fraudulently obtained, an attestation-signing or WHQL process was gamed, or a legitimate signing pipeline was abused to bless attacker code.

None of those are new individually. Stolen driver-signing certificates have fueled kernel malware for years, and abuse of Microsoft’s attestation and Windows Hardware Compatibility Program signing has been documented repeatedly since 2022, when researchers showed malicious drivers slipping through the attestation process. But the industry’s defensive posture still leans heavily on the assumption that a valid signature from a Microsoft-attributed publisher means a driver is trustworthy. PoisonX is a working demonstration that the assumption is broken.

Microsoft maintains a vulnerable driver blocklist that ships with Windows and is meant to catch known-bad drivers, but blocklists are reactive by definition — they catch what’s already been named. A freshly signed malicious driver isn’t on any list until someone finds it, analyzes it, and revokes or blocks it. GodDamn’s operators are exploiting exactly that window.

Defending Against Kernel-Level Blinding

If your defensive model assumes your EDR will always be watching, GodDamn is the counterexample. Practical mitigations:

  • Enable Microsoft’s vulnerable/malicious driver blocklist and keep it current — it won’t catch novel drivers, but it removes the easy targets.
  • Turn on hypervisor-protected code integrity (HVCI) and Windows’ Vulnerable Driver Blocklist where hardware allows; these raise the bar for loading unsigned or blocklisted kernel code.
  • Monitor for the precursors, not just the driver. NirSoft tools, PsExec across hosts, binaries masquerading as Symantec files, and new drivers appearing in the driver store are all detectable events that precede encryption.
  • Watch for your own EDR going quiet. A sensor that stops reporting is not “no news” — it may be the loudest signal you’ll get. Alert on agent silence and tamper events.
  • Segment and restrict lateral movement. PsExec-driven spread depends on flat networks and reused local admin credentials; kill both.

GodDamn itself will be renamed again within a year — that’s the business model. PoisonX, and the signed-malicious-driver technique it represents, is the part that outlives the brand. The takeaway isn’t a new name to add to a blocklist. It’s that “the driver is signed” has stopped being an answer to “is it safe.”

Sources