Ransomware Used Microsoft-Signed Malicious Driver to Kill EDR: 10 Hosts Hit Before Encryption

A ransomware operation that has quietly evolved for four years just achieved something security researchers say they had not seen before: it obtained a legitimately signed Microsoft kernel driver designed exclusively to destroy endpoint security software — and used it to blind defenses across at least 10 machines inside a single victim organization before anyone could respond. Broadcom’s Symantec Threat Hunter Team disclosed the campaign on July 9, 2026, naming the ransomware GodDamn and the kernel driver PoisonX. The disclosure matters to any organization running Windows endpoints because the technique it describes renders standard endpoint security software structurally inoperative — not circumvented, not evaded, but forcibly switched off — before a single file is encrypted.

The group behind GodDamn, tracked by Symantec as Hyadina, has operated continuously since March 2022 — per the Symantec Threat Hunter Team. Its prior products — Monster ransomware, then Beast ransomware after a June 2024 rebrand — targeted healthcare, manufacturing, and education organizations across the United States while deliberately avoiding machines in Commonwealth of Independent States countries. GodDamn represents the group’s third product, and the addition of PoisonX marks a technical escalation the prior iterations did not carry: a kernel-level weapon that every security tool running in user space is powerless to resist.

Why Your Endpoint Security Cannot Stop PoisonX Once It Loads

To understand what PoisonX does and why it works, you need to know one thing about how Windows manages trust between software layers. The operating system divides its execution environment into privilege rings. Ordinary applications — word processors, browsers, even the dashboard interfaces of security products — run in Ring 3, also called user mode. They can only read and write their own memory, and they must ask the kernel for anything more sensitive. Kernel-mode code runs in Ring 0. It has unconditional access to all memory, all hardware, and the ability to terminate any process on the machine — as explained in Windows kernel-mode architecture.

Endpoint detection and response tools, or EDR products, protect themselves from tampering using a feature called Protected Process Light, which prevents user-mode administrators from killing them. But tamper protection operates at Ring 3. A process running in Ring 0 does not need to ask — it can reach directly into the memory space of a security process and terminate it, regardless of what protections that process has set up for itself. That is exactly what PoisonX does.

PoisonX (stored on disk as g11.sys) is not a flawed driver that attackers found and weaponized — it is a driver written specifically to kill security software, with an undocumented IOCTL interface that receives kill commands from attacker-controlled code. When symantec.exe — an executable the attackers named after Symantec’s own product — drops PoisonX into the Windows system driver store and registers it as a service, the driver loads immediately and begins removing the kernel callbacks that EDR tools use to receive notifications about system events. Those tools keep running. Their dashboards show green. But they have gone blind — the OS is no longer telling them what is happening on the machine.

Microsoft Signed PoisonX: What the Signature Actually Means

The most unsettling detail in Symantec’s July 9 disclosure is not that PoisonX exists. It is that PoisonX carries a valid “Microsoft Windows Hardware Compatibility Publisher” signature — meaning Microsoft’s own Hardware Compatibility Program processed and signed this driver.

This is unusual enough that Brigid O Gorman addressed it directly: “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.”

The gap that explanation reveals is structural. Microsoft’s driver signing program verifies publisher identity — it confirms that whoever submitted this driver went through the Hardware Dev Center verification process. It does not analyze driver behavior or scan for malicious IOCTL interfaces. A developer who successfully passes identity verification and submits a driver framed as a security research tool can receive a signature for code designed exclusively to terminate antivirus processes. The system is not broken; it is operating exactly as designed. The design simply does not account for a developer acting in bad faith while presenting legitimate credentials.

PoisonX’s author, who operates under the GitHub alias “oxfemale” and self-identifies on LinkedIn as a Russian security researcher, published the driver on April 7, 2026, describing it as a research tool. Symantec’s position is unambiguous: the driver has no legitimate use case. Within weeks, it had been weaponized by the Hyadina group and incorporated into the GentleKiller toolkit distributed to affiliates of The Gentlemen ransomware-as-a-service operation, which had claimed 478 victims across more than 70 countries by June 2026.

How the June 2026 Attack Unfolded Across Four Days

The incident Symantec analyzed in detail ran from May 29 to June 3, 2026, and represents a deliberate, staged intrusion rather than a smash-and-grab. The exact method by which Hyadina first obtained access to the victim organization is unknown — the initial access vector was never identified.

The first confirmed malicious activity appeared on May 29, when an AnyDesk remote-desktop installation appeared on Computer 1 inside the organization. The file was not in a standard installation directory — it was in the user’s Music folder, a location inconsistent with authorized IT deployment. It was making outbound connections to unknown IP addresses. The attackers had already been inside.

On May 30, the operators moved to a second host and staged symantec.exe in the Music folder. The file dropped PoisonX into the system driver store as g11.sys [SHA-256: 2d91a78e739891c9854c254f5b2a6b84c0e167dfa253466cbccd2cdd1c20145d]. On the same host, a 14-tool credential-harvesting kit appeared in a user profile subdirectory. Thirteen of those tools came from NirSoft, a legitimate Windows utilities site. The fourteenth was Mimikatz. Together, they extracted credentials from browsers, Windows Credential Manager, cached domain logins, VNC sessions, email clients, Wi-Fi profiles, and live network traffic, per the Symantec Threat Hunter Team.

By June 2, the operators had used PsExec to move laterally and install AnyDesk — as a registered Windows autostart service — across at least 10 hosts inside the organization. After completing each AnyDesk installation, they terminated the running AnyDesk process, waited briefly, and rebooted the machine. The result was a persistent remote access foothold that survived restarts, distributed across a double-digit number of systems.

On June 3, the encryption payload appeared on a separate network segment. The binary — encrypter-windows-gui-x86.exe — deployed from the user’s Downloads or Music folder and renamed encrypted files using the victim organization’s own name as the file extension, rather than the .God8Damn extension Hyadina uses in other campaigns — per the Symantec Threat Hunter Team.

BYOVD Is No Longer a Specialized Technique: It Has Become Standard Criminal Infrastructure

The technique GodDamn employs has a name in the security industry: Bring Your Own Vulnerable Driver, or BYOVD. The standard form of the attack involves finding a legitimate but flawed signed driver — a graphics utility, a game’s anti-cheat component, a hardware monitoring tool — and exploiting its vulnerabilities to reach Ring 0. BlackByte, AvosLocker, Lazarus Group, Qilin, Warlock, and DeadLock have all deployed BYOVD operations.

PoisonX represents a different variant: not a flawed legitimate driver, but a deliberately malicious driver that somehow passed Microsoft’s signing review. That distinction matters operationally. Conventional BYOVD tools exploit a flaw in a driver that has some legitimate purpose — which means the driver may eventually be patched, and the patch reduces the attack surface. PoisonX has no flaw to patch. It does exactly what its author designed it to do. The only mitigation is blocking it by hash or publisher certificate — which is exactly what the Vulnerable Driver Blocklist exists to do.

The problem is timing. The Symantec Threat Hunter Team was explicit in the research report: “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.”

Researchers have independently confirmed the same gap. The Vulnerable Driver Blocklist receives major updates through Windows feature releases — roughly one to two times per year — with more targeted additions for urgent threats, but vendor coordination and compatibility testing take time that attackers do not need. ESET’s March 2026 analysis found 54 distinct EDR killer tools now using BYOVD, collectively abusing 35 signed vulnerable drivers. By the time blocklist coverage reaches a newly weaponized driver, the campaign using it has already run.

What Security Teams Can Do Now

The blocklist gap does not mean endpoint protection is worthless — it means it cannot be the only layer that matters. Symantec’s research and the broader BYOVD literature converge on several controls that function independently of whether a specific driver has been blocklisted yet.

HVCI (Hypervisor-Protected Code Integrity) is the most important. By moving code integrity enforcement into the hypervisor — a layer below Ring 0 — HVCI can block kernel-mode code that has not been explicitly allowed, even if that code carries a valid Microsoft signature. It is on by default for most new Windows 11 devices and can be enabled via Windows Security settings under Device Security → Core Isolation. On Windows enterprise deployments where it is not already active, enabling it should be a priority.

WDAC (Windows Defender Application Control) policies can prevent unauthorized driver loading before a driver reaches the kernel. Microsoft’s recommended driver block rules, available as a downloadable XML policy, cover known vulnerable drivers and can be applied without waiting for a Patch Tuesday update.

Behavioral detection before the driver loads is where the Symantec Threat Hunter Team places the emphasis: “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.” Specifically: AnyDesk and other remote management tools appearing in anomalous directories (a user Music folder is not where IT deploys software); new Windows services of type “kernel driver” appearing outside standard patch cycles; and .sys files appearing in user-writable directories rather than System32drivers.

Driver installation event monitoring provides an early warning that does not depend on signature knowledge. Sysmon Event ID 6 records driver load events. Windows Code Integrity logs record Event ID 3077 when a blocklisted driver is denied. Neither requires knowing in advance which driver an attacker will deploy.

Air-gapped or immutable backups are the backstop. An attacker who reaches 10 hosts and successfully blinds defenses across all of them before encryption begins has won the detection-and-response game. Recovery depends entirely on backups that the attacker could not reach from a compromised domain controller.

A Four-Year-Old Threat Actor, Improving With Each Iteration

Hyadina first appeared in March 2022, when it deployed Monster ransomware — a Delphi-based locker targeting 32-bit Windows systems, distributed as a typical ransomware-as-a-service operation through affiliates. A November 2022 attack documented by Symantec featured the same toolkit pattern visible in the June 2026 GodDamn attack: Mimikatz, NirSoft tools, AnyDesk, and NetScan. The toolset has not changed significantly in four years. The defense evasion capabilities have changed substantially.

Beast replaced Monster in June 2024, adding stronger encryption, multi-threaded processing, and broader targeting. GodDamn replaced Beast in May 2026 and added PoisonX. The progression is not a new group entering the field — it is one persistent developer, tracked under the Hyadina alias, systematically improving the same operation.

Symantec’s conclusion was direct: “GodDamn’s use of the relatively newly discovered PoisonX malicious driver component represents an escalation in defensive evasion capability by this group, indicating that Hyadina is continuing to actively develop its ransomware and its capabilities.” Ransom negotiations in GodDamn intrusions use a combination of email contact and the qTox encrypted messaging application, per CYFIRMA.

The GodDamn campaign remains active. Symantec has published indicators of compromise, including the SHA-256 hashes for PoisonX (g11.sys) and symantec.exe, on the Symantec Protection Bulletin. Organizations should cross-reference these hashes against their endpoint inventory and driver stores regardless of whether their EDR has flagged anything — the entire point of PoisonX is that an EDR that has been blinded will not flag what came after.

Frequently Asked Questions

What is BYOVD and how does GodDamn use it?

BYOVD, or Bring Your Own Vulnerable Driver, is a technique in which an attacker loads a legitimate, signed Windows kernel driver and then exploits it to reach Ring 0 — the highest privilege level on a Windows system. From Ring 0, the attacker can terminate any running process, including endpoint security software with tamper protection enabled. Most BYOVD attacks exploit a flaw in an existing legitimate driver. GodDamn uses a different variant: PoisonX is a purposefully malicious kernel driver that its author obtained a legitimate Microsoft Hardware Compatibility Publisher signature for, apparently by misrepresenting its function during the signing submission process. Once loaded, PoisonX terminates security processes and removes kernel callbacks — the notifications that EDR tools rely on to detect suspicious activity.

If my EDR is running, does that mean I am protected?

Not necessarily. PoisonX removes the kernel callbacks that EDR tools register with the operating system to receive event notifications. After PoisonX runs, an EDR product may continue running — its dashboard may show it as healthy — but it will no longer receive alerts about process creation, driver loads, or file activity on the machine. This is a structural limitation: security software operating in user space (Ring 3) has no reliable mechanism to detect or resist a process operating in kernel space (Ring 0). The controls that operate below or at the kernel level — HVCI, WDAC application control policies, and detection rules that fire on the driver-installation event itself — are the ones that remain effective after a BYOVD attack begins.

Why did Microsoft sign a driver designed to kill security software?

Microsoft’s driver signing program verifies publisher identity, not driver behavior. The Hardware Compatibility Program confirms that the person submitting a driver completed identity verification and passed the compatibility testing process — it does not analyze whether the driver’s IOCTL interface is designed for malicious process termination. PoisonX’s author submitted it as a “research tool.” Symantec’s researchers confirmed it has no legitimate use case, and stated that “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.” This is a known structural gap in the trust model: identity verification and behavioral review are different problems, and the current signing program only solves the first one.

What is the fastest thing an organization can do to reduce exposure to this specific attack?

Enable HVCI (Hypervisor-Protected Code Integrity) on Windows endpoints where it is not already active. HVCI enforces code integrity at the hypervisor level — below Ring 0 — and can block kernel-mode drivers that have not been explicitly allowed, even if they carry a Microsoft signature. It is the only commonly available control that operates below the kernel-level attack surface that PoisonX exploits. For environments where HVCI is not immediately deployable, configure WDAC policies to block unauthorized driver loading, apply Microsoft’s recommended driver block rules, and instrument endpoints with Sysmon Event ID 6 monitoring to detect suspicious driver installations before encryption begins.