Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

Rhysida Ransomware Decryption & Data Recovery

  • Active
  • High
  • Some versions decryptable

Rhysida is a RaaS operation active since 2023, marked by the .rhysida extension and a CriticalBreachDetected.pdf ransom note. It hits healthcare, education, manufacturing and government, ships an ESXi encryptor, and a subset of early Windows samples can be recovered with a free decryptor.

First seen
2023-05
File extensions
.rhysida
Ransom notes
CriticalBreachDetected.pdf
Affected platforms
Windows / Linux / VMware ESXi

Family profile

File extensions
  • .rhysida
Ransom notes
  • CriticalBreachDetected.pdf
  • CriticalBreachDetected
Contact patterns
  • Tor (.onion) negotiation portal + per-victim code
  • Rhysida Blog leak site on Tor
  • Bitcoin wallet address (inside the note)
  • No mailbox contact
Aliases / versions
Rhysida Ransomware、Vice Society 后继团伙、Rhysida ESXi Locker、Vanilla Tempest / VICE SPIDER(微软、CrowdStrike 对投放 Rhysida 团伙的命名)
First seen
2023-05
Status
Active
Threat level
High
Affected platforms
  • Windows
  • Linux
  • VMware ESXi
Tags
  • Leak-site regular
  • Active
  • Ransomware-as-a-Service
  • Double extortion
  • Targets virtualization
  • Phishing
  • Exploits vulnerabilities
Decryptor
Some versions decryptable

A free public decryptor exists, but its scope is limited. In February 2024 researchers at Kookmin University and the Korea Internet & Security Agency (KISA) disclosed an implementation flaw in Rhysida's key generation: insufficient entropy was fed into the CSPRNG and the seed was derived from system time, making it predictable and the per-file keys reconstructable. KISA and later Avast released automated tools, now listed on No More Ransom. The constraints matter: it only covers a subset of Windows-encryptor samples, does not work against the ESXi encryptor or the PowerShell variant, and later builds may have fixed the flaw. Always identify the exact build from real encrypted samples and the ransom note first, and only ever run a decryptor against copies, never the original disks.

Sources

Latest activity

  1. Rhysida's leak site kept posting through 2026 - one to three victims a month from March to August, ~285 total. On 10 Sep it listed General Santos Doctors Hospital (Philippines), claiming 3.5M files / 2.44TB.

    Sources
  2. Rhysida listed Berlin's city government, claiming 5.79TB / ~1.44M files including HR, finance, IBANs and plaintext credentials; exfiltration ran 7-12 Aug. Berlin confirmed the theft on 31 Aug and refused to pay.

    Sources
  3. Microsoft: Vanilla Tempest (Vice Society lineage) used malvertising and SEO-poisoned fake Teams sites to drop MSTeamsSetup.exe, installing the Oyster backdoor before Rhysida. Microsoft revoked 200+ signing certificates.

    Sources

Overview

Rhysida was publicly identified in May 2023, with activity traced back to early that year. It runs as ransomware-as-a-service: a core team supplies the encryptor, negotiation portal and leak site, while affiliates handle intrusion and deployment for a share of the ransom. CISA, the FBI and MS-ISAC published joint advisory AA23-319A in November 2023 and refreshed its indicators in April 2025, a sign the crew keeps rotating infrastructure.

Victimology marks Rhysida as an opportunistic actor that picks weaknesses rather than verticals. Education, healthcare, manufacturing, IT and government dominate its leak site; roughly half of the named organisations are US-based, with Europe growing year on year. Posting continued at a steady pace through 2025 and into 2026, so the group should be treated as currently active rather than historical.

Researchers broadly accept a lineage between Rhysida and the now-quiet Vice Society, with Sophos documenting near-identical tradecraft across both brands. IBM X-Force goes further and describes overlap between Rhysida and Interlock in the Supper backdoor, crypters and the traffic distribution systems used for delivery.

For Chinese enterprises the lesson is how ordinary the entry points are: VPN accounts without MFA, internet-exposed edge appliances and directly reachable hypervisor management interfaces. No public report confirms a targeted Rhysida campaign against mainland China organisations, but overseas subsidiaries and cross-border branches of Chinese groups sit squarely inside its target space.

How to identify it

Extension and naming. Encrypted files get .rhysida appended to the full original name, so report.xlsx becomes report.xlsx.rhysida. The base filename is not rewritten or randomised, which distinguishes Rhysida from renaming families such as DragonForce or Makop.

Ransom note. A PDF named CriticalBreachDetected.pdf is dropped in affected directories. The English text presents the actors as the "Rhysida cybersecurity team", claims they located and exploited a flaw in the victim network, and supplies a unique victim code plus a Tor portal address. No email address is provided; negotiation happens only through the onion site.

Other indicators.

  • Wallpaper is usually untouched, but some builds print the note to attached printers.
  • Domain environments typically show mass deployment of the encryptor via PsExec or a GPO.
  • Cobalt Strike, SystemBC and PortStarter artefacts often appear on staged hosts before encryption.
  • Appearance on the Rhysida leak site with a sample data pack confirms exfiltration has already happened.

Bottom line. The .rhysida extension together with CriticalBreachDetected.pdf is enough to attribute the family, but whether the free decryptor applies depends on the specific build, so a real sample must be analysed before any claim about recoverability.

Infection vectors

Rhysida's access playbook leans on valid credentials and exposed edge devices - technically unremarkable, operationally effective:

  • VPN accounts without MFA. Both the CISA advisory and Sophos rank this as the primary vector; credentials come from password reuse, infostealer logs and dark-web purchases.
  • Vulnerabilities in perimeter services. Known flaws in VPN gateways, remote access and file transfer appliances are exploited for a foothold.
  • Phishing. Loader delivery followed by a Cobalt Strike beacon.
  • Malvertising and SEO poisoning (since October 2025). Fake Microsoft Teams download sites (teams-install[.]top, teams-download[.]buzz) serve a signed MSTeamsSetup.exe that installs the Oyster/Broomstick backdoor, from which Rhysida is deployed; Microsoft has revoked over 200 of the abused signing certificates. The April 2025 revision of the CISA advisory additionally documents Gootloader as an initial access vector and the use of AZCopy and Storage Explorer to exfiltrate to cloud storage.
  • Lateral movement. Cobalt Strike, PsExec, RDP and stolen domain administrator credentials; the domain controller is frequently taken first so the encryptor can be pushed everywhere at once.
  • Privilege escalation and defence evasion. Credential dumping and ntdsutil for domain hashes, followed by disabling or uninstalling endpoint protection.
  • Exfiltration. Archiving plus cloud sync or transfer utilities before encryption, setting up the double-extortion leverage.

Rhysida operators typically dwell for days or weeks, mapping the backup system and hypervisor estate before detonating during a business trough - a weekend or a public-holiday night. "Nothing boots on Monday morning" is therefore the most common way these incidents are first reported.

Encryption behavior

Algorithms. File content is encrypted with ChaCha20; each per-file symmetric key is wrapped with a 4096-bit RSA public key. Key material is never written in cleartext, so without the operators' private key there is nothing to reverse.

Intermittent encryption. Rhysida encrypts only part of each file to gain speed. For large files this is significant: database files, virtual disks and mail stores may retain substantial untouched regions, which leaves room for structural repair. How much is recoverable depends entirely on the stride used and whether critical headers or page structures were hit, so it has to be measured on the actual files.

Recovery inhibition. Volume shadow copies are deleted, event logs cleared, database and backup agent services stopped, and directly reachable backup storage is attacked where possible.

Virtualisation. A Linux/ESXi encryptor encrypts vmdk, vmx and related files under /vmfs/volumes. One compromised host equals every VM on it going down, which is why ESXi cluster incidents produce such outsized losses.

Double extortion. Data is stolen before encryption; non-payment leads to staged publication on the leak site and direct pressure on the victim's customers and regulators.

Assess before you act

Recoverability assessment

Whether Rhysida-encrypted data can be recovered has to be judged sample by sample. We do not pay ransoms and do not negotiate on a client's behalf; our work is technical recovery and forensics.

1) Free decryptor (partially viable). The KISA and Avast tools built on the key-generation flaw work against a subset of Windows samples. Preconditions: the build falls inside the flawed range, the encryption window can be estimated, and files have not been re-encrypted. We identify the build from three to five encrypted files plus the note, validate on offline copies, and only then run at scale. The ESXi encryptor and the PowerShell variant are out of scope.

2) Repair space created by intermittent encryption (depends on the encryption pattern). Because only parts of each file are overwritten, database files (MDF/LDF, DBF, ibd), virtual disks (vmdk/vhdx) and mail stores often retain large intact regions. Page-level extraction and logical rebuilds are worth attempting for SQL Server, Oracle and MySQL; for virtual disks, repairing partition and filesystem structures can allow inner files to be extracted. Yields range from poor to high depending on whether critical structures were hit, so assessment precedes any commitment.

3) Backups, snapshots and shadow copies. Shadow copies are usually gone, but still worth checking - offline and offsite backups, storage-layer snapshots on NAS/SAN/gateways, hypervisor snapshots, untouched copies on the backup server, and cloud version history frequently deliver the highest recovery ratio. Never reattach backup media to a network that may still contain a foothold.

4) Unencrypted copies and log replay. File-server recycle bins, endpoint caches, BI and reporting staging databases, ERP archive exports, database transaction logs and application audit logs can all support reconstruction or point-in-time replay of critical records.

5) Low-level carving. Some builds write a new encrypted file and delete the original, leaving source data in unallocated clusters that raw sector scanning can recover. This requires stopping all writes to the affected volumes immediately.

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 Rhysida ransomware? What to do

  1. Containment and forensic preservation

    Isolate affected hosts and ESXi servers from production networks and storage paths while preserving memory and disk state. Do not reboot or power off - Cobalt Strike or SystemBC implants are commonly still resident. Image or snapshot the domain controller, backup server and hypervisor management hosts first, export logs from security appliances, the VPN gateway and Active Directory, and keep three to five encrypted files plus the original CriticalBreachDetected.pdf for analysis.

  2. Family identification and encryption analysis

    Confirm Rhysida from the extension, note structure, file trailer markers and sample characteristics, then distinguish the Windows encryptor, the ESXi encryptor and the PowerShell variant. Reverse the key-generation routine to check whether it falls inside the known flawed range, and measure the intermittent-encryption stride and which regions were overwritten. This step decides whether the path forward is decryption or structural repair.

  3. Recoverability assessment and plan sign-off

    Trial the public decryptor against real samples in an isolated environment while inventorying backups, storage snapshots, hypervisor snapshots and unencrypted copies, and run sample repairs on the critical databases and VMs. Deliver a written assessment stating which systems go the decryption route, which need page-level database rebuilds, and which rely on backup rollback or carving, with expected recovery ranges, timelines and a business restoration order - then execute only after sign-off.

  4. Recovery execution

    All work happens on images or copies with the originals kept read-only. Restore in business priority order: domain controllers and identity first, then core databases such as ERP and MES, then file and mail systems. In ESXi cases, repair virtual disk structures and mount them to extract inner data rather than overwriting the original datastores. 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 VPN account lacked MFA, whether an unpatched edge appliance was exploited, where domain administrator credentials leaked, and the timing and volume of exfiltration (which drives regulatory reporting). Remove Cobalt Strike and SystemBC persistence along with rogue accounts, scheduled tasks and GPO backdoors; reset credentials domain-wide and enforce MFA on VPN; segment the ESXi management network and disable SSH; 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 reboot or power off affected hosts and ESXi servers - losing memory-resident key material, processes and connections destroys both forensic evidence and any partial decryption chance.
  • Do not repeatedly run downloaded "Rhysida decryptors" against original disks; a mismatched build can damage files further, so trials belong on copies only.
  • Do not delete CriticalBreachDetected.pdf or the encrypted samples, and do not rush to clean up "virus files" - they are the only basis for build identification and a decryption feasibility call.
  • Do not format, reinstall or rebuild RAID sets and storage pools, and never re-initialise an ESXi datastore; doing so permanently removes the option of low-level carving.
  • Do not reconnect backup tapes, external drives or the backup server to a network that has not been cleaned - Rhysida actively hunts and destroys reachable backups.
  • Do not contact the onion portal or pay the ransom on your own; payment neither guarantees a working key nor prevents publication of stolen data.

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

Rhysida Frequently asked questions

  • Can Rhysida-encrypted files really be decrypted for free?

    Sometimes. The key-generation flaw disclosed in February 2024 allowed KISA and Avast to publish free decryptors, but they only cover a subset of Windows-encryptor samples, do not work on the ESXi encryptor or PowerShell variant, and later builds may have fixed the flaw. The determining factor is the encryptor build, not the extension, so real encrypted files and the ransom note must be analysed. We validate on isolated copies before any bulk run.

  • If the decryptor does not apply, are there other ways to recover .rhysida files?

    Yes, and they are often more realistic than decryption. In order of assessment: offline and offsite backups plus storage-layer snapshots; hypervisor snapshots; untouched copies on the backup server; and because Rhysida encrypts intermittently, large database files and virtual disks frequently retain substantial intact regions that page-level extraction and structural repair can exploit - the achievable ratio depends on the encryption pattern. Transaction and application logs support point-in-time replay, and unallocated space can be carved. All of this requires stopping writes to the original volumes immediately.

  • Our ESXi virtual machines were encrypted by Rhysida - is anything recoverable?

    The ESXi encryptor is not covered by the free decryptors, but that does not mean nothing can be done. First confirm whether datastore snapshots survive, whether the storage array or NAS holds volume snapshots, and whether the backup platform has usable VM-level backups. If none exist, move to structural repair of the vmdk files: because encryption is intermittent, the guest filesystem and data regions often retain large untouched areas, so partition and metadata repair can allow the disk to be mounted and inner files extracted. Critically, do not re-initialise the datastore and do not create new VMs on the original LUN.

  • Will Rhysida publish our data, and should we pay to stop it?

    Rhysida runs double extortion: data is exfiltrated before encryption and published in stages if no payment is made. Paying does not remove the risk - the operators still hold a copy, which may be resold or recycled by other crews (Babuk2 demonstrably re-extorted using old breach data). We do not pay ransoms or negotiate. The higher-value action is to establish the scope and timeline of the exfiltration quickly, drive internal notification and regulatory or contractual obligations from that, and rotate and notify around the affected accounts, keys and customer records.

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

    Four things. First, isolate: pull production network links, break storage paths, disable the VPN accounts - but do not power off or reboot. Second, preserve the scene: image or snapshot the domain controller, backup server and ESXi management hosts first, and export VPN, firewall and Active Directory logs. Third, keep three to five encrypted files and the original ransom note. Fourth, establish whether backups still exist and whether they were touched. We run 24/7 emergency response and can usually return an initial family assessment and recovery path within an hour of remote access.