A Signed Driver Makes Endpoint Protection Blind

A driver with a valid Microsoft signature disables protection processes on the endpoint. The security tool continues running but stops reporting anything. This exact pattern was observed by Symantec’s threat-hunter team in the group behind the GodDamn ransomware. The case highlights less a new malware strain than the limits of Windows driver trust.

Related: What really sets EDR and XDR apart  ·  How a ransomware attack unfolds

What lies behind the signed driver

What is a BYOVD attack? Bring Your Own Vulnerable Driver (BYOVD) describes a technique where an attacker with administrator rights installs a validly signed but flawed or malicious driver on the system. Windows verifies the signature, finds it valid, and loads the driver into the kernel-no additional exploit needed.

In the GodDamn case, the driver is named PoisonX and carries a genuine signature from the Microsoft Windows Hardware Compatibility Publisher. Symantec highlights a key difference: classic BYOVD abuses a legitimate but vulnerable driver, whereas PoisonX is a malicious driver from the start, engineered to pass signature checks. Once loaded, it terminates the processes of installed endpoint defenses and removes the user-mode hooks that antivirus and EDR tools use to monitor the system. The agent remains technically active, but its visibility is gone.

GodDamn itself isn’t new. Broadcom attributes the family to an actor called Hyadina and sees it as the successor to Beast, which evolved from the older Monster lineage. PoisonX, however, isn’t exclusive to this group-it’s already documented in other toolkits, making it a widely used component, not an isolated case.

The long prelude before encryption

Encryption is the final act, not the opening move. In the campaign described by Symantec, attackers gained access via the remote administration tool AnyDesk, placing it in an inconspicuous location within the user profile. Next came a bundle of freely available NirSoft tools to harvest credentials.

Only then did the attackers move laterally through the network, disabling Defender using its own administrative commands and setting up persistence services. By the time ransomware was deployed, around ten systems had been compromised. This prelude can last hours or even days-it’s the real detection window.

Why Signature Trust Reaches Its Limits

The common assumption is: what’s signed is trustworthy. The PoisonX case disproves this. A valid signature confirms a code’s origin-but says nothing about its intent. Once an attacker gains administrator privileges, the signature becomes a free pass into the kernel.

Microsoft counters this with a blocklist of known problematic drivers and hypervisor-protected code integrity. Both measures help, but they act reactively. There’s a window between discovering a misused driver and adding it to the blocklist. Not every system has core isolation enabled. Compatibility with legacy software further delays adoption.

What Detection Engineering Actually Delivers

The leverage lies in behavior, not signatures. Loading a kernel driver is a rare, highly observable event. Sysmon logs it with hash, signature status, and path. A driver loaded from a user directory instead of the system folder is a strong red flag.

Equally telling: the creation of a kernel service from an unusual source, or the sudden termination of security processes. Correlate these three events, and you’ll spot the attack before encryption even begins.

Least Privilege as the Foundation

All the controls mentioned share one prerequisite: without administrator rights, no attacker loads a driver into the kernel. That’s why least privilege sits at the start of any effective defense-not the end.

In practice, this means: no permanent local admin rights, just-in-time access for privileged tasks, LAPS for local accounts, and a tiered model that keeps domain admins off endpoints. Blocklists, HVCI, and telemetry only work if widespread admin rights don’t already do half the attackers’ work for them.

Frequently Asked Questions

Each question is locked. Tap to unlock the answer.

What is a BYOVD attack?

Bring Your Own Vulnerable Driver refers to an attacker injecting a validly signed but flawed or malicious driver using administrator privileges. Windows trusts the signature and loads the driver into the kernel, where it operates with the highest system rights.

Is an up-to-date EDR solution enough to counter this technique?

Not on its own. The signed driver targets defenses directly, effectively blinding them. Detection only becomes effective when combined with tamper protection, driver telemetry, and restricted administrator rights.

Does Microsoft’s Vulnerable Driver Blocklist provide reliable protection?

It helps, but it’s reactive. There’s a window between the discovery of a driver and its inclusion on the list. Custom WDAC rules targeting known abusive drivers can help close this gap.

How can you spot this attack in logs?

Three key events stand out: loading a kernel driver from a user directory, creating a kernel service from an unusual source, and the sudden termination of security processes. When correlated, these paint a clear picture.

What’s the most critical first step?

Reducing widespread administrator rights. Without these privileges, no driver can be loaded into the kernel. All other security measures build on this foundation.

Editor’s Picks

Editor’s PickWhat Really Sets EDR and XDR ApartEditor’s PickHow a Ransomware Attack UnfoldsEditor’s PickWhen Attackers Outpace the Patch

More from the MBF Media Network

cloudmagazinFor the first time, you can watch an AI thinkMyBusinessFutureFrom pilot to scale: AI in SMEsDigital ChiefsIT determines whether the spin-off pays off

Image source: AI-generated (July 2026)