Signed Does Not Mean Safe: GodDamn Ransomware Used a Microsoft-Signed Driver to Kill EDR — Your 2026 Defense Playbook

Per the Symantec Threat Hunter Team, reported by The Hacker News, Dark Reading and Infosecurity Magazine on 9–10 July 2026, the Hyadina ransomware-as-a-service crew — a roughly four-year-old operation whose locker rebranded from Beast and, earlier, Monster — deployed a new locker called GodDamn against US healthcare, manufacturing and education organisations. The intrusion used PoisonX, a malicious kernel driver carrying a legitimate Microsoft Hardware Compatibility signature, published on GitHub on 7 April by an author using the handle oxfemale and described as a research tool. PoisonX kills security-related processes and strips user-mode API hooks, blinding endpoint protection. In one case Hyadina combined legitimate RMM software, more than a dozen penetration-testing tools, open-source stealers and PsExec lateral movement to reach around 10 hosts before encryption. The operational lesson: signature trust is no longer a security control, and mid-market defenders need a six-control playbook that assumes it.

CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai

Signed Does Not Mean Safe: GodDamn Ransomware Used a Microsoft-Signed Driver to Kill EDR — Your 2026 Defense Playbook

Signature trust is no longer a security control

On **9–10 July 2026**, the **Symantec Threat Hunter Team** published the analysis behind coverage in **The Hacker News**, **Dark Reading** and **Infosecurity Magazine** of a ransomware campaign that should force a reset in how mid-market security teams think about endpoint protection. The **Hyadina** ransomware-as-a-service crew — a roughly four-year-old operation whose locker was previously known as **Beast** and, earlier still, **Monster** — deployed a new locker called **GodDamn** against US organisations in **healthcare, manufacturing and education**.

The technical centrepiece of the campaign is a kernel-mode driver called **PoisonX** that carries a **legitimate Microsoft Hardware Compatibility signature**. Symantec observed PoisonX being used to **kill security-related processes** and to **remove user-mode API hooks**, blinding endpoint-detection-and-response (EDR) and other user-mode security products before the ransomware executes. According to the Symantec write-up, the driver was **published on GitHub on 7 April 2026** by an author using the handle **oxfemale**, and described there as a research tool.

The operational lesson is not "another BYOVD story". It is bigger than that. Bring-Your-Own-Vulnerable-Driver campaigns weaponise a legitimate signed driver that happens to contain an exploitable bug. This is a different failure mode: a driver **whose behaviour is malicious by design** shipping with a **valid, current Microsoft signature**. When malware ships with a legitimate Microsoft signature, **allowlisting-by-signature and out-of-the-box driver policies fail closed on nothing**. Every mid-market defender who has, in effect, been outsourcing driver trust to "if Windows loaded it, it must be fine" needs a different operating model in 2026.

Attribution and what Symantec actually observed

Per **Symantec's Threat Hunter Team** analysis, cited by The Hacker News, Dark Reading and Infosecurity Magazine, the intrusion Symantec dissected followed a shape mid-market SOC teams should study directly rather than in summary.

The initial access vector and the specifics of persistence Symantec keeps to their private customer telemetry, but the operator toolkit is public. In one intrusion the attackers combined:

The kill chain reached approximately **10 hosts before encryption**. That is not a stealthy long-dwell campaign; it is a fast, wide sweep that assumes the security team will not detect the driver load or the mass process kills until after the ransom note lands.

**Hyadina** itself, per the Symantec analysis, is a roughly four-year-old ransomware-as-a-service operation. The locker line runs **Monster → Beast → GodDamn**, which is a common rebrand pattern for RaaS crews trying to shed leak-site heat, refresh affiliate marketing or evade sanctions and law-enforcement attention on a specific brand. The relevant point for defenders is that this is not a new, unknown actor; the tradecraft is production-grade and the operator has an installed base of affiliates.

**PoisonX**, per the Symantec write-up, was published on GitHub on 7 April 2026 by the handle **oxfemale** and described as a research tool. Whether the original publication was in good faith is not the operational question. The operational question is that the resulting driver, once obtained, carries a valid Microsoft Hardware Compatibility signature and behaves as a purpose-built EDR-blinding tool in the hands of a ransomware crew.

Why "signed = safe" was already dead

Even before GodDamn, the "signed driver equals trusted driver" heuristic was already the wrong instinct. BYOVD campaigns had been publicly documented for years, ransomware crews had shipped vulnerable-legitimate drivers to disable EDR, and Microsoft itself had responded with the **Microsoft vulnerable driver blocklist** (now enforced by default on Windows 11 in most configurations and available on Windows 10 and Windows Server via policy). What GodDamn does is close the last gap in the pre-2026 defender mental model:

For a broader view of the vulnerable-driver angle, see our companion piece on [Anubis ransomware, Citrix Bleed 2 and EDR killers](/en/blog/anubis-ransomware-citrix-bleed-2-edr-killers-resilience-playbook-2026), which covered the earlier BYOVD pattern in detail; the July 2026 GodDamn campaign is the next step along the same axis, not a substitute for that reading. The RMM abuse component of the GodDamn intrusion also connects directly to our earlier work on [remote support software as an attack surface](/en/blog/remote-support-software-attack-surface-helpdesk-security-2026).

The six-point 2026 defense playbook

The six controls below are the operational response mid-market defenders should implement or verify before the next Hyadina-affiliate campaign lands. None of them is exotic. The value is in operating the set coherently.

1. Enable and keep updated the Microsoft vulnerable driver blocklist — and consider WDAC custom driver policies

The **Microsoft vulnerable driver blocklist** is the baseline. On Windows 11 it is enforced by default in most configurations; on Windows 10 and Windows Server it can be enabled via policy. Verify **enforcement**, not just presence — a blocklist in audit mode logs and moves on. For mid-market environments with a small, well-known set of legitimate kernel drivers, **Windows Defender Application Control (WDAC) custom driver policies** are the higher-assurance option: a positive **allowlist** of driver publishers and hashes that permits only the drivers your estate actually needs. WDAC is operationally more expensive to run than the blocklist because it requires an inventory and a change process, and it is where mature 2026 posture is heading.

2. Enable HVCI (memory integrity) end to end

**Hypervisor-protected Code Integrity (HVCI)**, exposed in the Windows Security app as **Memory Integrity**, is the platform control that isolates kernel-mode code integrity checks inside a virtualisation-based-security enclave and prevents an attacker who has already gained kernel-mode execution from tampering with the check itself. HVCI blocks specific classes of kernel manipulation techniques that unhookers and process-kill drivers rely on. It has real hardware and driver-compatibility requirements — which is why estates that turned it off once in 2022 to fix a driver often never turned it back on. Re-audit HVCI coverage across the fleet as a specific line item, not as part of a general endpoint hardening ticket.

3. Move detection from signature reputation to behaviour on kernel driver loads and mass process kills

If PoisonX carries a valid Microsoft signature, then any EDR strategy that rests on **signature reputation** for kernel drivers is defeated by design. The 2026 detection posture is **behavioural**:

These are all detections your EDR platform can generate; the question is whether they are enabled, tuned and monitored.

4. Monitor and restrict RMM tooling and PsExec usage

The Hyadina intrusion combined **legitimate RMM software** for control and **PsExec** for lateral movement. Both are dual-use and both need governance:

Mid-market environments overwhelmingly ship with unrestricted PsExec use as a "just how IT works" assumption; that assumption is a live gift to any operator with a working set of stolen credentials.

5. 24/7 MDR because the access-to-encryption window is now measured in hours

The GodDamn intrusion reached approximately 10 hosts before encryption. The operator did not wait for a business-hours SOC. If your detection stack fires the right alerts but nobody is looking at them between 22:00 and 06:00, the alerts are decoration. The 2026 mid-market posture is **24/7 Managed Detection and Response (MDR)** with a named provider, a documented response SLA (minutes for critical, not hours), and rehearsed hand-off from the MDR analyst to your internal owner. Building a 24/7 rotation internally at mid-market scale is uneconomic for almost every organisation below several hundred employees; the honest answer is to buy the shift, not staff it.

6. Tested offline backups and an incident-response runbook

The last control is the one that decides whether GodDamn is an outage or an existential event. **Tested, offline** backups — immutable, air-gapped or object-lock — with **restore rehearsals** on a documented cadence, and a written **incident-response runbook** that names owners, communication channels, legal counsel, cyber-insurance broker and regulatory-notification obligations. Untested backups are worth their unit-test success rate, which is often lower than intuition suggests.

When to hand this to a managed partner

The six-control stack — vulnerable-driver blocklist and WDAC governance, HVCI coverage, behavioural detection on kernel loads and mass process kills, RMM and PsExec monitoring, 24/7 MDR, backup and IR discipline — is technically standard and operationally expensive. Building it in-house at mid-market scale means a senior security engineer, an EDR-platform specialist, a WDAC and identity engineer, a 24/7 SOC rotation and a backup and IR programme with real budget authority.

Call IT Dev delivers that stack as a managed service from a Morocco nearshore footprint. The [cybersecurity practice](/en/services/cybersecurity) runs the WDAC and HVCI programme, behavioural detection tuning, RMM and PsExec governance and 24/7 SOC/MDR coverage; the [technical support](/en/services/technical-support) practice absorbs the endpoint hardening and driver-blocklist rollout work; the [cloud infrastructure](/en/services/cloud-infrastructure) practice runs the backup, immutability and restore-rehearsal programme. The commercial construct is set out on the [why Morocco](/en/why-morocco) page: nearshore time-zone alignment with EU and UK, English and French delivery depth, **CNDP Law 09-08 and GDPR-aligned** data-protection posture, and a labour-cost basis that lets mid-market buyers fund the full six-control stack rather than only the two they can currently staff.

The GodDamn campaign is not a signal that endpoint protection has failed. It is a signal that the operating model around endpoint protection has to catch up with 2026 attacker economics: signatures are not trust boundaries, quarterly patch reviews are not detection, and 09:00–18:00 monitoring is not coverage.

${CTA_DRIVER}

الأسئلة الشائعة

What did Symantec actually attribute to Hyadina and GodDamn on 9\u201310 July 2026?

Per the Symantec Threat Hunter Team analysis, cited by The Hacker News, Dark Reading and Infosecurity Magazine on 9\u201310 July 2026, the Hyadina ransomware-as-a-service crew \u2014 a roughly four-year-old operation whose locker rebranded from Beast and, earlier, Monster \u2014 deployed a new locker called GodDamn against US organisations in healthcare, manufacturing and education. The intrusion used PoisonX, a malicious kernel driver carrying a legitimate Microsoft Hardware Compatibility signature, published on GitHub on 7 April 2026 by an author using the handle oxfemale and described there as a research tool. PoisonX kills security-related processes and removes user-mode API hooks, blinding endpoint protection.

How is this different from a classic BYOVD (Bring-Your-Own-Vulnerable-Driver) campaign?

BYOVD weaponises a legitimate signed driver that happens to contain an exploitable bug \u2014 the driver was written for a real purpose and got abused. PoisonX is a driver whose behaviour is malicious by design that also happens to ship with a valid current Microsoft Hardware Compatibility signature. The practical implication for defenders is that allowlisting-by-signature and default driver reputation policies do not fail closed on it; the trust boundary that many mid-market estates were leaning on (if Windows loaded it, it must be fine) is defeated by design.

What other tooling did Symantec observe in the intrusion chain?

Per the Symantec write-up, in one intrusion the attackers combined legitimate RMM software for command-and-control and hands-on-keyboard access, more than a dozen penetration-testing tools, open-source information stealers for credential and browser-session harvesting, and PsExec for lateral movement. The kill chain reached approximately ten hosts before encryption \u2014 a fast, wide sweep rather than a long-dwell stealth operation.

What is the six-point 2026 defense playbook?

One, enable and keep updated the Microsoft vulnerable driver blocklist and consider WDAC custom driver policies for higher-assurance environments. Two, enable HVCI / memory integrity end to end and re-audit coverage on hosts where it was disabled for a driver-compatibility reason in prior years. Three, move detection from signature reputation to behavioural rules on new kernel driver loads, mass process kills, EDR-tampering patterns and user-mode API unhooking. Four, monitor and restrict RMM tooling with a written allowlist and alert on PsExec-style remote execution. Five, run 24/7 MDR because access-to-encryption is now measured in hours. Six, keep tested offline / immutable backups and rehearse the incident-response runbook.

Do these controls stop future signed-driver attacks or just this one?

The playbook is designed to raise the cost of the class of attack, not just the GodDamn instance. Vulnerable-driver blocklists and WDAC address the population of known-bad and unauthorised drivers; HVCI raises the cost of kernel-mode tampering even after successful load; behavioural detection catches the effect (mass process kills, EDR unhooking) regardless of how signed the driver is; RMM and PsExec governance addresses the operator toolkit that Hyadina and its peers rely on; 24/7 MDR ensures the alerts are actioned in the operator\u2019s window, not the SOC\u2019s business hours. New signed-driver variants are the reasonable expectation for the rest of 2026, and the playbook is meant to hold against them.

How does Call IT Dev deliver this at mid-market economics?

The six-control stack \u2014 vulnerable-driver blocklist and WDAC governance, HVCI coverage, behavioural kernel-load and process-kill detection, RMM and PsExec monitoring, 24/7 SOC/MDR and backup + IR discipline \u2014 is delivered as a managed cybersecurity service from a Morocco nearshore footprint. The commercial construct pairs nearshore EU time-zone alignment, English and French delivery depth and CNDP Law 09-08 and GDPR-aligned data-protection posture with a labour-cost basis that lets mid-market buyers fund the full stack rather than only the two controls they can currently staff internally.

CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai — contact@callitdev.com — +212-537-373777