Rhysida Ransomware: Attack Chain, IOCs, and Recovery Options

Rhysida ransomware is a double extortion operation first observed in May 2023. The group encrypts Windows and VMware ESXi systems and auctions stolen data on its Tor leak site. It has been linked to the threat cluster that previously deployed Vice Society ransomware. A free public decryptor works against early Windows builds but not every variant, so identifying the build is one of the first recovery steps.

This article is a standalone reference for incident response teams, MSPs, and security decision-makers. If you suspect Rhysida activity in your environment, engage an incident response team before wiping or rebuilding affected hosts, because the evidence on them is what scopes the data theft.

Rhysida ransomware at a glance

What is Rhysida ransomware?

Rhysida is a financially motivated ransomware operation, first seen in 2023, when researchers spotted its Tor-based victim portal. The name comes from a genus of centipedes, and the Rhysida ransomware group uses a centipede as its logo.

The operation is tied to the threat cluster that ran the Vice Society extortion scheme from 2021 and is tracked as Vanilla Tempest, among other names. Before Rhysida, the cluster mostly deployed ransomware built by others, including Zeppelin, Quantum Locker, HelloKitty, and BlackCat. Even after adopting Rhysida, it used INC ransomware against healthcare targets in 2024.

The Vice Society link rests mainly on shared tradecraft and timing. A Rhysida intrusion analyzed in 2023 showed the Active Directory database copied with ntdsutil into a folder named temp_l0gs, a firewall rule disguised as "Windows Update," and a domain-wide password change before encryption, all familiar from Vice Society cases. Vice Society stopped posting victims in mid-2023, shortly after Rhysida appeared.

Rhysida's connection to Vice Society is assessed with moderate-to-high confidence, but it does not prove a rebrand. Germany's federal cybersecurity agency, BSI, reports that the cluster has used Rhysida almost exclusively since June 2023.

Is Rhysida a RaaS operation?

Public reporting is split on whether Rhysida is ransomware-as-a-service or a private operation. A joint CISA advisory cites reports that Rhysida operates as RaaS, but other assessments suggest the cluster runs it privately, and no public affiliate recruitment has been observed.

At least one other cluster, UNC5227, has been linked to deployments of Rhysida, LockBit, BlackCat, and RansomHub. For responders, Vanilla Tempest's tradecraft is a useful baseline, but a different entry route or toolset does not rule Rhysida out.

Who Rhysida targets

Most Rhysida victims are targets of opportunity, though education and healthcare stand out. Other victims include manufacturing, information technology, and government organizations. The incidents below are examples, not a cross-section by sector. Victims confirmed each incident through breach notices, regulatory filings, or public statements.

In May 2026, Rhysida listed Stuttgart as a victim, but the city later said its systems and data were never accessed.

Disclaimer: Victim listings on ransomware leak sites represent unverified claims made by the threat actor. Treat them as unconfirmed unless corroborated by company disclosures, SEC filings, regulatory notifications, or law enforcement confirmation.

Rhysida attack lifecycle

Rhysida intrusions are hands-on-keyboard operations that move from access to domain takeover, data theft, and encryption. The entry routes have broadened since 2023, while much of what follows entry has stayed recognizable.

Phase 1: Initial access

The longest-standing entry route is compromised VPN accounts, often without MFA enabled by default. Reported routes by period:

The fake-installer route relies mainly on malvertising: search ads that lead to lookalike download pages for Microsoft Teams, PuTTY, or Zoom. In waves reported in mid-2024 and from June 2025, the installer deployed Oyster, also tracked as Broomstick and CleanUpLoader, a backdoor that establishes persistent access and can load additional payloads.

The installers carry valid digital signatures from fraudulently obtained certificates, which helps them pass security checks. Some were signed through Fox Tempest, a malware-signing service the cluster used before the service was taken down in May 2026.

TerminalFix is a variant of the ClickFix technique: a fake CAPTCHA check tells the user to paste a command into Windows Terminal or PowerShell instead of the Run dialog. BSI attributes a loader from this campaign to Rhysida's operators.

Phase 2: Persistence and command and control

Operators secure multiple ways back in. Entry backdoors persist on their own: Oyster registers a scheduled task that runs its DLL through rundll32, and the TerminalFix chain adds a Run key, an hourly task, and hidden folders. Besides these, operators have used AnyDesk.

For command and control, SystemBC proxy malware became the main tool after the 2023 move to Rhysida, with Cobalt Strike appearing occasionally. Later campaigns have also used Oyster for this, and the TerminalFix chain adds a Python-based reverse tunnel.

Phase 3: Discovery and credential access

Discovery relies on built-in Windows tools, also known as living-off-the-land binaries (LOLBins), which blend in with routine administration:

• ipconfig, whoami, and systeminfo
• nltest
• net user [username] /domain
• net group "domain admins" /domain
• net group "domain computers" /domain
• net localgroup administrators

Advanced Port Scanner and Advanced IP Scanner map the network, while PowerView maps the domain and its accounts. Discovery targets Active Directory, servers, and backup systems, with the domain controller as the main prize. Operators copy the Active Directory database (NTDS.dit) with ntdsutil or extract credentials with secretsdump, gaining password hashes for every domain account at once.

Phase 4: Lateral movement

PsExec and RDP handle most lateral movement and remote execution. To reach VMware ESXi hosts and NAS devices, operators have used SSH, including through PuTTY. In one analyzed intrusion, eight days passed between the first signs of lateral movement and widespread encryption.

Phase 5: Data exfiltration

In recent intrusions, operators have used AzCopy and Azure Storage Explorer, Microsoft utilities for moving files into Azure storage, to copy stolen data to storage accounts they control. The transfer can blend into routine cloud activity.

Phase 6: Defense evasion and encryption

Just before encryption, a cleanup script such as g.ps1, detected as SILENTKILL, kills antivirus processes and services, deletes shadow copies, modifies RDP settings, and changes an Active Directory account password. Operators also clear event logs with wevtutil, and depending on the build, the encryptor can delete shadow copies and clear the logs itself.

Deployment is scripted. One investigation found operators keeping a list of target hosts in C:\in and their tools in C:\out, then using batch files to place a PowerShell script on each host, copy the encryptor to C:\Windows\Temp as conhost.exe, and run it.

The Windows encryptor skips system folders and executable or system file types, appends the .rhysida extension, and drops CriticalBreachDetected.pdf as the ransom note. It accepts these command-line options:

• -d sets the target directory.
• -sr makes the encryptor delete itself after encryption through a hidden PowerShell window.
• -S In some Windows builds, it skips immediate encryption and creates a scheduled task named Rhsd that runs the encryptor at startup.

In one case, operators force-stopped virtual machines with esxcli, then ran the Linux encryptor against /vmfs/volumes, a pattern common to ESXi ransomware.

Extortion model and leak site

The operation uses a double extortion ransomware model: it steals data before encryption, leaving the victim with both locked systems and the threat of publication. The ransom note poses as an automated alert from a "cybersecurity team," announces a network compromise, and provides a unique code to contact the operators through a Tor portal. Payment is demanded in Bitcoin.

Rhysida's leak site works as an auction house. When a victim does not pay, the group offers the stolen data to the highest bidder, listing it with an opening bid in bitcoin and a countdown (usually seven days). According to a commercial provider cited by Germany's BSI, 92% of Rhysida leak-site listings are followed by publication of the stolen data, on average 11 days after the listing.

Indicators of compromise

Most indicators below come from the joint FBI, CISA, and MS-ISAC advisory, last updated in April 2025, based on investigations through December 2024. They work best for hunting back through logs, not as a live blocklist. A hash match confirms a known sample, but any file change produces a new hash, so a miss does not rule out compromise. The behaviors in the detection section below age more slowly.

File hashes (SHA256)

The advisory also lists SHA1 hashes and the legitimate tools the operators used.

Network and email indicators

The parent domain of the first entry belongs to an unrelated real estate site, so hunt for the subdomain, not the whole domain. Fresher indicators for the 2026 TerminalFix wave, including file hashes, domains, and hunting queries, are in Microsoft's analysis; they mark that campaign, not necessarily a Rhysida deployment.

Host artifacts

• Encrypted files with the .rhysida extension and a CriticalBreachDetected.pdf ransom note
• A scheduled task named Rhsd, created by some builds launched with -S
• C:\Windows\Temp\conhost.exe, where the encryptor was placed in one investigation; the file can delete itself after running, so its absence does not clear a host
• Staging folders C:\in and C:\out, including C:\out\PSTools.zip, from the same investigation

MITRE ATT&CK mapping

The table maps Rhysida behavior to ATT&CK v19 techniques and tactics, so some rows differ from the CISA advisory, which uses v17. Observed means the behavior is documented in Rhysida intrusions. Probable means the behavior is documented, but its link to Rhysida is inferred.

Detection and threat hunting

Like most human-operated ransomware, Rhysida relies on legitimate tools, so ransomware detection works best on sequences of events, not single alerts. The signals below run from entry to encryption; the earlier a signal fires, the more time you have to respond.

• Unusual VPN logins. A VPN session on an account without MFA from an unfamiliar location or device, followed by RDP or discovery commands from the VPN address range.
• A pasted command that fetches files. In the TerminalFix chain, PowerShell drops files into C:\ProgramData; LockScreenContentServer.exe, a legitimate Windows file, runs from there instead of its usual system folder; and pythonw.exe later holds an outbound WebSocket connection on port 443. Commands sent through this tunnel may not be logged.
• A new installer, then a rundll32 task. A Teams, PuTTY, or Zoom installer fetched from an ad, followed by a scheduled task that repeatedly runs rundll32 with a DLL from AppData, fits Oyster. Task and file names change between waves.
• A discovery burst from one account. nltest queries for domain controllers and trusts, net group "domain admins" /domain, and systeminfo in quick succession.
• ntdsutil on a domain controller. A copy of NTDS.dit made outside planned maintenance.
• SSH into hypervisors and NAS devices. SSH sessions, including through PuTTY, from Windows servers to ESXi hosts or NAS devices.
• Uploads to unfamiliar Azure storage. AzCopy or Azure Storage Explorer sending data to a storage account your organization does not own.
• PsExec fan-out. PSEXESVC appearing on many hosts at once, then executables with system names such as conhost.exe or svchost.exe running from C:\Windows\Temp.
• The final cleanup. Windows event logs cleared with wevtutil, shadow copies deleted, security services stopped, and passwords reset across the domain. By this stage, encryption is starting or imminent.

What to do if Rhysida is active in your environment

"Pull network cables, not power cords. Isolate DCs and backup repos first. Then call IR counsel and a response firm on an out-of-band channel. Assume all day-to-day channels like email and Teams are compromised."

Magdy Abdelaziz, Head of DFIR, Proven Data

Once you isolate ransomware-infected servers, suspend or kill any encryptor process still running, since isolation does not stop local encryption. Power down a host only if you cannot cut it off from the network. The next steps follow from how Rhysida intrusions unfold:

1. Secure evidence first. Capture memory and disk images from a sample of affected hosts and copy logs off them early to preserve ransomware evidence. Operators and some encryptor builds clear Windows event logs, and operators have also deleted PowerShell history, so central copies in a SIEM may be the only intact record. Do not wipe or reimage encrypted hosts yet: the No More Ransom decryptor for early builds runs only on the machine where the files were encrypted.
2. Copy the AzCopy records. By default, AzCopy writes log and plan files to the %USERPROFILE%\.azcopy folder of the account that ran it, and Azure Storage Explorer transfers leave files in the same place. The plan files list what each job was set to copy, which helps scope the theft. The encryptor covers user profiles, so it can encrypt the AzCopy files too.
3. Report the incident. File a report with the FBI's IC3 or CISA in the US, or with your national cybersecurity authority elsewhere, whether or not you pay the ransom.
4. Find and close the entry point. Review VPN logins for accounts without MFA; check for Teams, PuTTY, or Zoom installers downloaded from search ads; and review PowerShell logs and console history for pasted commands.
5. Hunt for every way back in before reconnecting. Check for AnyDesk and other remote access tools, SystemBC proxy malware, any backdoor from the entry route, and scheduled tasks or Run keys that launch rundll32, unfamiliar executables, or Windows files outside their usual folders. Before rebooting a host, also check for a scheduled task named Rhsd: some builds use it to launch the encryptor at the next startup.
6. Reset credentials if NTDS.dit was compromised. Treat it as compromised if it was copied or dumped, or if operators held domain admin rights and the logs cannot rule it out. Reset passwords domain-wide and reset the krbtgt account twice: let the first reset replicate to all writable domain controllers, and wait longer than the maximum ticket lifetime (10 hours by default) before the second. The copied database also holds the KDS root key behind gMSA passwords, so plan gMSA recovery with Microsoft's Golden gMSA guidance.

Can files encrypted by Rhysida be recovered?

Sometimes. A free decryptor can recover files encrypted by early Windows builds of Rhysida, but not by newer builds first seen in June 2024 or by the Linux/ESXi and PowerShell variants, so identifying the build comes first. Decryption does not undo the data theft, though: the operators keep their copy either way.

The Windows encryptor encrypts file contents with AES-256 in CTR mode and protects each file's key with RSA-4096, storing it at the end of the file. Files over 1 MiB are generally only partly encrypted, in up to four 1 MiB blocks. Some reports, including the CISA advisory, name ChaCha20 as the file cipher, but in analyzed samples ChaCha20 only generates the keys.

That key generator was the weak point: early builds seeded it with the encryptor's start time, so defenders could brute-force the seed and rebuild each file's key. KISA (South Korea's internet security agency) and university researchers released a recovery tool in December 2023, and a free decryptor is also available on No More Ransom. Newer builds seed the generator from process data instead, and the public tools no longer work on them. Even on early Windows builds, full decryption is not guaranteed: less common or proprietary file formats may not be supported.

Before attempting decryption:

• Back up the encrypted data. A failed attempt to decrypt ransomware files can damage them.
• Keep encrypted hosts intact. The No More Ransom decryptor works only on the same machine where the files were encrypted, with no files copied in from other hosts. Drive letters and the number of CPU cores must also stay the same.
• Run the decryptor's testing mode first. Without changing any files, it checks whether decryption will work. A failed test does not prove a newer build: files encrypted with a 32-bit encryptor need the decryptor's 32-bit mode, so test that mode too. A surviving copy of the encryptor can also be analyzed to identify the build.

Without a working decryptor, recovery depends mainly on backups the operators could not reach. The pre-encryption cleanup script and early builds delete shadow copies, and operators have targeted backup systems directly, so check that backups are intact and predate the intrusion before restoring from them. Because large Windows files are encrypted only in blocks, professional Rhysida ransomware recovery can sometimes salvage much of a large database. Paying the ransom does not guarantee recovery.

DO NOT PAY THE RANSOM. Decisions about ransom payment carry legal, operational, and financial consequences, including potential OFAC sanctions exposure, and should be assessed with qualified legal counsel and an incident response team before any decision to engage with or pay the threat actor. That assessment must not delay containment, evidence preservation, required reporting, or recovery.

Security checklist

Each control below targets a route or technique described in this article.

• Phishing-resistant MFA on VPN and remote access. Stolen VPN credentials on accounts without MFA remain the longest-standing entry route.
• Application allowlisting. Allow only approved software, so a signed installer from a search ad cannot run.
• Restricted PowerShell. Limit PowerShell for standard users and enforce Constrained Language Mode through App Control for Business to blunt TerminalFix lures.
• Staff awareness. No real verification page asks users to paste a command, and business software should come from internal sources, not search ads. SmartScreen and ad blocking add a second layer.
• PowerShell logs kept off the host. Enable module, script block, and transcription logging; keep logs for at least 180 days; and forward them to a hardened central server, since operators wipe local copies.
• Control of remote access tools. Keep a list of approved tools. Block the rest (including portable versions) on endpoints and by domain and port at the perimeter, since AnyDesk can also use port 443.
• Fewer domain admins. Use separate admin accounts with time-limited access and remove inactive accounts, so fewer accounts can copy NTDS.dit.
• Segmentation. Allow internal SMB only where needed, block SMB and RDP between workstations, and allow RDP only for known groups. That keeps PsExec and RDP from reaching every host.
• Hardened ESXi. Keep management interfaces on an isolated network, disable SSH unless needed, and enable lockdown mode and execInstalledOnly, which prevents binaries not installed as packages from running.
• Offline, immutable ransomware backups. Keep them encrypted, in a separate segment, and behind separate credentials, since operators target backup systems directly. Test restores regularly.