Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Ransomware family

Anubis Ransomware Decryption & Data Recovery

  • Active
  • Critical
  • No public decryptor

Anubis is a RaaS operation that surfaced in December 2024, marked by the .anubis extension and a RESTORE FILES.html note. Its defining feature is a built-in /WIPEMODE that permanently zeroes file contents; 2026 attacks on an Adriatic port authority and Coca-Cola's Fairlife brought it mainstream attention.

First seen
2024-12
File extensions
.anubis
Ransom notes
RESTORE FILES.html
Affected platforms
Windows / Linux / VMware ESXi / NAS storage

Family profile

File extensions
  • .anubis
Ransom notes
  • RESTORE FILES.html
Contact patterns
  • A Tor (.onion) negotiation chat portal plus a per-victim ID, supplied inside RESTORE FILES.html
  • Listing with a countdown timer on the Anubis leak site, used as double-extortion pressure
  • Affiliate recruitment on Russian-language forums RAMP and XSS under handles such as superSonic and Anubis__media
  • No fixed mailbox domain in public analysis; contact and payment run through the onion portal
Aliases / versions
Sphinx、Anubis RaaS、Ransom:Win64/Anubis.A
First seen
2024-12
Status
Active
Operational status
Newly emerged
Threat level
Critical
Affected platforms
  • Windows
  • Linux
  • VMware ESXi
  • NAS storage
Tags
  • Emerging
  • Active
  • Ransomware-as-a-Service
  • Double extortion
  • Targets virtualization
  • Targets NAS
  • Phishing
  • Exploits vulnerabilities
Decryptor
No public decryptor

No free public decryptor exists for Anubis. The family has no entry on No More Ransom's decryption tools list, and no vendor or law-enforcement agency has released a tool for it.

The reason is implementation-level. Anubis wraps its keys with Elliptic Curve Integrated Encryption Scheme (ECIES) and encrypts file content with a stream cipher; the operators advertise the combination as "ChaCha + ECIES". Keys are per file, and the operator supplies key material to the encryptor through a /KEY= parameter at launch. Public research has not reported an exploitable RNG or key-derivation flaw, so there is no "implementation bug to free decryptor" path of the kind seen with Rhysida or Akira.

Wipe mode matters even more. When operators detonate with /WIPEMODE, file contents are permanently zeroed - the filename still appears in the directory, but the size is 0 KB. For those files decryption is meaningless in principle: no key restores content that was overwritten. The first action on site is therefore not to hunt for a decryptor but to separate and count encrypted versus wiped files, because that split decides whether the case runs as a recovery job or as an impact-assessment and rebuild job.

Treat any "Anubis decryptor" circulating online as suspect; running unidentified tools can damage data further. We do not pay ransoms, do not negotiate on a client's behalf, and never take on a case with a promise of full recovery.

Latest activity

  1. Leak-site postings continued without pause, with the latest victim listed on 9 September; more than a hundred organisations named in total, led by healthcare, manufacturing and professional services, over half US-based.

    Sources
  2. Anubis claimed Coca-Cola's Fairlife, saying it encrypted the Nutanix platform and stole about 1 TB of data. Four US plants paused production; Coca-Cola confirmed on 27 July that data had been taken.

    Sources
  3. Arctic Wolf detailed Anubis affiliates exploiting CitrixBleed 2 (CVE-2025-5777) to hijack sessions and bypass MFA, holding access via cloudflared tunnels and RMM tools like ScreenConnect; ~83 leak-site victims.

    Sources

Overview

Anubis (early builds codenamed Sphinx) surfaced in December 2024: a Russian-speaking RaaS crew recruiting on RAMP and XSS as superSonic and Anubis__media, with three revenue models - encryption ransom at 80% to the affiliate, data extortion at 60%, access monetisation at 50%, restricted to US, European, Canadian and Australian targets.

What sets it apart is the wiper inside the encryptor. Detonated with /WIPEMODE it permanently zeroes file contents: the filename remains, the size reads 0 KB. Paying for a key restores nothing.

By September 2026 its leak site had named more than a hundred organisations, over half in the United States, then the UK, Australia, France and Canada, concentrated in healthcare, manufacturing, professional services and finance. In June 2026 Resecurity documented an attack on an Adriatic port authority that disrupted cargo tracking and customs processing; in July Coca-Cola disclosed a ransomware attack on its Fairlife subsidiary that halted US dairy production (Fairlife runs four US production facilities), after which Anubis claimed the intrusion on its leak site, saying it had encrypted the Nutanix platform and taken about 1 TB of data - both claims are the attackers' own and were not independently verified, though Coca-Cola later confirmed data was taken.

"Anubis" is an overloaded name, also used for an Android banking trojan and the AnubisBackdoor; both are unrelated, so attribute from the extension and sample characteristics. No mainland-China victim is publicly confirmed, but the entry points - internet-facing Citrix and SSL VPN, remote accounts without MFA - are just as common there.

How to identify it

Extension and note. Files get .anubis appended to the original name (Trend Micro's sample screenshots record it as .anubis. with a trailing dot, while other vendors record .anubis - go by the filenames actually on the host), and an HTML note, RESTORE FILES.html, appears in affected directories, supplying a per-victim ID, a Tor negotiation portal and a publication countdown. No email address is given.

Wipe artefacts are the most misread signal. After a /WIPEMODE detonation the directory fills with files that look normal by name but are 0 KB. Responders often read this as corruption or a disk fault and start chkdsk passes or RAID rebuilds - the most damaging mistake in these cases. Instead, count and map the zero-byte files and tally them separately from the .anubis files.

Other indicators.

  • Encrypted file icons are replaced with the Anubis logo; some builds attempt a wallpaper change.
  • Endpoint alerts carry names such as Ransom:Win64/Anubis.A.
  • Logs show vssadmin deleting shadow copies and database and backup agent processes force-stopped.
  • Linux encryptors are dropped under a six-digit-number_encrypt_x86_64 naming pattern.
  • A leak-site listing with a sample data pack confirms exfiltration already happened.

Bottom line. Extension plus note attributes the family, but the ratio of encrypted to 0 KB files drives the response plan, so inventory first.

Infection vectors

Anubis affiliates concentrate on edge appliances and valid credentials:

  • CitrixBleed 2 (CVE-2025-5777). Pre-authentication memory disclosure against Citrix NetScaler devices configured as Gateway or AAA virtual servers, stealing session tokens and bypassing MFA outright - the dominant 2026 entry point.
  • Valid VPN credentials. From historical breaches, infostealer logs and access brokers; responders have documented legitimate Cisco AnyConnect logins originating from a handful of VPS hosting ASNs.
  • Spear phishing. Targeted mail with malicious attachments or links led the 2025 reporting and started the port authority intrusion.
  • Exposed RDP. Microsoft's family description lists RDP exploitation and malware loaders among the distribution routes.

Beyond CVE-2025-5777, no public report confirms Anubis exploiting another named edge vulnerability; widening the review to every internet-facing remote-access entry point beats matching against a list of product names.

Post-access tradecraft is unremarkable but efficient: persistence through legitimate RMM tooling (ScreenConnect, Zoho Assist, MeshAgent, UltraVNC, mRemoteNG, Total Software Deployment) that blends into normal IT traffic; cloudflared installed on servers and even NAS appliances for outbound tunnels; lateral movement over RDP and PsExec with hypervisor hosts such as Hyper-V as jump points; credential access via Mimikatz, saved browser passwords and ntds.dit; exfiltration with rclone, s5cmd, S3 Browser, WinSCP and PuTTY.

Dwell time can be very short. In one documented case roughly 24 hours elapsed between the tunnelling infrastructure being stood up and the encryptor running. Patching edge appliances and enforcing MFA on VPN remain the cheapest effective controls.

Encryption behavior

Algorithms. File content is encrypted with a stream cipher and each per-file key wrapped with Elliptic Curve Integrated Encryption Scheme (ECIES); the operators advertise the pairing as "ChaCha + ECIES", and reverse engineering places the ECIES implementation in the same lineage as EvilByte and Prince (the Go ecies library). Key material must be supplied through /KEY= at launch, so without the operators' private key there is nothing to invert.

Command-line parameters. /KEY= (key), /elevated (escalation), /PATH= (directories to encrypt), /PFAD= (exclusions) and /WIPEMODE (destruction). Deployment is hands-on-keyboard and scope can differ from host to host, so damage must be inventoried machine by machine rather than extrapolated from one sample.

Behaviour. The encryptor probes access to the physical drive device to test for administrative rights and attempts token manipulation if it lacks them, then deletes volume shadow copies via vssadmin, force-stops database and backup agent processes, and skips critical system directories so the host still boots. Under /WIPEMODE the contents are permanently zeroed: the filename survives, the size does not - the first fact to establish during assessment.

On intermittent encryption. Public research has not reported that Anubis uses intermittent or partial encryption, so do not assume databases and virtual disks retain untouched regions; the overwrite pattern must be measured byte by byte against real samples, and that measurement decides whether page-level rebuilds are viable at all.

Platforms and extortion. The build set advertised in recruitment posts covers Windows, Linux, NAS and ESXi; in the field, Linux encryptors have been dropped and Synology NAS devices compromised, and in the Fairlife case the actors claimed to have encrypted a Nutanix platform. Note that no public analysis of an ESXi encryptor sample exists to date - ESXi support rests on the advertising alone, so treat virtualisation platforms as high risk without assuming a dedicated ESXi build is a settled fact. Data is stolen before encryption, with staged publication on the leak site under a countdown if no payment follows.

Assess before you act

Recoverability assessment

Recoverability has to be answered separately for two classes of file. We do not pay ransoms or negotiate on a client's behalf - our work is technical recovery and forensics.

1) Public decryptor: none. No free or vendor tool covers Anubis and it has no No More Ransom entry. No exploitable weakness has been reported in its ECIES key wrapping, so no plan should rest on waiting for a decryptor.

2) Wiped 0 KB files: not a decryption problem. Content zeroed by /WIPEMODE cannot be restored with any key. Whether anything survives lower down depends on the wipe implementation (in-place overwrite versus truncate and rewrite), the filesystem and the media - chances are worse on SSDs and copy-on-write storage. Test rather than assume, and stop all writes to the affected volumes immediately.

3) Structural repair of large files (depends on the encryption pattern). Because intermittent encryption is unconfirmed, whether database files (MDF/LDF, DBF, ibd) and virtual disks (vmdk/vhdx) retain usable regions must be measured byte by byte. Where only part of a file was overwritten, page-level extraction and logical rebuilds are worth pursuing; where the overwrite is complete, abandon the path early and redirect the outage window to backups and rebuild.

4) Backups, snapshots and shadow copies: currently the realistic main route. Shadow copies are usually deleted, but check everything else - offline and offsite backups, immutable/WORM copies, storage array and NAS volume snapshots, hypervisor snapshots, untouched copies on the backup server, cloud version history. Anubis compromises NAS devices and installs tunnelling tools on them, so NAS snapshots cannot be trusted by default, and backup media must never be reattached to an uncleaned network.

5) Unencrypted copies and log replay. File-server recycle bins, endpoint caches, BI staging databases, ERP archive exports, transaction logs and application audit logs often support reconstruction or point-in-time replay - in wipe scenarios frequently the only surviving source.

6) Low-level carving. Where the encryptor writes a new file and deletes the original, source data may remain in unallocated clusters and can be carved from raw sectors. In wipe mode the yield drops sharply.

7) Breach-impact assessment is part of "recovery" too. Establish the scope and timeline of the exfiltration to drive notification duties, contractual and regulatory handling, and rotation around affected accounts, keys and customer records.

We commit to a verifiable assessment and a clearly bounded recovery scope. We never claim "100% decryption", and no technique guarantees full recovery.

Our response plan

Hit by Anubis ransomware? What to do

  1. Containment, forensics and a zero-byte file inventory

    Isolate affected hosts, hypervisors and NAS appliances from production networks and storage paths and disable VPN accounts - but do not reboot or power off. Anubis persists through legitimate RMM tooling such as ScreenConnect and MeshAgent, so memory and live sessions are central to attribution. Image or snapshot the domain controller, backup server, virtualisation management hosts and NAS first, then export logs from the Citrix/VPN gateway, firewalls and Active Directory. Do one thing other families do not require: inventory the count and distribution of zero-byte files across the estate, tally them separately from .anubis files, and preserve three to five encrypted samples plus the original RESTORE FILES.html.

  2. Family confirmation and encrypt-versus-wipe analysis

    Confirm Anubis from the extension, note structure, replaced file icons and sample characteristics, and explicitly rule out the same-named Android banking trojan and AnubisBackdoor. Then reconstruct the command-line parameters actually used in this deployment (/PATH=, /PFAD=, whether /WIPEMODE was set) and measure overwrite coverage byte by byte against real encrypted samples to establish whether files were overwritten entirely or only in part. This finding decides whether the case proceeds to structural repair or straight to backup-led rebuild; it cannot be assumed from experience.

  3. Dual assessment: recoverability and breach impact

    Run two tracks in parallel. One inventories recovery sources: offline and offsite backups, immutable copies, storage and NAS snapshots (verified as untouched by the actors first), hypervisor snapshots, unencrypted copies and transaction logs, with sample repair tests on the critical databases and virtual disks. The other scopes the exfiltration: reconstruct timeline and volume from the logs and traffic of rclone, s5cmd, WinSCP and similar tools, and determine which customer, employee and contract records are involved. Deliver a written assessment covering which systems are recoverable with expected ranges and timelines, which must be rebuilt, and the basis and deadlines for regulatory notification.

  4. Recovery execution and business rebuild

    All work happens on images or copies with originals kept read-only. Restore in business priority order: domain controllers and identity first (credentials were harvested via Mimikatz and ntds.dit, so a domain-wide reset is mandatory), then core databases such as ERP and MES and the virtualisation platform, then file and mail systems. For data confirmed as wiped, switch promptly to reconstruction from logs, archives and upstream or downstream systems rather than sinking more of the outage window into futile recovery attempts. After each batch, run integrity checks and business-side verification - reconciliation, report comparison, application start-up tests - and record everything in a traceable recovery manifest.

  5. Attribution, hardening and handover

    Reconstruct the full kill chain: whether the Citrix NetScaler was unpatched against CVE-2025-5777, whether VPN lacked MFA, where credentials leaked, and when the cloudflared tunnels and RMM agents such as ScreenConnect were installed. Remove every unauthorised RMM agent, tunnel service, rogue account and scheduled task; reset credentials domain-wide and enforce MFA on VPN; patch edge appliances and revoke existing session tokens; segment the virtualisation and NAS management networks; add baseline alerting for RMM software and outbound tunnels; and rebuild backups to a 3-2-1 design with immutable copies. Close with an incident report and a formal handover checklist.

Risk warning

What not to do

  • Do not treat 0 KB files as a disk fault - no chkdsk or repair passes, no RAID or storage pool rebuilds; those operations destroy whatever low-level remnants still exist.
  • Do not reboot or power off affected hosts and hypervisors. Anubis persists through legitimate tools such as ScreenConnect and MeshAgent, and losing memory and session state removes the basis for both attribution and scoping.
  • Do not run any downloaded "Anubis decryptor". No public tool exists for this family, and unidentified binaries can damage data further.
  • Do not delete RESTORE FILES.html or the encrypted samples, and do not rush into antivirus clean-up - they are the only basis for identifying the family and the deployment parameters used.
  • Do not assume NAS snapshots are safe; the actors compromise NAS devices and install tunnelling tools on them. And never reconnect backup tapes, external drives or the backup server to a network that has not been cleaned.
  • Do not contact the onion portal or pay on your own. Under wipe mode payment does not even establish a technical basis for recovery, and it does not stop already-exfiltrated data from being published.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related scenarios

Related industries

Similar families

FAQ

Anubis Frequently asked questions

  • Can .anubis files be decrypted?

    Not at present. Anubis wraps each file key with ECIES, no exploitable implementation flaw has been reported publicly, and neither No More Ransom nor any major vendor has released a decryptor. Treat any "Anubis decryptor" found online as suspect. The realistic routes are backups and snapshots, unencrypted copies and log replay, and - only where measurement confirms partial overwriting - structural repair of database files. We measure coverage against real samples first and then state a verifiable recovery scope, rather than promising full recovery.

  • Lots of our files are now 0 KB - is the disk failing?

    Usually not a disk problem - it is Anubis's wipe mode. When operators detonate with /WIPEMODE, file contents are permanently zeroed while the filename stays in the directory and the size reads 0 KB. The dangerous response is to treat it as hardware failure: chkdsk passes, RAID rebuilds or storage pool re-initialisation all destroy the remaining low-level remnants. Stop writes to the affected volumes, break the storage paths, inventory the ratio of zero-byte files to .anubis files, and only then choose a strategy. Zeroed content cannot be restored with any key; rebuilding relies on backups, archives and data held in upstream or downstream systems.

  • Will paying the ransom get our data back?

    We neither pay nor negotiate, so this is purely the technical position: under wipe mode the contents are already overwritten, a key cannot restore anything, and payment does not bring zeroed data back. Even for normally encrypted files, paying buys an unverified decryption program, with the attendant risks of instability, further damage and repeat extortion. The leak side does not disappear either - the operators keep a copy that may be resold or recycled. The higher-value action is to establish the exfiltration scope and timeline quickly, complete notification and credential rotation, and spend the outage window on verifiable recovery and rebuild work.

  • Our ESXi or Nutanix virtual machines were encrypted by Anubis - anything we can do?

    There are paths worth assessing, but facts come first. Start by checking whether datastore snapshots, storage array or NAS volume snapshots, and VM-level backups still exist and were not touched by the actors - Anubis attacks hypervisor hosts and NAS appliances, so snapshots cannot be trusted by default. Only if backups are all unusable does structural assessment of the virtual disks make sense: because intermittent encryption is not confirmed for this family, vmdk/vhdx files must be measured byte by byte, and repairing partition and filesystem metadata to mount and extract inner files is worthwhile only where partial overwriting is confirmed. Throughout, do not re-initialise the datastore and do not create new VMs on the original LUN.

  • How does Anubis get in, and what should we close first?

    2026 incident analysis puts CitrixBleed 2 (CVE-2025-5777) against Citrix NetScaler first - stolen session tokens bypass MFA outright. Next come logins with valid VPN credentials (documented against Cisco AnyConnect, from source IPs clustered on a few VPS hosting ASNs) and spear phishing; beyond CVE-2025-5777 no public report confirms exploitation of another named edge vulnerability. Once inside, the actors persist through legitimate RMM tooling such as ScreenConnect, Zoho Assist and MeshAgent and install cloudflared on servers and even NAS devices to open outbound tunnels. The priorities follow directly: patch edge appliances and revoke existing session tokens, enforce MFA on VPN, alert on unapproved RMM software and outbound tunnels, and segment the virtualisation and NAS management networks. In at least one case only about 24 hours separated tunnel setup from encryption, so the investigation window is narrow.

  • What should we do in the first hour after discovery?

    Four things. First, isolate: cut production network and storage paths, disable VPN accounts and block cloudflared outbound tunnels - but do not power off or reboot. Second, preserve the scene: image or snapshot the domain controller, backup server, virtualisation management hosts and NAS first, and export Citrix/VPN gateway, firewall and Active Directory logs. Third, keep three to five .anubis files and the original RESTORE FILES.html. Fourth, immediately inventory the count and spread of zero-byte files and establish whether backups still exist and whether they were touched. We run 24/7 emergency response and can usually return an initial family assessment, an encrypted-versus-wiped ratio and a recovery path within an hour of remote access.