How the GodDamn Ransomware Driver Bypasses Your EDR

Most EDR bypass driver incidents rely on a driver the attacker never had to hide, because it already has a real, valid signature. That is exactly what happened with GodDamn, a ransomware family that Broadcom’s Symantec Threat Hunter Team linked to a kernel driver called PoisonX in early July 2026. If you run Windows endpoints, the technique behind it is worth understanding properly, because the fix is a setting most teams have not turned on.

What actually happened

Symantec traced GodDamn back through two earlier names. Beast appeared in June 2024, and before that came Monster, a Delphi-based ransomware first seen in March 2022. The developer, tracked as Hyadina, has kept rebuilding the same core operation for four years. In the case Symantec documented, the group used AnyDesk for remote access and PsExec to move laterally. They stole passwords with a NirSoft-based credential toolkit alongside Mimikatz, then finally dropped ransomware onto at least ten hosts.

The new piece is PoisonX, a driver file named g11.sys that carries a genuine Microsoft Windows Hardware Compatibility Publisher signature. Once it loads, it can kill security-product processes and remove the API hooks that antivirus and EDR agents use to monitor a system. The software keeps running. It just stops seeing anything.

Why an EDR bypass driver gets past your defences

Windows only loads kernel drivers that carry a valid digital signature, a control called driver signature enforcement. The rule exists to stop attackers writing custom kernel-mode malware. Unsigned code simply will not load on a 64-bit system. The workaround, known as bring-your-own-vulnerable-driver or BYOVD, does not try to beat that check. It sources a driver that already passed it.

Once a BYOVD-style driver is on disk and loaded, it runs with kernel privileges, the highest level of trust on the machine. From there it can terminate processes, tamper with security callbacks, or strip protections that would normally block user-mode code from touching a protected process. An EDR bypass driver won’t always show up on a blocklist the day it’s used, so treat behaviour as the fallback, not an afterthought. PoisonX doesn’t need to exploit anything after it loads. It just switches the lights off.

What to actually do about it

Three controls address this directly, and none of them require exotic tooling.

  • Turn on the vulnerable driver blocklist. Microsoft has shipped this by default since the Windows 11 2022 update. It also activates automatically whenever memory integrity, also called hypervisor-protected code integrity or HVCI, is switched on. Check that HVCI is actually enabled rather than assuming it is. Many fleets built from older images still have it off.
  • Enable the attack-surface-reduction rule for exploited signed drivers. This Microsoft Defender rule blocks an application from writing a vulnerable signed driver to disk in the first place, which stops the problem before a reboot could load it.
  • Apply the latest blocklist directly. The built-in blocklist updates quarterly and through monthly Windows updates. Microsoft also publishes the current version for App Control for Business, so teams that cannot wait for the next update cycle can pull it in sooner.

Watch for the behaviour, not just the driver

None of this catches every future EDR bypass driver on day one; a brand-new signed malicious driver will not be on the blocklist until someone reports it. That is why the other half of the defence is behavioural. Watch for AnyDesk or similar remote-access tools appearing in unusual folders. Watch for PsExec spawning across many hosts in a short window, and for any process that looks like it is impersonating a security product, as GodDamn’s operators did with a file called “symantec.exe”.

It also helps to log driver load events directly rather than relying only on the EDR agent to report them, since that agent is the thing PoisonX is designed to blind. Windows writes driver-load activity to the CodeIntegrity operational log. A spike in unfamiliar or newly-signed drivers loading across several hosts in the same window is worth investigating on its own, regardless of what your endpoint tool is reporting at the time.

Credential hygiene matters here too. GodDamn’s operators harvested passwords with fourteen separate NirSoft tools plus Mimikatz once they were inside, pulling stored logins out of browsers, mail clients and even network traffic capture. Restrict local admin rights and rotate credentials that touch multiple hosts. Disable saved-password features in browsers on shared or server-class machines. Together these cut how much a single foothold is worth to an attacker who has already gotten past the EDR layer.

The takeaway for IT teams

A digital signature tells you a driver passed Microsoft’s checks. It does not tell you the driver is harmless, and GodDamn is proof that criminal groups will build an EDR bypass driver from scratch if it buys them a way past your defences. Treat kernel-level protections as a baseline requirement, not an optional extra. Confirm HVCI and the driver blocklist are switched on across your estate rather than assuming a default install has already handled it.

Related posts

Adobe ColdFusion Vulnerabilities Are a Design Failure, Not Bad Luck

Gitea Docker Vulnerability Now Under Active Probing, CVE-2026-20896

Inside Android’s New Lockscreen Rate-Limiting Rules