Your organisation’s endpoint detection and response platform just became a liability. Researchers at Symantec’s Threat Hunter Team disclosed on 9 July 2026 that the Hyadina ransomware-as-a-service (RaaS) group has debuted a new locker called GodDamn — and its defining weapon is a Microsoft-signed kernel driver named PoisonX (g11.sys) that silently terminates antivirus and EDR processes before a single file is encrypted. In at least one documented campaign spanning 10-plus hosts, Hyadina’s affiliate dwell time, credential harvesting, and lateral movement completed entirely under the radar of conventional endpoint defences. By the time the “.God8Damn” extension appeared on files, the security stack was already dead.

This is not a theoretical edge case. GodDamn is the latest evolution of the long-running Beast ransomware family, which itself descended from Monster. Hyadina has operated this RaaS for roughly four years, and the introduction of a deliberately crafted, signed malicious kernel driver signals a dangerous maturation of their toolset. For CIOs, CISOs, and IT security leaders — particularly those managing manufacturing, healthcare, and education environments — the GodDamn campaign demands an immediate response.

🔑 Key Takeaways

  • New ransomware family: GodDamn is a rebrand of Beast (Monster lineage), operated by the Hyadina RaaS group active since ~2022.
  • BYOVD with a twist: PoisonX (g11.sys) is a deliberately malicious driver — not a flawed legitimate one — that passed Microsoft’s signing review.
  • EDR neutralised first: PoisonX runs at Ring 0 (kernel level), terminating AV/EDR processes and stripping security agents of their functional rights.
  • Full-featured attack chain: NirSoft credential harvesting → PsExec lateral movement → AnyDesk persistence → PowerShell pre-staging → .God8Damn encryption.
  • Masquerades as Symantec: A user-mode tool disguises itself as symantec.exe to evade process-level inspection.
  • 10+ hosts compromised in the single documented campaign before encryption was triggered.
  • Immediate defence: Enable Microsoft’s Vulnerable Driver Blocklist, deploy WDAC policies, and hunt for g11.sys and unauthorised AnyDesk instances now.

What Is GodDamn Ransomware? The Hyadina Family Tree

The Hyadina group is a roughly four-year-old ransomware-as-a-service operation that has quietly evolved its toolset through successive generations. Their first major locker, Monster, gave way to Beast — an enhanced rebranding that sharpened the encryption engine and evasion techniques. GodDamn is the latest iteration, first spotted on 21 May 2026, and it introduces a capability that sets it apart from most commodity ransomware: a kernel-resident driver purpose-built to destroy security tooling before encryption begins.

Hyadina’s target profile is instructive. The group primarily attacks US-based organisations across healthcare, manufacturing, and education, while deliberately avoiding former Soviet bloc countries — a geographic carve-out common among Russian-speaking RaaS affiliates. The RaaS model, however, means that affiliates can license GodDamn and deploy it anywhere they find opportunity. For Indian enterprises that share technology supply chains, manufacturing partnerships, or cloud infrastructure with US counterparts, the risk is not hypothetical.

Symantec’s Threat Hunter Team and CYFIRMA intelligence both attribute this campaign to Hyadina. The group contacts victims via email and the qTox encrypted messaging application — a communications pattern consistent with professional RaaS operations seeking to negotiate ransom terms privately.

PoisonX: How Attackers Got a Malicious Driver Past Microsoft’s Signing Gate

Bring Your Own Vulnerable Driver (BYOVD) attacks are not new. The classic technique involves finding a legitimate but flawed signed driver — a hardware monitoring utility, a game’s anti-cheat module — and exploiting its vulnerabilities to escalate from user mode to Ring 0 kernel access. What makes PoisonX different, and significantly more alarming, is that it is a deliberately malicious driver that its developers succeeded in getting signed by Microsoft.

This distinction matters enormously. Microsoft’s Driver Signing Enforcement is supposed to be the last line of defence against kernel-mode malware. A malicious driver that carries a legitimate Microsoft signature can bypass that control entirely — it looks, to the operating system and many security tools, identical to a trusted system component.

Once g11.sys loads at kernel level, PoisonX can:

  • Terminate antivirus and EDR processes before they can alert or log the intrusion.
  • Strip security agents of functional rights — revoking permissions so they cannot restart or communicate with their management console.
  • Tamper with kernel records to blind security products to ongoing activity.

PoisonX is not a bespoke Hyadina creation. It was previously adopted by The Gentlemen RaaS and integrated into their GentleKiller tool, suggesting an emerging market for shared malicious kernel components — a supply chain problem inside the ransomware ecosystem itself.

Characteristic Classic BYOVD PoisonX (GodDamn)
Driver origin Legitimate, flawed vendor driver Deliberately malicious, yet signed
Microsoft signing Legitimate (vendor signed) Obtained via Microsoft’s review process
Vulnerability exploited Known CVE in driver code No CVE — driver IS the weapon
Blocklist mitigation Microsoft VDB hash blocks exploited driver Requires revocation + hash block update
Reuse across groups Rare — each group finds their own Shared: Gentlemen RaaS, Hyadina

Inside the Attack Chain: From Initial Foothold to .God8Damn

The Symantec-documented campaign ran from 29 May to 3 June 2026, though it was only publicly disclosed on 9 July. The intrusion was methodical and staged — a deliberate, multi-phase operation rather than a smash-and-grab. Here is how Hyadina’s affiliate moved through the network:

1. Initial Access. The initial vector for this specific campaign has not been publicly confirmed. Given Hyadina’s history, exploitation of internet-facing services or phishing is the most likely entry point.

2. Credential Harvesting. Attackers deployed a NirSoft-based toolkit to extract credentials from browsers, the Windows Credential Manager, cached domain credentials, VNC sessions, email clients, Wi-Fi profiles, and network traffic captures. This broad sweep ensures that lateral movement options remain wide open regardless of which applications hold the most sensitive passwords.

3. Defence Evasion. A user-mode component masquerading as symantec.exe was deployed to blend into process lists on hosts that run Symantec endpoint products — a highly targeted deception. Simultaneously, PoisonX (g11.sys) was loaded at kernel level to terminate security software.

4. Lateral Movement. The group used PsExec — Microsoft’s own legitimate remote execution tool — to move host-to-host across the network. Because PsExec is a trusted administrative utility, many environments either whitelist it or generate low-fidelity alerts on its use.

5. Persistence. AnyDesk, a popular remote desktop application, was installed and registered as an auto-starting Windows service, giving attackers a persistent, encrypted tunnel back to the victim environment. PowerShell scripts were pre-staged for reusable installation of additional components.

6. Encryption. Across 10 or more hosts in a single documented campaign, GodDamn encrypted files appending the .God8Damn extension. In some observed variants, the extension incorporated the victim organisation’s name instead of the generic marker — a psychological tactic that personalises the extortion message.

The India Angle: Why South Asian Enterprises Are Not Safe Bystanders

Hyadina’s stated targeting of US organisations in healthcare, manufacturing, and education maps almost exactly onto the sectors where Indian IT infrastructure intersects most deeply with Western networks. Indian pharmaceutical companies with US FDA-regulated operations, auto-component manufacturers supplying US OEMs, and IT service providers managing US healthcare systems all fall within the blast radius of a GodDamn affiliate campaign — even if the primary target is American.

Moreover, RaaS economics mean that any affiliate can choose to expand Hyadina’s geographic scope. An affiliate operating from outside the US faces no structural constraint against targeting Indian organisations directly. The same PoisonX driver, the same credential-harvesting playbook, the same AnyDesk persistence mechanism works just as effectively in Mumbai as in Minneapolis.

India’s rapid EDR adoption — accelerating since CERT-In’s 2022 incident-reporting mandate and subsequent guidance — means that many organisations have deployed exactly the class of tooling that PoisonX is designed to neutralise. Deploying an EDR is no longer sufficient protection; the integrity of the EDR itself must be defended.

What You Should Do Right Now — A Zero-Trust Defence Checklist

As a cybersecurity consultant specialising in zero-trust architecture and network security, I recommend the following immediate and medium-term actions for any organisation that relies on endpoint security tooling:

Immediate (this week):

  • Block g11.sys by hash. Add the PoisonX driver to your EDR’s block list and to Windows Defender Application Control (WDAC) policies immediately. Hunt for its presence in your environment.
  • Hunt for masquerade processes. Search your SIEM and EDR telemetry for symantec.exe running on hosts that do NOT have Symantec/Broadcom endpoint software installed — this is a high-fidelity IOC for this campaign.
  • Audit AnyDesk deployments. Block or alert on AnyDesk (and other unapproved RMM tools) installed as a Windows service, especially auto-start services registered after your standard deployment windows.
  • Alert on PsExec usage. Create SIEM rules or EDR detections for PsExec invocations — especially chains where PsExec executes on more than three hosts within a short time window.

Medium-term (next 30 days):

  • Enable and update Microsoft’s Vulnerable Driver Blocklist (VDB). Ensure your Windows endpoints receive the latest blocklist updates via Windows Update or deploy them via Group Policy. Verify that Driver Signature Enforcement is active and not bypassed by test-signing modes.
  • Deploy Windows Defender Application Control (WDAC) in enforcement mode. WDAC kernel-mode policies can restrict which signed drivers are permitted to load — even a Microsoft-signed driver can be blocked by hash or publisher policy. This is the single most effective control against PoisonX-class attacks.
  • Harden EDR with tamper protection. Verify that tamper protection is enabled in your EDR platform so that kernel-level manipulation attempts are logged and alerted even if not fully blocked.
  • Segment networks to limit PsExec blast radius. Zero-trust micro-segmentation ensures that even if an attacker gains credentials and uses PsExec, they cannot traverse freely to high-value servers and backup systems.
  • Block NirSoft utilities at the perimeter and endpoint. Add NirSoft executables (WebBrowserPassView, NetworkPasswordRecovery, etc.) to your deny list unless there is a documented operational need.
  • Review privileged credential storage. GodDamn’s NirSoft sweep targets Windows Credential Manager, browser stores, and cached credentials. Enforce a privileged access workstation (PAW) model and minimise credentials cached on domain workstations.

These controls align directly with the NIST Zero Trust Architecture (SP 800-207) pillar of device health validation. If you cannot attest that your kernel is uncompromised, you cannot trust your endpoint’s security posture — and downstream access decisions based on that posture become meaningless. We have covered similar supply-chain-scale ransomware campaigns and the evolution of ransomware automation in previous briefings — the pattern is consistent: attackers are investing in disabling defenders before detonating their payload. If you are running a flat network where an EDR outage on one host opens the entire estate to lateral movement, this is not the first time we have seen that assumption weaponised.

Frequently Asked Questions

What is a BYOVD ransomware attack?

Bring Your Own Vulnerable Driver (BYOVD) is a technique where attackers drop a kernel-mode driver onto a victim system to gain Ring 0 (kernel-level) access. Because Windows requires drivers to be signed, attackers traditionally exploit legitimate drivers that contain vulnerabilities. GodDamn’s PoisonX variant goes further — it is a deliberately malicious driver that somehow obtained Microsoft’s signature, removing the dependency on a exploitable flaw in a third-party driver.

How is PoisonX different from other BYOVD drivers?

Most BYOVD attacks repurpose legitimate signed drivers (graphics utilities, game anti-cheat software) by exploiting their known vulnerabilities. PoisonX (g11.sys) is not a repurposed legitimate driver — it was built as a weapon and its developers succeeded in getting it through Microsoft’s signing review process. It has also already been shared across at least two ransomware groups (The Gentlemen RaaS and Hyadina), suggesting an emerging market for malicious signed kernel components.

Is Microsoft doing anything about signed malicious drivers?

Microsoft maintains a Vulnerable Driver Blocklist (VDB) that can revoke trust in known malicious or vulnerable drivers. Once PoisonX is added to this blocklist — and its certificate revoked — the driver will be blocked on systems with up-to-date VDB policies. However, the window between disclosure and blocklist update is a period of elevated risk. Organisations should supplement the VDB with WDAC policies that allow only explicitly approved drivers to load at kernel level, regardless of signing status.

What does the .God8Damn extension tell incident responders?

The .God8Damn extension is Hyadina’s GodDamn ransomware variant’s primary marker. In some observed cases, the group substitutes the victim organisation’s name in the extension. If you discover this extension in your environment, treat it as a confirmed GodDamn/Hyadina incident. Preserve memory dumps and kernel artefacts before rebooting — the PoisonX driver (g11.sys) may still be resident and can provide forensic evidence of exactly which security processes were terminated and in what order.


Is Your EDR Protected Against Kernel-Level Attacks?

GodDamn and PoisonX demonstrate that a deployed EDR is not the same as a protected EDR. If your organisation has not validated kernel-integrity controls, WDAC policies, and network segmentation against BYOVD-class threats, now is the time to close those gaps — before an affiliate drops g11.sys on your servers.

🔒 Schedule a Zero-Trust Security Assessment with Sanjay Seth →