Anubis Ransomware: The RaaS Platform Weaponising Healthcare Regulators Against Its Own Victims

The announcement that accompanied the emergence of Anubis ransomware in late 2024 was notable not for its technical claims but for its business model innovation. Alongside the standard double-extortion framework — encrypt files, exfiltrate data, threaten publication — the group introduced a third lever: if the victim fails to pay, Anubis will contact the relevant data protection regulator on their behalf.

For a healthcare organisation holding protected health information, that means a threatened report to the US Department of Health and Human Services Office for Civil Rights under HIPAA. For European operators, a report to the relevant national data protection authority. For UK companies, the Information Commissioner’s Office. The threat transforms extortion from a bilateral negotiation into a three-party problem in which the regulator becomes an involuntary participant — and an amplifier.

That regulatory weaponisation is the defining feature of Anubis. Everything else — the Go-based encryptor, the affiliate model, the victim portal — is consistent with the mature RaaS operational template that the ransomware ecosystem has been refining since at least 2019. But the decision to use data protection enforcement infrastructure as a pressure mechanism represents a meaningful evolution in extortion tradecraft.

Group Overview

The group’s name references the Egyptian god of death and the afterlife — a naming convention shared with several ransomware operations that draw on mythology for brand identity. Anubis’s administrative infrastructure, affiliate-facing tooling, and victim communication portal have been characterised by researchers as professionally built and operationally stable, suggesting a core development team with prior RaaS experience rather than a newly formed criminal enterprise.

The Regulatory Pressure Model

Anubis’s regulatory threat mechanism operates as follows: when a victim does not meet the payment deadline after initial extortion contact, the group sends a second communication to the victim organisation notifying them that Anubis will file a report with the relevant data protection authority detailing the data exfiltrated, the categories of data involved, and the organisation’s failure to disclose the breach to regulators within the legally mandated timeframe.

The legal exposure this creates is real. Under HIPAA, healthcare organisations must notify HHS OCR of breaches affecting 500 or more individuals within 60 days of discovery. Under UK GDPR and the EU GDPR, personal data breaches must be reported to the supervisory authority within 72 hours of discovery where the breach is likely to result in a risk to individuals’ rights and freedoms. If an organisation has been aware of a breach — as a ransomware victim clearly has been — but has not notified the regulator while paying or attempting to negotiate, the regulatory exposure is genuine and potentially significant.

Anubis’s extortion communications explicitly reference this dynamic. Observed messages from the group tell victims that their failure to pay will result in “mandatory notifications to [HHS OCR / ICO / relevant authority]” along with publication of stolen data. The threat is calibrated to the victim’s regulatory environment: US healthcare victims receive HIPAA-specific language, European victims receive GDPR-specific language.

This is more sophisticated than the standard data leak threat. Most victims — and their legal counsel — are aware that published stolen data is reputational damage but may not constitute an independent regulatory violation, since the theft itself is the notifiable event rather than the publication. The regulatory notification threat is different: it positions Anubis as capable of initiating enforcement action against the victim, and because the 72-hour or 60-day clock has often already expired by the time victims are making payment decisions, it creates time pressure with a legal dimension.

There is debate among legal and security practitioners about how effective this tactic actually is. Regulators do not uniformly impose maximum penalties for breach notification delays when organisations cooperate with investigations, and paying ransom does not necessarily prevent regulatory action if the breach is eventually disclosed through other means. But the threat adds complexity and cost to the victim’s decision-making, and the healthcare sector — already under intense regulatory scrutiny following a wave of significant incidents — is particularly sensitive to this pressure.

Technical Profile

Anubis’s encryptor is written in Go. The choice of Go has become increasingly common in the ransomware ecosystem since the mid-2020s because Go produces statically linked binaries that do not require runtime dependencies, cross-compiles easily for Windows, Linux, and macOS from the same codebase, and its concurrency primitives (goroutines) facilitate fast parallel encryption of file systems.

Encryption scheme. Anubis uses AES-256-CTR for file encryption with a per-file key derived from a session key generated at runtime. The session key is asymmetrically encrypted with an attacker-controlled RSA-4096 public key embedded in the binary. This is a standard hybrid encryption pattern: symmetric encryption for speed, asymmetric for secure key exchange. Without the RSA-4096 private key held by the operators, file recovery without a decryptor is not feasible.

File targeting. The encryptor targets a broad range of business-relevant file extensions across document, database, archive, image, and virtual machine categories. It specifically identifies and prioritises VMware VMDK files and similar virtual disk formats, reflecting the modern enterprise’s heavy use of virtualisation. Backup-adjacent paths and VSS (Volume Shadow Copy Service) deletion are standard behaviour — the encryptor attempts to delete shadow copies via vssadmin.exe delete shadows before or during encryption.

Encrypted file extension. Affected files receive a .anubis extension appended to their original filename.

Ransom note. A ransom note file is dropped in each encrypted directory with a standard format: a victim ID, instructions for accessing the Tor-based negotiation portal, and the regulatory threat language outlined above.

Anti-analysis features. Observed samples include basic anti-sandbox checks (looking for signs of virtualised analysis environments), binary packing, and string obfuscation. The tooling is functional rather than sophisticated — consistent with a production RaaS product built for reliability over advanced evasion.

Data exfiltration. The double-extortion data theft component uses rclone or custom tooling for exfiltration to attacker-controlled cloud storage. Exfiltration precedes encryption in standard operations, consistent with other mature RaaS groups. The exfiltration stage is where most of the sensitive data categories relevant to the regulatory threat are harvested.

Affiliate Model and Recruitment

Anubis recruits affiliates through established dark web forums and via direct outreach to experienced threat actors with demonstrated access to high-value networks. The core terms are:

• Standard split: 80% to the affiliate, 20% to the Anubis core team
• Data-theft-only operations: 60% to the affiliate, 40% to the core team (reflecting the value the core team derives from operating the leak site and managing regulatory notification threats)
• Affiliates are provided with: a web-based panel for managing victims, the encryptor binary builder (configurable targets, ransom note customisation), a negotiation portal, and access to the core team’s data exfiltration infrastructure

The 80/20 split is standard for competitive RaaS platforms — LockBit operated on similar terms during its peak. The lower split for data-theft-only operations is unusual: most RaaS groups do not offer a data-exfiltration-without-encryption product. Anubis’s willingness to monetise data theft separately reflects awareness that some targets — hospitals, for instance — may have sufficiently resilient backup infrastructure that encryption pressure is less effective, while the regulatory notification threat remains powerful regardless of whether files are encrypted.

Recruitment materials observed by researchers emphasise the group’s technical stability, payment reliability, and the “regulatory leverage advantage” as differentiators from competing platforms.

Targeting and Victim Profile

Healthcare is Anubis’s dominant sector by victim count in 2026. At least 17 US healthcare organisations have been claimed as victims this year, including hospital networks, outpatient care providers, dental groups, and health insurance administrators. This targeting pattern is not accidental: healthcare organisations hold PHI that creates HIPAA exposure, typically lack the incident response maturity of financial services firms, and face operational pressure that creates incentive to resolve ransomware incidents rapidly.

Beyond healthcare, claimed victims span financial services, legal practices, local government entities, and manufacturing. The common thread is not industry sector but data category: Anubis affiliates appear to be sourcing targets partly through initial access brokers advertising corporate network access with confirmed presence of regulated personal data categories.

The geographic distribution of claimed victims is primarily North American (reflecting the HIPAA regulatory leverage available) with secondary concentration in EU and UK organisations where GDPR enforcement creates equivalent pressure.

Initial Access

Anubis does not appear to use a single consistent initial access method. Observed entry points across investigated incidents include:

Phishing with credential harvesting. Spearphishing campaigns delivering credential-stealing malware or directing users to fake authentication portals — particularly Outlook/M365 login pages — providing authenticated access to VPN and email systems.

Purchased access. Initial access broker marketplaces on dark web forums routinely list healthcare network access for sale. Anubis affiliates, like most mature RaaS operators, include IAB purchasing as a standard acquisition channel. Access types seen in Anubis-linked incidents include compromised VPN credentials, RDP sessions, and Citrix access.

Exploitation of internet-facing services. Vulnerability exploitation against VPN appliances (Cisco ASA, Fortinet FortiGate, Ivanti), Citrix Netscaler, and Remote Desktop Services. Healthcare organisations frequently lag on patching enterprise perimeter appliances.

RMM compromise. At least two incidents have involved entry through compromised remote monitoring and management tools used by third-party IT providers supporting healthcare organisations.

Tactics, Techniques, and Procedures

Post-initial access, Anubis-affiliated intrusions follow the established ransomware affiliate playbook:

Discovery and enumeration. ADFind or BloodHound/SharpHound for Active Directory enumeration. Network scanning with internal tools or living-off-the-land alternatives (NetScan, built-in Windows networking commands).

Credential access. LSASS dumping (via ProcDump, Mimikatz, or driver-based approaches), credential extraction from browsers and password stores, Active Directory credential harvesting (DCSync where domain admin is obtained).

Lateral movement. PsExec and WMI for moving between systems. RDP for manual operator access to high-value systems. SMB share enumeration for identifying backup servers and data stores.

Persistence. Scheduled tasks, service creation, and where viable, persistence through compromised domain accounts. Persistence is maintained during the multi-day exfiltration phase.

Exfiltration. rclone configured to exfiltrate data to cloud storage (commonly Mega.nz or attacker-controlled S3 buckets). The exfiltration volume is targeted toward data categories creating regulatory exposure: patient records, financial data, HR and payroll records.

Defence evasion. EDR tampering where accessible (driver-based EDR killers in some incidents). Disabling Windows Defender via PowerShell or Group Policy where administrator access exists.

Execution. Encryptor deployment via PsExec or Group Policy. Domain-wide ransomware execution, typically timed for low-activity periods (overnight, weekends).

Incident Impact

The healthcare incidents where Anubis affiliates have achieved domain-wide encryption have followed a pattern familiar from other ransomware operations targeting the sector: emergency diversion of ambulances, cancellation of non-emergency procedures, reversion to paper-based workflows, and prolonged recovery periods. The regulatory pressure tactic has added legal complexity to several responses, with victim legal teams managing simultaneous considerations of incident response, negotiation, and regulatory notification obligations.

Recovery timelines for investigated incidents have ranged from two to six weeks for core clinical systems, with full recovery of all systems taking longer. The operational impact on patients during these periods is difficult to quantify but represents a real safety concern when healthcare organisations are unable to access records or imaging systems during clinical care.

Defensive Implications

The healthcare sector profile of Anubis victims points to known structural weaknesses that remain unaddressed across much of the sector:

Patch management for perimeter systems. VPN appliances and remote access infrastructure are disproportionately represented in healthcare breach initial access vectors. Patch cadence for these systems needs to be treated as equivalent to clinical device maintenance — not deferred until convenient.

MFA everywhere, particularly VPN. Credential theft against unmfa’d VPN accounts is a recurring entry point. All remote access should require phishing-resistant MFA (hardware tokens or passkeys preferred; TOTP as minimum).

Backup isolation. Air-gapped or immutable backups that cannot be reached from domain administrator accounts are the primary recovery mechanism. Backup systems reachable via the domain are a target, not a safety net.

Regulatory breach notification posture. HIPAA-covered entities should have pre-established regulatory notification procedures that do not depend on ransom payment decisions. The Anubis regulatory threat is most effective when victims have not already assessed their notification obligations. Legal counsel with HIPAA expertise should be part of incident response retainer arrangements.

Incident response readiness. The healthcare sector’s reliance on third-party IT providers creates supply chain risk and adds complexity to initial response. Internal incident response runbooks that do not assume external providers are available are important baseline preparation.

Monitoring for exfiltration. The data theft that enables both the leak site threat and the regulatory notification threat happens before encryption. DLP controls and anomalous outbound data transfer monitoring provide opportunities to detect and interrupt Anubis operations before the encryptor is deployed.

The Anubis group’s innovation is primarily on the business side rather than the technical side. The regulatory notification lever is real, creates genuine pressure, and is calibrated to the victim sector. The defences against it are the same defences against any capable ransomware affiliate: strong perimeter security, MFA, backup isolation, and incident response readiness. What is different is that the regulatory dimension means responding organisations need legal counsel involved from the outset, not after payment decisions have been made.