Hyadina Strikes with GodDamn: Microsoft-Signed Driver Disables…

The Hyadina ransomware-as-a-service group deploys a new locker, GodDamn, using the Microsoft-signed PoisonX kernel driver to neutralize endpoint security before encryption. A Symantec-documented incident reveals a 24-hour operational window from initial compromise to payload deployment: an AnyDesk instance appears on May 29, and PoisonX disables defenses on May 30. The valid Microsoft signature makes this BYOVD vector especially dangerous because it bypasses kernel-mode loading controls, while Microsoft's reactive blocklist leaves attackers weeks of runway.

The Hyadina ransomware-as-a-service group has fielded a new locker, GodDamn, using a Microsoft-signed kernel driver to disarm endpoint security tools before encryption. The Symantec-documented incident shows a 24-hour operational window from initial compromise to payload deployment: an AnyDesk instance appeared on May 29, and the PoisonX driver neutralized defenses on May 30. The valid Microsoft signature on the driver makes the BYOVD — Bring Your Own Vulnerable Driver — vector particularly insidious because it bypasses kernel-mode loading controls, while Microsoft's reactive blocklist leaves attackers weeks of margin.

Key Takeaways

Hyadina, a RaaS operation active for roughly four years, has replaced its previous Beast and Monster lockers with GodDamn and predominantly targets U.S. organizations in healthcare, manufacturing, and education.
The PoisonX driver, published on GitHub on April 7, 2026 by author "oxfemale" as a "research tool," carries a valid Microsoft Hardware Compatibility signature that allows kernel-mode loading and the issuance of IOCTLs to terminate security-related processes.
In a case analyzed by Symantec, the operational chain unfolds over 24 hours: AnyDesk on May 29 as the first signal, PoisonX dropped via a binary masquerading as "symantec.exe" on May 30.
Symantec and Carbon Black implement driver-agnostic behavioral monitoring to detect anomalous IOCTLs targeting security products, countering the structural delay of days or weeks in Microsoft's blocklist.

GodDamn's Operational Path: From AnyDesk to Encryption in 24 Hours

Symantec researchers reconstructed a compromise chain that began on May 29, 2026 with the loading of an AnyDesk instance into an endpoint's Music folder. The following day, on a second computer in the same network, the attacker dropped a binary named symantec.exe. This executable installed PoisonX, a kernel driver that Symantec labels as malware with no legitimate use.

PoisonX operates at the kernel level by sending IOCTLs to terminate security-related processes and remove user-mode API hooks. The result is the neutralization of endpoint security tools before the GodDamn locker proceeds to encryption. Lateral movement occurs via PsExec, a standard Windows remote administration toolkit.

The dossier does not specify the initial intrusion vector or the social engineering tactics employed. The victim organization's identity is not disclosed.

PoisonX: The Microsoft Signature as an Evasion Weapon

PoisonX was published on GitHub on April 7, 2026 by an account named "oxfemale," which describes it as a "research tool." According to the LinkedIn profile cited by the source, the author presents herself as a Russian researcher specializing in reverse engineering and releases red team tools on a weekly or daily basis. Symantec does not independently verify this national affiliation, which remains a self-presented claim.

The driver possesses a valid Microsoft Hardware Compatibility signature. Symantec researchers could not determine the steps that led to obtaining the signature or the mechanism by which the attackers — or those acting on their behalf — convinced Microsoft to sign the binary. The valid signature allows PoisonX to load in kernel mode on Windows systems without triggering reputation-based blocking alarms.

"it is easy to say that yes, it shouldn't have been signed by Microsoft. However, we do not know the steps taken by the attackers to get the driver signed or how they might have tricked Microsoft into doing so." — Brigid O Gorman, Symantec

The 14-Tool Kit: When Open Source Becomes Offensive Infrastructure

In the post-exploitation phase, Hyadina deployed 14 open-source tools for credential theft on Windows systems. The composition is specific: 13 utilities come from NirSoft, a well-known developer of administration and password recovery tools, plus one instance of Mimikatz for in-memory credential extraction. The programs cover browser stealer, email and IM stealer, Wi-Fi traffic interception, and network functions.

The choice of legitimate utilities complicates signature-based detection: no binary is inherently malicious, and their isolated presence does not constitute a reliable indicator of compromise. The source does not specify which credentials were actually exfiltrated or the nature of the data subsequently encrypted by GodDamn.

Why Microsoft's Blocklist Can't Keep Pace with Attacker Speed

Microsoft maintains the Vulnerable Driver Blocklist, a catalog of drivers known to be abusable for BYOVD techniques. The mechanism is reactive: a driver is identified, reported, evaluated, added to the list, and the list is distributed to enterprise endpoints. Between these stages lies an interval that Symantec quantifies as days, more often weeks.

"There is a lag of days, more often weeks, between a driver being identified and the blocklist update reaching enterprise endpoints. This means that only a subset of known vulnerable drivers is blocklisted at any given time, and unfortunately, attackers often move quicker than the blocklist." — Brigid O Gorman, Symantec

Brigid O Gorman, the Symantec researcher cited by the source, emphasizes that this temporal asymmetry is structural, not contingent. RaaS groups rotate drivers at a weekly cadence; the blocklist, by its centralized and manual nature, inevitably accumulates lag. The consequence is a systemic vulnerability window in which drivers already known to attackers circulate freely on endpoints that have not yet received the update.

Why It Matters

The dossier does not document specific remedial measures issued in response to this campaign. No emergency patches, direct vendor advisories, or CVEs assigned to PoisonX or the described BYOVD mechanism emerge.

The primary source does not specify how target organizations should modify their endpoint configurations in response to Hyadina. The brief does not list hardening recommendations, group policies, firewall rules, multi-factor authentication requirements, or backup procedures.

What the dossier documents is an alternative detection approach: Symantec and Carbon Black implement driver-agnostic behavioral monitoring that intercepts anomalous IOCTLs — including requests to terminate processes directed at security products — regardless of the reputation or signature of the driver involved. The source does not quantify the prevalence of this capability among customers or measure its effectiveness against GodDamn in the wild.

The geographic scope of the GodDamn campaign, the total number of victims, and the exact start date of operations with the new locker remain unknown. The described incident dates to late May; the article is published July 9, 2026.

The Lesson: Signature Does Not Equal Trust, and the Kernel Does Not Forgive

The GodDamn/Damn/Hyadina/PoisonX case (the locker name varies between GodDamn and Damn across sources, with GodDamn as the primary form) illustrates an architectural tension in Windows: a valid Microsoft signature opens the kernel, and a compromised kernel zeroes out everything that relies on user-mode. EDRs, AVs, API hooks become mute lines of code when an authorized driver sends termination IOCTLs.

The paradox is that Microsoft inadvertently signs the weapon that disarms its own defense systems. The answer is not to abolish signing — kernel mode requires a trust model — but to recognize that the trust point has become a primary target. Symantec researchers insist on the shift from file-identity-based detection to driver-behavior-based detection. The brief does not specify whether other endpoint vendors have implemented analogous capabilities.

For security teams, the concrete question is whether their endpoint products implement driver-agnostic IOCTL monitoring. The source does not provide a verification checklist but identifies the technical criterion to demand: the ability to detect suspicious driver-process interactions regardless of the driver's signature or reputation.

Hyadina continues to operate. GodDamn is the group's third locker in roughly four years. The release cadence of "oxfemale" on GitHub suggests that the catalog of signed and weaponizable drivers grows faster than any reactive blocklist.

Information is based on the cited advisory and current as of publication.

FAQ

What exactly is the BYOVD technique?

Bring Your Own Vulnerable Driver: the attacker introduces a legitimately signed driver that presents abusable functionality (process termination, kernel memory read/write, protection bypass) to evade endpoint defenses. The valid signature allows loading in kernel mode where the driver operates above user-mode controls.

Can I protect myself by updating the Microsoft blocklist?

The source indicates the blocklist suffers structural delays of days or weeks. It is not a sufficient tool against attackers who rotate drivers weekly. The brief does not document immediate operational alternatives.

Is "oxfemale" the attacker?

No. She is the author of the PoisonX tool on GitHub. A direct link to Hyadina is not proven. The source reports the LinkedIn claim of Russian nationality but does not verify it independently.

Information is based on the cited source and current as of publication.

Sources

Sources and references