Researchers have flagged a new ransomware family called GodDamn, and the detail that makes it worth writing about isn't the encryption payload — it's how it gets there. GodDamn employs a malicious kernel driver named PoisonX to neutralize security software as part of its defense-evasion strategy, operating at a privilege level most endpoint protection tools were never designed to fight from below. If your mental model of ransomware defense is "make sure the EDR agent is running," GodDamn is a reminder that an agent running at the wrong privilege level can be turned off by something running at a higher one.
Why kernel-level matters
Most security software — antivirus engines, EDR agents, DLP tools — runs in user mode, also called ring 3 in the classic x86 privilege ring model. User-mode software operates under the assumption that the operating system kernel underneath it is trustworthy and that the kernel will enforce the boundaries the security product depends on: file system hooks, process monitoring, network filtering, tamper-protection flags that stop the product from being disabled. That assumption holds as long as nothing malicious gets access to ring 0, the kernel's own privilege level.
A malicious kernel driver changes that equation entirely. Code running in kernel mode has essentially unrestricted access to the operating system — it can intercept, modify, or simply discard the very system calls and hooks that a user-mode security product relies on to see what's happening on the machine. From ring 0, a driver like PoisonX doesn't need to "beat" an EDR product in a fair fight. It can disable the EDR's kernel hooks, terminate its processes, or feed it false information about what's running — all from a privilege level the EDR itself typically cannot see or defend against, because the EDR's own visibility into the kernel is exactly what's being sabotaged. It's the security equivalent of an attacker gaining root access to a building's control room and simply turning off the cameras rather than trying to dodge them.
This is why kernel-level defense evasion is treated as a categorically more serious problem than user-mode evasion techniques like process injection or living-off-the-land binaries. Those techniques try to hide malicious activity inside legitimate-looking behavior that a vigilant detection product might still catch. A malicious kernel driver instead goes after the detection product's own ability to perceive anything at all.
The BYOVD connection
GodDamn's approach with PoisonX fits into a well-established attack class known as bring-your-own-vulnerable-driver, or BYOVD. Windows requires kernel drivers to be digitally signed to load, which in theory should prevent arbitrary malicious code from ever reaching ring 0. BYOVD sidesteps that requirement not by forging a signature, but by abusing a legitimately signed driver that has its own exploitable vulnerability — one that a genuine hardware or software vendor shipped, got properly certified, and that attackers can load onto a target system and then exploit to gain kernel-level code execution, all without needing their own malicious code to pass signature verification at all.
The pattern has become common enough that Microsoft maintains a dedicated vulnerable driver blocklist specifically to close off known-abusable signed drivers before attackers can load them. Ransomware operators gravitate toward this technique because it directly targets the thing standing between them and successful encryption: security software. Terminate or blind the EDR agent first, and the rest of the ransomware deployment — lateral movement, data staging, encryption — proceeds against a target that's effectively lost its ability to see or respond to what's happening on its own endpoints. Whether PoisonX specifically abuses an existing signed driver or ships as its own malicious driver through some other loading mechanism, the strategic goal is identical to classic BYOVD: get code running at ring 0 so user-mode security tooling becomes irrelevant.
A landscape with no sector loyalty
GodDamn didn't emerge in isolation. The same window in July 2026 has seen a spread of ransomware activity across industries and geographies that share no obvious connective thread beyond opportunism. Qilin hit Cash Canada on June 24 and Chamco on June 30. Safepay published data from rtngmbh.de, a German construction and utility company, on July 6. CRPxO targeted Creative Smiles Pediatric Dentistry on July 10, with roughly 2.5GB of sensitive data reportedly at risk. TheGentlemen went after Xiamen Mibet New Energy, a Chinese solar manufacturer. AiLock targeted Pinturas Prisa, a Mexican paint manufacturer.
Lay those targets side by side and the pattern is the absence of a pattern: gaming and retail, construction and utilities, pediatric healthcare, solar manufacturing, industrial paint production — spread across Canada, Germany, China, and Mexico, hit by at least five distinct named groups within roughly two and a half weeks. This is what ransomware-as-a-service has matured into by 2026. There's no meaningful sector-specific defense strategy anymore, because the affiliates running these campaigns aren't specialists targeting an industry — they're opportunists running a playbook against whatever network they can get initial access to, then handing off to whichever ransomware brand they're affiliated with for the encryption and extortion phase. A pediatric dental practice with 2.5GB of patient data and a Chinese solar energy company have nothing in common operationally, but they're both reachable by the same commoditized access-broker-to-affiliate pipeline that now underlies most ransomware activity.
That's the strategic implication worth internalizing: "we're not a target, we're too small/niche/foreign to matter" stopped being a defensible assumption years ago, and the July 2026 target list makes the point concretely. GodDamn's kernel driver evasion technique is dangerous specifically because it will get bundled into exactly this kind of indiscriminate access-broker distribution model — a defense-evasion capability this effective doesn't stay exclusive to one group's campaigns for long once it's proven to work.
What GodDamn's approach means for defenders specifically
The core problem GodDamn/PoisonX creates is that many organizations' ransomware defense strategy still assumes the EDR agent will be present and functional at the moment of attack. That assumption breaks the moment an attacker can load a kernel driver that blinds or disables it before the encryption payload ever runs. Defenders need to shift some of their assumptions accordingly: detection has to extend to the kernel driver-loading event itself, not just to the ransomware behavior that happens afterward, because by the time the ransomware behavior is visible, the security tooling meant to catch it may already be neutralized.
This also reframes what "good EDR coverage" means. A security product with strong tamper protection — meaning it actively resists being disabled, uninstalled, or blinded even by processes with elevated local privileges — is materially more valuable against this technique than one that simply has good detection signatures. Detection quality doesn't matter if the detector can be switched off first.
Practical takeaways
- Enable and enforce Microsoft's vulnerable driver blocklist (HVCI-compatible where available) across all Windows endpoints — it's specifically designed to stop known-exploitable signed drivers from loading in the first place.
- Implement driver allowlisting through Windows Defender Application Control or a comparable mechanism, so unsigned or unrecognized kernel drivers can't load even if an attacker gets local admin.
- Confirm your EDR/AV product has active tamper protection enabled and tested — not just present in the license, but actually configured and verified to resist local termination attempts.
- Add kernel-level monitoring for driver load events as a detection signal in its own right. A newly loaded, rarely-seen driver on an endpoint is a high-value alert regardless of what happens afterward.
- Don't assume industry or size makes you a non-target. The July 2026 target list spans pediatric dentistry to solar manufacturing — access brokers and RaaS affiliates operate on opportunity, not sector strategy.
- Segment and monitor privileged access broadly, since kernel driver loading typically requires local administrative rights — reducing standing admin privileges reduces the population of accounts that can trigger this technique in the first place.
- Treat ransomware preparedness as an assumption that your primary detection layer might already be compromised at the moment of attack — build offline backups, tested restoration procedures, and network segmentation that don't depend on the EDR agent surviving the initial compromise.
GodDamn is a small, specific data point — one new ransomware family, one kernel driver — but it lands in a landscape that's already telling a bigger story. Ransomware operators are converging on techniques that go after the defender's ability to see the attack at all, distributed through an access-broker ecosystem that doesn't care what industry it's selling into next. Kernel-level evasion used to be a nation-state-grade technique. In 2026, it's showing up in commodity ransomware, which means the defenses built to counter it — driver blocklists, allowlisting, tamper protection — need to move from "advanced hardening" to "baseline configuration" a lot faster than most organizations have budgeted for.