GodDamn Ransomware Uses Signed PoisonX Driver to Blind Endpoint Defenses

A ransomware family tied to the Hyadina group (rebranded from Beast) uses a Microsoft-signed malicious kernel driver, AnyDesk, and PsExec to disable security tooling before encrypting data.

Incident Response Vulnerability Threat Intelligence

A ransomware family called GodDamn, tracked as a rebrand of the Beast lineage tied to the Hyadina group, has been observed using a Microsoft-signed malicious kernel driver called PoisonX (deployed on disk as “g11.sys”) to disable endpoint security software before encrypting victim data. The technique is a classic bring-your-own-vulnerable-driver (BYOVD) attack, but the notable escalation is that the driver’s authors got it signed by Microsoft, letting it load without triggering the usual unsigned-driver warnings.

In observed intrusions, attackers paired the PoisonX driver with a user-mode defense evasion tool disguised as a legitimate Symantec binary (“symantec.exe”), then used AnyDesk for remote access and PsExec for lateral movement, alongside a NirSoft-based toolkit for harvesting credentials from memory and browser stores. GodDamn was first spotted in the wild on May 21, 2026, and the attack chain described here was observed in a confirmed intrusion in early June.

The use of a signed driver to blind security tooling is a meaningful step up in defense evasion — it sidesteps driver signature enforcement entirely, which is one of the more reliable barriers against kernel-level tampering. It also signals that Hyadina is actively investing in developing GodDamn’s capabilities rather than running it as a one-off rebrand.

Security teams should treat unexpected kernel driver installations as a high-priority signal regardless of whether the binary is signed — a valid signature only proves provenance, not intent. Equally important: AnyDesk, PsExec, and similar legitimate remote-access and admin tools are frequently abused in exactly this way, so alert on their use outside of known, change-managed maintenance activity, and review whether your endpoint telemetry captures driver load events at all.

Why it matters: A signed kernel driver bypassing your EDR is a detection-layer problem, not a patching problem. Make sure your monitoring flags unexpected kernel driver loads and known dual-use remote access tools like AnyDesk and PsExec running outside of change-managed maintenance windows.

Read source →