GodDamn Ransomware & the PoisonX Driver: BYOVD Tactics Evolving?
Just caught the Threat Hunter Team's report on the new 'GodDamn' ransomware. It looks like a rebrand of the Beast family, but the addition of the PoisonX kernel driver is a significant escalation.
This is a textbook Bring Your Own Vulnerable Driver (BYOVD) scenario. By loading a malicious driver at kernel-mode (Ring 0), the ransomware can leverage ZwTerminateProcess or patch SSDT hooks to neutralize EDRs and AVs before encryption begins. The PoisonX driver essentially acts as a kill-switch for endpoint defenses.
If you're monitoring for this, standard user-mode heuristics won't catch the driver load itself. You need to be watching Sysmon Event ID 6 or equivalent driver load events. Here is a basic KQL query for Defender/ Sentinel to hunt for non-Microsoft signed drivers loading in unusual contexts:
DeviceEvents
| where ActionType == "DriverLoad"
| where InitiatingProcessFileName !in ("System", "svchost.exe")
| where isnotnull(SHA256)
| project Timestamp, DeviceName, FileName, SHA256, InitiatingProcessFileName, Signer
| order by Timestamp desc
Has anyone seen specific IoCs for the PoisonX driver yet? I'm curious if it's a modified version of a known vulnerable driver or something entirely new.
Good post. We've seen a massive spike in BYOVD attempts this quarter. The only reliable mitigation we've found is strictly enforcing HVCI (Hypervisor-Protected Code Integrity) and leveraging Microsoft's vulnerable driver blocklist.
Even then, if the actor has admin rights to disable HVCI before the payload drops, you're in trouble. We use a PowerShell script to enforce VBS at startup to prevent tampering:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 1
Make sure your BIOS settings are actually compatible, or this will blue-screen legacy hardware.
I analyzed a similar driver last month that was targeting ProcessGuard callbacks. If PoisonX is anything like that, it's likely stripping the kernel callbacks used by CrowdStrike or SentinelOne.
One trick is to monitor for cbt (Callback) changes or handle enumeration anomalies. You can sometimes catch the ransomware mapping the ntoskrnl.exe section to find the callback table addresses. Look for NtQuerySystemInformation calls with SystemModuleInformation class from non-system processes.
This sounds like a nightmare for MSPs managing older fleets. A lot of our clients still have hardware that doesn't support VBS/HVCI.
For those without hardware virtualization support, focus on Application Control (AppLocker/WDAC) to block unsigned drivers entirely. It's a heavy management lift, but it stops the driver load chain dead. We're testing this WDAC policy to block anything not signed by MS:
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access