GodDamn Ransomware Rebrands From Beast and Uses PoisonX Driver to Disable Defenses

GodDamn ransomware has emerged as the latest rebrand of Beast, a ransomware family linked to the earlier Monster operation that first appeared in 2022.

The new variant stands out because attackers used the PoisonX kernel driver to disable endpoint defenses before deploying ransomware. According to Symantec and Carbon Black researchers, the driver can terminate security-product processes and remove user-mode API hooks, reducing visibility on compromised hosts.

The investigated attack began with suspicious AnyDesk activity on May 29, 2026. By June 3, GodDamn ransomware appeared on another network segment, after attackers had staged tools, harvested credentials, moved laterally, and installed remote-access software on at least 10 hosts.

GodDamn is the latest Beast rebrand

GodDamn is not an entirely new ransomware family. Symantec links it to Hyadina, the developer behind Monster and Beast, based on code overlap, tactics, and tool reuse.

Monster first appeared in March 2022 as a Delphi-based ransomware targeting 32-bit Windows systems. It also avoided systems that appeared to be located in countries within the Commonwealth of Independent States.

Hyadina later rebranded Monster as Beast in June 2024. Beast added Linux and VMware ESXi support, improved encryption performance, and gave attackers more control over configuration and targeting.

Ransomware name	First observed	Key traits	Notable changes
Monster	March 2022	Delphi-based ransomware targeting 32-bit Windows systems	Used affiliate-style operations and credential-harvesting tools
Beast	June 2024	Monster rebrand with broader platform support	Added Linux and VMware ESXi targeting
GodDamn	May 2026	Latest Beast-linked iteration	Uses PoisonX and a fake Symantec-named tool for defense evasion

PoisonX gave attackers kernel-level defense evasion

The most important change in the GodDamn attack was the use of PoisonX, a signed kernel driver that can terminate protected security processes from kernel mode.

An earlier Xcitium reverse-engineering report said PoisonX used a Microsoft-signed driver and a hidden IOCTL interface to kill CrowdStrike Falcon by process ID. Xcitium said the driver could bypass user-mode protections because the termination action happened from kernel mode.

Symantec said the PoisonX driver used in the GodDamn intrusion was saved as g11.sys and carried a signature attributed to Microsoft Windows Hardware Compatibility Publisher. The driver was dropped by a fake security tool named symantec.exe.

Why this is different from ordinary BYOVD abuse

Many ransomware groups use bring-your-own-vulnerable-driver tactics to disable security tools. In those attacks, adversaries abuse legitimate, signed drivers that contain exploitable flaws.

PoisonX is more concerning because Symantec describes it as a driver that appears to have been built for malicious use and then signed by Microsoft. That makes it harder to dismiss as a normal third-party driver weakness.

Broadcom’s broader BYOVD research warns that ransomware operators increasingly use trusted Windows drivers to kill, blind, or weaken endpoint security products before encryption begins.

• Kernel-level access lets attackers act below normal user-mode defenses.
• Signed drivers can appear trusted to Windows and security tools.
• Security products may lose visibility before the ransomware payload runs.
• Behavior-based monitoring is needed because hash-based detection can lag behind new driver variants.

Attackers used AnyDesk, PsExec, and credential tools

The first observed activity in the investigated intrusion was AnyDesk running from a user Music folder, a location inconsistent with a normal installation. Symantec said the initial infection vector was unknown.

Attackers then staged a broad credential-harvesting toolkit in a user profile directory. The toolkit included Mimikatz and multiple NirSoft tools capable of recovering credentials from browsers, Windows Credential Manager, cached domain credentials, VNC sessions, email clients, Wi-Fi profiles, and live traffic.

Network discovery also played a role. Netscan was staged with the credential tools, likely to help map reachable systems before lateral movement.

PsExec helped spread the intrusion

On June 1, the attackers began lateral movement using PsExec. Symantec observed a process lineage involving psexesvc.exe, services.exe, and wininit.exe, which confirmed PsExec activity across remote targets.

The attackers used stolen credentials to mount an administrative share on an internal host. They then pushed commands to other machines and configured AnyDesk for unattended access.

AnyDesk was set up with a dedicated configuration directory and a setting that suppressed standard interactive consent prompts. The attackers also registered AnyDesk as auto-start Windows services, giving them persistence after reboots.

Tool or component	Observed role	Defender concern
AnyDesk	Remote access and persistence	Unauthorized remote control across multiple hosts
PsExec	Lateral movement	Remote command execution using stolen credentials
NirSoft tools	Password recovery and credential harvesting	Exposure of browser, email, Wi-Fi, and cached credentials
Mimikatz	Credential dumping	Potential domain credential compromise
symantec.exe	Fake security tool and defense evasion	Dropped PoisonX and helped disable protections
g11.sys	PoisonX kernel driver	Kernel-level termination of security processes

Encryption followed a four-day dwell period

GodDamn ransomware was first detected on June 3, four days after the earliest observed malicious activity. Symantec said that gap was consistent with a dwell period for staging, exfiltration, or additional reconnaissance before encryption.

The ransomware binary was named encrypter-windows-gui-x86.exe and appeared in user profile directories, including Downloads and Music folders.

In some GodDamn attacks, encrypted files receive the .God8Damn extension. In the incident investigated by Symantec, encrypted files were instead renamed with the victim organization’s name as the extension.

Key indicators of compromise

Security teams should not treat a single hash match as the only detection path. The intrusion also involved suspicious file paths, unexpected remote-access setup, Defender changes, driver installation, and PsExec-driven lateral movement.

The following IoCs come from the Symantec report and should be used alongside behavior-based hunting.

Type	Indicator	Description
SHA-256	2d91a78e739891c9854c254f5b2a6b84c0e167dfa253466cbccd2cdd1c20145d	PoisonX driver, g11.sys
SHA-256	b29f91a440527fb621d106a2048f6379fff3263c60aeda9c82ff8c1d5ae880a8	Defense evasion tool, symantec.exe
SHA-256	e097f3b445b63b07afacde8d6a67f0be654dd51e228a3610fb0710a1f7e29a69	GodDamn ransomware, encrypter-windows-gui-x86.exe
SHA-256	45126297c07c6ef56b51440cd0dc30acf7b3b938e2e9e656334886fe2f81f220	AnyDesk executable used in the intrusion
SHA-256	31eb1de7e840a342fd468e558e5ab627bcb4c542a8fe01aec4d5ba01d539a0fc	Mimikatz, mimik.exe
IP address	15.235.230[.]188	AnyDesk relay infrastructure contacted during the intrusion
IP address	185.229.191[.]39	AnyDesk relay infrastructure contacted during the intrusion
IP address	141.95.145[.]210	AnyDesk relay infrastructure contacted during the intrusion
IP address	162.19.171[.]150	AnyDesk relay infrastructure contacted during the intrusion

What defenders should hunt for

Defenders should look for unusual driver installation events, particularly newly created kernel services tied to suspicious driver paths. PoisonX activity is especially concerning when paired with attempts to stop security processes or modify Microsoft Defender settings.

The PoisonX analysis identified a fixed device path and IOCTL-based process-killing behavior. Security teams can use that pattern to hunt for suspicious driver-device access, not only known hashes.

Organizations should also review unauthorized AnyDesk deployments, PsExec activity, new auto-start services, administrative share use, and credential tools running from user profile folders.

• New kernel-mode services created outside normal software deployment windows.
• Security tools stopping unexpectedly before ransomware execution.
• PowerShell commands changing Microsoft Defender real-time monitoring.
• AnyDesk running from Music, Downloads, or other user profile folders.
• AnyDesk services created with nonstandard configuration directories.
• PsExec service activity followed by remote command execution.
• NirSoft password tools or Mimikatz staged together in user directories.

How to reduce GodDamn ransomware risk

Organizations should harden both identity and endpoint controls. The GodDamn intrusion shows how stolen credentials, remote-access tools, and kernel-level defense evasion can combine before encryption begins.

Microsoft’s recommended driver block rules explain that the vulnerable driver blocklist can help block drivers with known security vulnerabilities, malicious behavior, or behavior that circumvents the Windows security model.

Recommended response steps include:

1. Restrict AnyDesk and other remote-access tools to approved hosts and managed configurations.
2. Alert on AnyDesk running from user folders or newly created auto-start services.
3. Monitor PsExec activity, especially when it appears outside IT maintenance windows.
4. Enable tamper protection, Defender protections, and endpoint policy monitoring.
5. Use Microsoft driver block rules and test App Control policies in audit mode before enforcement.
6. Turn on memory integrity where supported and review systems that cannot enable it.
7. Monitor driver installations, service creation events, and suspicious IOCTL behavior.
8. Rotate credentials if Mimikatz or NirSoft password tools appear in the environment.
9. Maintain offline backups and test restore procedures before an incident occurs.

Why GodDamn matters for ransomware defense

GodDamn shows that ransomware operators continue to invest in pre-encryption defense evasion. The ransomware payload is only the final stage of a longer intrusion that includes access, credential theft, remote control, lateral movement, and security shutdown.

The pattern also matches broader driver-abuse research, which shows that attackers increasingly rely on signed kernel components to weaken or disable endpoint defenses.

Security teams should treat suspicious driver loads and remote-access deployment as high-priority ransomware warnings. Microsoft’s driver blocklist guidance can help reduce exposure, but defenders also need behavioral detections that identify attempts to blind security tools before encryption starts.

FAQ