Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

Medusa Ransomware Decryption & Data Recovery

  • Active
  • Critical
  • No public decryptor

Medusa appeared in June 2021 and shifted to a ransomware-as-a-service model from 2023, using the .MEDUSA extension and !!!READ_ME_MEDUSA!!!.txt note. It specialises in exploiting remote-management and file-transfer components such as ScreenConnect, Fortinet EMS and GoAnywhere, and applies pressure through a countdown clock with paid extensions.

First seen
2021-06
File extensions
.MEDUSA .medusa
Ransom notes
!!!READ_ME_MEDUSA!!!.txt
Affected platforms
Windows / Linux / VMware ESXi

Family profile

File extensions
  • .MEDUSA
  • .medusa
Ransom notes
  • !!!READ_ME_MEDUSA!!!.txt
Contact patterns
  • Tor live chat (contact within 48 hours)
  • Tox messaging ID
  • Medusa Blog (.onion leak site, countdown and paid deadline extensions)
Aliases / versions
Medusa Ransomware、Spearwing、MedusaBlog
First seen
2021-06
Status
Active
Threat level
Critical
Affected platforms
  • Windows
  • Linux
  • VMware ESXi
Tags
  • Leak-site regular
  • Active
  • Ransomware-as-a-Service
  • Double extortion
  • Targets virtualization
  • Exploits vulnerabilities
  • Phishing
Decryptor
No public decryptor

No public, free Medusa decryptor exists.

Medusa encrypts file content with AES-256 using RSA for key exchange; the private key stays with the operators and no exploitable weakness has been found on the ciphertext side. NoMoreRansom and similar platforms list no Medusa decryptor.

One common misconception needs clearing up: Medusa and MedusaLocker are different families. The FBI states explicitly in the joint advisory that the Medusa variant is unrelated to MedusaLocker and to the Medusa mobile malware. "MedusaLocker decryptors" circulating online do not apply to Medusa, and using one wastes time and can damage the scene.

Recovery must come through technical routes: backups and snapshots, intact blocks left by partial encryption, unencrypted copies and logs.

Latest activity

  1. CISA, FBI and HHS updated advisory AA25-071A: as of April 2026 Medusa had impacted over 500 critical-infrastructure victims, up from 300, across healthcare, defence, manufacturing, government, IT and finance.

    Sources
  2. Microsoft reports Storm-1175, previously a Medusa deployer, has switched to a new locker, StormEncryptor: .encrypted files, !!!README_FIRST!!!.txt, a three-day deadline, entering via N-central flaw CVE-2026-18577.

    Sources
  3. Microsoft tied Medusa affiliate Storm-1175 to zero-day attacks: SmarterMail auth bypass (CVE-2026-23760) and GoAnywhere (CVE-2025-10035). Initial access to exfiltration and encryption takes days, sometimes 24 hours.

    Sources

Overview

Medusa was first identified in June 2021, initially run end-to-end by a single crew. Around 2023 it moved to a RaaS model, bringing in affiliates and initial access brokers, and volume grew accordingly. Symantec tracks the operators as Spearwing. CISA, the FBI and MS-ISAC published the #StopRansomware advisory AA25-071A in March 2025, with subsequent updates as new vulnerabilities entered its toolkit.

Its most distinctive trait is productised coercion. Medusa runs a .onion leak site called Medusa Blog, posting a public countdown for each victim and listing priced options openly: extend the countdown, delete the data specifically, or buy the data outright. The advisory also records ransom demands posted with direct links to affiliated cryptocurrency wallets. Beyond encryption and leak pressure, public reporting has documented triple-extortion cases in which a victim that had already paid was approached again by someone claiming to be a Medusa member, alleging the negotiator had pocketed the funds. The negative lesson is unambiguous: payment guarantees nothing.

By sector, Medusa spans healthcare, education, manufacturing, government, information technology, legal and insurance, with healthcare and public health specifically named as frequent victims. Targets range from small firms to large institutions running full virtualisation stacks.

For organisations in the region, the instructive part is its choice of entry points: Medusa repeatedly exploits remote-management and file-transfer components — ScreenConnect, Fortinet EMS, Fortra GoAnywhere, BeyondTrust and similar. These systems are often maintained by outsourced IT or MSPs, patched late, exposed to the internet, and inherently privileged, so a single break reaches the core of the network. Rather than memorising family names, it is far more useful to bring the versions and exposure of such operations-channel systems into routine inspection.

How to identify it

Extension. Encrypted files uniformly gain .MEDUSA (lowercase .medusa in some builds). It is the most direct marker, but must be distinguished from MedusaLocker, which commonly uses .encrypted, .dever or .lockfilesKR — different family, different handling and recovery path.

Ransom note. The filename is consistently !!!READ_ME_MEDUSA!!!.txt, instructing victims to make contact within 48 hours via Tor live chat or Tox, with a link to the leak site and an explanation of the countdown. That combination — fixed note name, 48 hours, Tox — is a reliable identifier.

Host-side artefacts.

  • Volume shadow copies deleted via vssadmin.
  • Heavy living-off-the-land use: PowerShell, certutil, bitsadmin, PsExec, WMI and RDP for lateral movement.
  • Persistence through legitimate remote tools (AnyDesk, Atera, Splashtop, ConnectWise and others).
  • EDR disabled via bring-your-own-vulnerable-driver, with published analyses documenting signed drivers named to resemble well-known security vendors' drivers.
  • Windows event logs cleared and firewall rules modified to permit RDP.

Leak-site signature. Victims appear on Medusa Blog with a public countdown and openly priced options to extend, delete or purchase the data. Seeing that pricing structure on a leak site effectively confirms the family.

Virtualisation artefacts. Bulk power-off of guests on ESXi/vCenter, encryption of datastore files, and recursive encryption of network shares.

Infection vectors

Medusa's entry points reduce to two lines: buy the account or break the operations channel.

1. Initial access brokers and phishing. The advisory records Medusa purchasing ready-made access from IABs alongside credential-stealing phishing. Many victims therefore had credentials circulating on underground markets long before encryption.

2. Remote-management and file-transfer component flaws — Medusa's signature vector:

  • CVE-2024-1709: ConnectWise ScreenConnect authentication bypass;
  • CVE-2023-48788: Fortinet FortiClient EMS SQL injection;
  • CVE-2025-10035: Fortra GoAnywhere MFT deserialisation flaw;
  • CVE-2026-1731: BeyondTrust remote code execution;
  • CVE-2026-23760: SmarterTools SmarterMail authentication bypass, exploited as a zero-day — Microsoft attributed it to Medusa affiliate Storm-1175 in April 2026.

Timing matters too: Storm-1175 was exploiting GoAnywhere CVE-2025-10035 more than a week before the patch existed, so waiting for a vendor advisory and then scheduling the fix does not close this class of entry point.

These systems share a profile: permanently internet-facing, inherently privileged across hosts, and treated internally as operations infrastructure rather than business systems, so patching is deprioritised. Medusa bets on that repeatedly.

3. Weak credentials and RDP/VPN without MFA, combined with accounts stolen from browsers and credential stores for lateral movement.

Inside the network: rely on LOLBins (PowerShell, certutil, bitsadmin, WMI) to minimise custom tooling on disk; establish redundant channels through legitimate remote software; disable EDR via BYOVD; enumerate and destroy backups and delete shadow copies; exfiltrate; then deploy the encryptor in bulk outside business hours via PsExec, scheduled tasks or Group Policy, covering ESXi and network shares.

Because so much of this uses built-in tooling, Medusa's pre-encryption activity often reads as routine administration in conventional alerting — which is why it is frequently discovered only when files start changing.

Encryption behavior

Algorithms. AES-256 for file content with RSA for key exchange and wrapping. Key material is recoverable only by the operators, and no exploitable weakness exists on the ciphertext side.

Scope of encryption. Local disks, mapped network drives, reachable SMB/NFS shares and NAS directories, and virtual-machine files on ESXi datastores. Large files are typically partially encrypted for speed, and the coverage strategy and ratio vary by build and parameters and must be measured per case — which is exactly what determines how much usable original data remains inside VMDKs and database files.

Destruction and anti-forensics.

  • Deletes volume shadow copies with vssadmin, cutting the easiest local rollback.
  • Stops and disables database, mail, backup-agent and security services.
  • Loads vulnerable signed drivers via BYOVD to disable EDR.
  • Clears Windows event logs and modifies firewall rules to permit RDP.
  • Leans on built-in tooling (LOLBins) to minimise detectable artefacts on disk.

Extortion model.

  • The note demands contact within 48 hours; after that the victim is published on Medusa Blog with a countdown.
  • The countdown can be extended for a fee priced per day, alongside listed options to have the data deleted specifically or purchased outright.
  • Triple extortion is publicly documented: victims who had already paid were approached again by someone claiming to be an accomplice.

In Medusa cases, therefore, payment not only fails to guarantee decryption or deletion — it can invite a second demand. That needs saying plainly to decision-makers when the response strategy is set.

Assess before you act

Recoverability assessment

There is no public decryptor for Medusa, and its extortion model makes payment especially unreliable — victims who paid have publicly been approached for more. Medusa recovery is therefore purely technical, tested in this order.

1. Backups, snapshots and shadow copies. vssadmin removes local shadow copies, but several layers usually remain in play: offline and off-site backups, tape, immutable or object-locked cloud backups, snapshots on storage arrays and NAS controllers, and overlooked copies on the backup server. The key is validating each copy's restorability — Medusa enumerates before destroying, so what survives may be incomplete. Suspend automatic snapshot reclamation as soon as encryption is discovered.

2. Intact blocks left by partial encryption. For large files (vmdk, mdf/ndf, dbf, ibd, pst, archives), map the encryption layout first to establish strategy and ratio, then:

  • rebuild partition tables and filesystems from intact VMDK ranges and export guest databases and business files;
  • repair SQL Server, Oracle and MySQL data files at page and extent level, merging unencrypted transaction and archive logs to reach consistency;
  • extract usable objects from PST files, archives and imaging data by walking format structures.

It depends on the mode. Coverage varies considerably across Medusa builds and parameters, and whether critical metadata was overwritten decides the outcome. Measure first, assess second; no percentage is promised.

3. Unencrypted copies and log replay. Dev/test databases, read-only reporting instances, downstream warehouses, ERP/OA/HIS staging tables and interface files, endpoint-local copies, mail attachments and scan archives often supply core data; transaction and interface logs can rebuild documents. Healthcare cases should also check independent PACS/LIS storage and in-house imaging archives.

4. Low-level carving. Depending on write behaviour, deleted originals and purged backup directories may leave recoverable clusters on the volume.

5. Run the exposure assessment in parallel. Medusa publishes a countdown and prices the data for sale, so where personal information is involved the compliance clock is tight. We deliver exfiltration scoping as a parallel track to recovery, not as an afterthought.

Our limits. No claim of 100% decryption, no guaranteed recovery, no ransom payment, no negotiation on your behalf.

Our response plan

Hit by Medusa ransomware? What to do

  1. Containment, forensics and decision support under the countdown

    Isolate affected hosts, ESXi clusters and NAS devices, and take read-only images of datastores, database files and backup volumes. Preserve !!!READ_ME_MEDUSA!!!.txt, encrypted samples, logs from operations systems such as ScreenConnect, GoAnywhere and FortiClient EMS, RDP and VPN logon records, and driver-load and service-stop records. Do not power off, do not rebuild.

    What is distinctive here is the decision pressure created by the 48-hour countdown. We provide a fact-based response briefing immediately: the leak-site clock does not change what is technically recoverable, and neither paid extensions nor "buying the data" offer any guarantee — victims who paid have publicly been approached again. That helps leadership hold a steady course.

  2. Family identification and encryption analysis

    Confirm the family from the .MEDUSA extension, !!!READ_ME_MEDUSA!!!.txt and the Tox/Tor 48-hour instruction, and explicitly distinguish it from MedusaLocker — the two are unrelated, and a misidentification leads straight to the wrong plan and wasted attempts with inapplicable tools.

    Then run per-block entropy and structure comparison on representative large files (vmdk, mdf/ndf, dbf, ibd, pst) to determine the real coverage strategy and ratio, whether partition tables, database header pages and directory metadata were overwritten, and whether the encryptor wrote in place or created new files and deleted originals — the latter opens the door to carving.

  3. Recoverability assessment and exposure scoping

    Two tracks run in parallel. Recovery: consolidate backup and snapshot availability (validated copy by copy), the reach of partial-encryption repair, what unencrypted copies and logs can backfill, and carving opportunities — then state, per system, the recoverable scope, achievable point in time and what cannot be recovered.

    Exposure: use firewall, proxy, operations-system and host logs to establish the timing, channel and volume of exfiltration, scope the business data and personal information involved, and assess notification obligations and deadlines under China's Cybersecurity Law, Data Security Law and PIPL. Healthcare and education additionally need to account for sector regulators' reporting requirements.

  4. Recovery execution and business validation

    Execute in an isolated clean environment: restore from validated backups or storage snapshots; rebuild VMDK extents and export guest data; repair databases at page level with log merging and consistency checks; restore file shares, NAS directories and archives in priority batches.

    Healthcare clients get HIS, LIS, PACS and their interface data first; education and government clients get core business databases and records systems first. Business owners sample-verify each recovered system against core tables, key documents and recent activity before production cutover, and we deliver a data-gap list alongside.

  5. Attribution, hardening and sign-off

    Reconstruct the intrusion chain against Medusa's typical entry points: versions and exposure of ScreenConnect (CVE-2024-1709), FortiClient EMS (CVE-2023-48788), Fortra GoAnywhere (CVE-2025-10035) and BeyondTrust (CVE-2026-1731), plus MFA coverage on RDP/VPN and any credential leakage.

    Hardening priorities: bring remote-management and file-transfer systems into the same patch and exposure governance tier as business systems, keep them off the public internet behind enforced MFA, and constrain their cross-host privileges; enforce MFA everywhere and remove internet-facing RDP; move backups off-domain onto immutable storage; enable driver-load monitoring against BYOVD; and build detections for anomalous PowerShell, certutil, bitsadmin and PsExec use. We close with a sign-off report and observation-period guidance.

Risk warning

What not to do

  • Do not rush to pay because of the countdown. Medusa openly prices extensions, deletion and data purchase on its leak site, and victims who paid have publicly been approached again by supposed accomplices — payment guarantees neither decryption nor deletion.
  • Do not use MedusaLocker decryptors or playbooks. The FBI states the two are unrelated, and running the wrong tool on original disks can destroy recoverable data.
  • Do not reboot or rebuild encrypted servers and ESXi hosts, and do not run chkdsk / fsck or disk-repair utilities on encrypted volumes — they overwrite the intact blocks partial encryption left behind.
  • Do not resume operations before flaws in ScreenConnect, GoAnywhere, FortiClient EMS and similar operations systems are addressed. They are Medusa's primary entry points and carry inherently high cross-host privileges.
  • Do not clean up residual Windows event logs, driver-load records or remote-tool artefacts. Medusa relies heavily on built-in tooling and BYOVD, making these among the few available pieces of evidence for the intrusion path and exfiltration scope.
  • Do not defer the exposure assessment until recovery is finished. Once the countdown is public, compliance deadlines around personal information are tight, so exfiltration scoping must run in parallel with recovery.

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

Medusa Frequently asked questions

  • Are Medusa and MedusaLocker the same ransomware?

    No. The FBI states explicitly in the #StopRansomware advisory that Medusa is unrelated to MedusaLocker, and also unrelated to the Medusa mobile malware. The names simply resemble each other.

    Telling them apart is straightforward: Medusa uses the .MEDUSA extension and the fixed note !!!READ_ME_MEDUSA!!!.txt, demanding contact within 48 hours via Tor chat or Tox. MedusaLocker commonly uses .encrypted, .dever or .lockfilesKR, with a different note format and contact method.

    The distinction matters because MedusaLocker tooling and advice circulating online does not apply to Medusa at all, and running it on original disks can overwrite recoverable data. We always start from sample and note comparison and settle the family before discussing any plan.

  • Medusa gave us a 48-hour countdown — must we decide within it?

    The countdown is a pressure device, not a technical constraint. It changes neither what is recoverable from your files nor whether backups and snapshots exist.

    It helps to see the business model: extending the countdown, having data deleted, and buying the data are all priced options on the leak site — panic converted into revenue. More importantly, triple extortion is publicly documented: after paying, victims were approached again by someone claiming to be a Medusa member, alleging the negotiator had pocketed the money. In other words, no promise made after payment carries any enforcement.

    The pace we recommend is this: what gets completed within 48 hours is not the pay-or-not decision, but containment, evidence preservation, suspending snapshot reclamation, and starting the recoverability assessment and exposure scoping. Decisions need measured findings behind them. We do not pay ransoms and do not negotiate.

  • Can .MEDUSA files be recovered?

    There is no decryptor, but recovery routes exist and how far they go has to be measured.

    We work through: snapshots on the storage array and NAS controller (vssadmin cannot reach that layer — suspend automatic reclamation first), offline and immutable backups, intact blocks left by partial encryption in large files, and unencrypted copies and logs.

    For ESXi VMDKs and database data files confirmed as partially encrypted, mapping the encryption layout allows filesystem rebuilding from intact ranges and export of guest data, with page-level repair plus log merging for SQL Server, Oracle and MySQL. The recoverable share depends on the encryption mode and whether critical metadata was overwritten, and Medusa builds differ considerably — so we measure first and do not quote percentages in advance.

    One caution: do not trial assorted "decryptors" on original disks and do not run disk-repair utilities. Both destroy recoverable blocks directly.

  • How did Medusa get in, and why didn't our EDR alert?

    Medusa's entry point is usually not the endpoint but the operations channel: remote-management and file-transfer systems such as ConnectWise ScreenConnect (CVE-2024-1709), Fortinet FortiClient EMS (CVE-2023-48788), Fortra GoAnywhere (CVE-2025-10035) and BeyondTrust (CVE-2026-1731), plus accounts bought from initial access brokers. These systems sit on the public internet year-round with inherently high cross-host privileges, yet rarely share the patch cadence of business systems.

    EDR stays quiet for two reasons. Living off the land: Medusa leans on PowerShell, certutil, bitsadmin, WMI, PsExec and legitimate remote software, so the behaviour reads as administration. Active countermeasures: affiliates disable EDR using vulnerable signed drivers (BYOVD) and clear event logs afterwards.

    The hardening follows directly: bring operations systems into the same patch and exposure governance tier as business systems, keep them off the public internet behind enforced MFA, enable driver-load monitoring, and build detections for anomalous LOLBin use.