GodDamn Ransomware Uses PoisonX Driver to Kill EDR Before Encrypting

Symantec identified GodDamn ransomware using a kernel driver named PoisonX via the BYOVD technique to kill security software before file encryption begins.
Table of Contents
    Add a header to begin generating the table of contents

    Symantec’s threat research team identified a new ransomware operation called GodDamn that neutralizes endpoint security software before deploying its encryption payload by loading a purpose-built kernel driver named PoisonX through the Bring Your Own Vulnerable Driver technique — giving the attacker ring-0 access that no user-mode security process can block, and using it to eliminate defenses before the encryption phase begins.

    How PoisonX Reaches Kernel Level to Disable Defenses

    GodDamn’s approach to disabling endpoint security is not to find a flaw in the security software itself. Instead, the ransomware loads PoisonX — a kernel driver component — by abusing the Bring Your Own Vulnerable Driver technique, which exploits Windows’ trust in signed drivers to gain a foothold inside the operating system kernel before attacking the security layer from above.

    BYOVD works by bringing a legitimate but old or vulnerable signed driver onto the target system. Windows validates the driver’s cryptographic signature and loads it into the kernel as a trusted module. Once loaded, the attacker exploits a vulnerability within that trusted driver to execute attacker-controlled code at ring 0 — the kernel privilege level that places the attacker above every user-mode process on the system, including all endpoint detection and response software.

    How PoisonX Reaches Ring 0 to Terminate EDR Before Encryption Begins

    PoisonX, once loaded into the kernel, systematically terminates endpoint detection and response processes, Windows Defender services, and other security products running on the system. These processes are user-mode or kernel-mode components that PoisonX outranks by virtue of its kernel-level execution. Security tools that would normally quarantine the ransomware payload, generate alerts, or block the encryption process are killed before those capabilities can engage.

    The result is that GodDamn’s file encryption phase runs in an environment where the defensive layer has already been removed. From the security software’s perspective, the attack ends at the moment PoisonX terminates the relevant processes. The encryption phase that follows runs without the interference or detection that a fully operational security stack would provide.

    BYOVD and Why Signed Driver Abuse Defeats Fully Updated Endpoints

    The BYOVD technique is notable because it does not require any unpatched vulnerability on the target system. An organization that has applied all available Windows patches and maintains current endpoint security software is still exposed if the specific driver PoisonX exploits has not been blocked. Windows maintains a Vulnerable Driver Blocklist that, when enabled and current, prevents known vulnerable signed drivers from loading — but the blocklist requires regular updates to cover newly identified drivers, and a driver that PoisonX exploits may not yet be on the list at the time of an attack.

    Microsoft’s Memory Integrity feature, available on Windows 11 Secured Core systems, adds additional constraints on kernel-level driver behavior and can reduce BYOVD risk. These mitigations do not eliminate the risk entirely, as newly identified drivers that bypass current blocklist entries can still be exploited until the blocklist is updated to include them.

    GodDamn in the Context of the BYOVD Ransomware Trend

    Symantec’s disclosure identifies GodDamn as a new entrant to a category of ransomware operations that have adopted BYOVD as a standard component of their attack chain. BlackCat, Akira, and ORCA have all been documented using similar kernel-level driver abuse as part of their pre-encryption defense suppression stages. The emergence of a purpose-built named driver component — PoisonX — rather than reuse of a generic off-the-shelf driver exploit suggests GodDamn is a developed operation with ongoing capability investment rather than a commodity ransomware kit assembled from existing tools.

    Named driver tooling that carries its own identity is typically maintained and updated over time. A threat actor who has invested in developing PoisonX as a distinct capability component has the infrastructure and expertise to update that component as new blocklist entries and defensive controls are added — indicating GodDamn is likely to persist and adapt rather than represent a one-time campaign using disposable tools.

    Symantec’s Finding and the Active Deployment Context

    Symantec confirmed that GodDamn has been deployed against real targets. The disclosure is based on analysis of active incidents rather than theoretical capability assessment. For organizations running Palo Alto, CrowdStrike, Microsoft Defender for Endpoint, or other major endpoint security platforms, the PoisonX component’s ability to terminate these processes from kernel level means that the attack’s initial phase may produce no alerts in the very tools that would normally detect ransomware activity. Investigation after the fact may show a gap in telemetry during the window when PoisonX was operating — a signal that should trigger investigation of driver loading events that preceded the encryption activity.

    Related Posts