A ransomware crew that Symantec tracks as Hyadina is breaking into U.S. organizations with a kernel-mode driver called PoisonX that somehow carries a valid Microsoft Hardware Compatibility signature. Once loaded, the driver terminates security processes and strips user-mode API hooks, clearing the way for the group's newly rebranded GodDamn locker. The intrusion also leaned heavily on legitimate remote-management software, PsExec, and 14 open-source credential-theft utilities — a textbook living-off-the-land and bring-your-own-vulnerable-driver (BYOVD) operation.

Who is Hyadina?

Hyadina is a four-year-old ransomware-as-a-service (RaaS) operation. GodDamn is its latest locker and an evolution of two earlier variants, Beast and Monster. The group concentrates on American targets across sectors such as healthcare, manufacturing, and education, and — according to Symantec — deliberately steers clear of victims in former Soviet states.

In the incident Symantec analyzed, the crew hit an unnamed organization using a grab-bag of dual-use tooling: commercial remote monitoring and management (RMM) software plus more than a dozen penetration-testing programs. The standout component, though, was PoisonX — a signed Windows kernel driver able to kill any process on the machine, security software included.

How the intrusion unfolded

Symantec's researchers were unable to determine the group's initial-access method or social-engineering approach. The first indicator surfaced on May 29, when an unexpected instance of AnyDesk appeared on a compromised host — loaded, oddly, from the machine's Music folder. AnyDesk is legitimate software, but attackers increasingly favor it over traditional shells for hands-on-keyboard access.

The following day, the operators dropped a binary named symantec.exe — a nod to the researchers watching them — onto a second infected computer. That binary deployed PoisonX, the malicious kernel driver bearing a Microsoft Hardware Compatibility signature. PoisonX proceeded to terminate security-related processes and remove user-mode API hooks, neutering the endpoint protection running on the host.

With defenses disabled, Hyadina rolled out a toolkit of 14 open-source utilities aimed at Windows credential theft: browser, email, and instant-messenger stealers; Wi-Fi credential dumpers; and live network-traffic interceptors. Every one of them except Mimikatz came from NirSoft, a well-known source of free Windows utilities.

Chaining the commercial RMM tool, the signed driver, the OSS stealers, and lateral movement via PsExec, the attackers established persistence across the environment before executing the GodDamn ransomware.

The signed-driver problem

PoisonX was published to GitHub on April 7 by an author using the handle "oxfemale," who described it in an accompanying blog post as a "research tool." The same author releases red-team tooling — exploit proofs-of-concept, credential stealers, and antivirus killers — on a near-daily basis, and describes herself on LinkedIn as a Russian security researcher focused on reverse engineering and penetration testing. Dark Reading said it tried to reach her about the intent behind the tools but had not connected by publication.

Symantec is unequivocal about calling PoisonX malware. As the company's Brigid O Gorman put it, the driver has no legitimate use, so "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."

Gorman also stressed why signature-based defenses fall short against this kind of activity: "Unfortunately, almost every tool is potentially malicious when in the wrong hands. This is why things like behavioral and adaptive protection are so important — because they block suspicious behavior on the network, even if that behavior emanates from legitimate-seeming tools, rather than simply blocking obviously malicious files or tools."

Why the blocklist isn't enough

Microsoft ships a Vulnerable Driver Blocklist designed for exactly this scenario: preventing known-dangerous drivers from loading even when they are validly signed, in order to blunt BYOVD attacks. But Gorman cautioned that defenders can't rely on it alone. "There is a lag of days, more often weeks, between a driver being identified and the blocklist update reaching enterprise endpoints," she said. "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."

Technical background: how BYOVD defeats EDR

The following is general, well-established background on this class of attack, not specific detail from the Hyadina case.

Most endpoint detection and response (EDR) products do a large share of their work in user mode, typically by hooking functions inside ntdll.dll so they can inspect calls like NtCreateFile or NtProtectVirtualMemory before they reach the kernel. A signed kernel driver sits below all of that. Running at ring 0, it can:

• Call kernel APIs such as ZwTerminateProcess / PsLookupProcessByProcessId to kill protected security processes that user-mode code can't touch.
• Overwrite or "unhook" the EDR's user-mode hooks — often by mapping a fresh, clean copy of ntdll from disk over the hooked one in memory, restoring the original syscall stubs so the EDR never sees the malicious calls.

Because the driver is validly signed, Windows Driver Signature Enforcement (DSE) loads it without complaint. That is the entire premise of BYOVD: the attacker doesn't bypass code signing — they bring code that is already signed.

Generic hardening and hunting ideas

Defenders can raise the cost of these attacks with a few well-known controls (validate against your own environment before deploying):

• Enable the Microsoft vulnerable-driver blocklist and memory integrity (HVCI). The blocklist is controlled by a registry value under the code-integrity config key:

HKLM\SYSTEM\CurrentControlSet\Control\CI\Config
    VulnerableDriverBlocklistEnable = 1   (REG_DWORD)

Enabling Memory Integrity (Hypervisor-Protected Code Integrity) in Windows Security → Device security → Core isolation turns this on as well. Because of the update lag Gorman described, treat this as one layer, not a complete answer.

• Alert on new kernel-driver loads. With Sysmon, Event ID 6 (Driver loaded) surfaces newly loaded drivers so you can flag unusual or freshly signed ones.
• Watch for RMM tools running from user data folders. A remote-access binary such as AnyDesk executing from %USERPROFILE%\Music (as seen here) is highly abnormal and worth a high-confidence alert.
• Monitor for PsExec-style lateral movement. Remote service creation shows up as Windows System Event ID 7045, which is a strong signal for PsExec-driven execution across hosts.
• Lean on behavioral detection. As Symantec notes, the individual tools here are legitimate or open source; the malicious signal is in the sequence of behavior, not in any single file's reputation.

The Hyadina case is a reminder that a valid signature is a starting assumption, not a guarantee — and that stopping this class of attack depends on catching anomalous behavior rather than known-bad hashes.