Medusa encrypts a digital asset platform's operations database

The client is a digital asset service provider running over-the-counter matching and custody operations. Its front-end matching service sits in the cloud; the operations backend — user accounts, order records, KYC review records and reconciliation ledgers — runs on a SQL Server instance on one on-premises Windows server; a separate file server holds KYC images and compliance review material.

Under internal controls, the bulk of assets sits in offline cold wallets with private keys split between hardware devices and paper backups, connected to neither the office network nor the backend.

Operations were outsourced to a small provider that reached internal hosts through one remote management product: never updated since deployment, its console mapped directly to the internet, its accounts without multi-factor authentication.

Early one weekend morning in August, duty staff found the backend unreachable. The database service had stopped; the mdf, ndf and ldf files and the file server's image directories all carried an appended .MEDUSA extension, and every directory held a note named !!!READ_ME_MEDUSA!!!.txt demanding contact within 48 hours via Tor live chat or Tox. The backup agent had been stopped, .bak files on the local backup disk were encrypted too, shadow copies had been purged, and no off-site or offline copy had ever been implemented. No contact was made, and once the 48-hour deadline lapsed the client's entry appeared on Medusa Blog: a public countdown, with screenshots of KYC material posted as a "sample".

Containment went out on the first call: hosts powered but off the network, no writes, no database restart, no "decryptor" trials, snapshot reclamation suspended. Automated withdrawals were paused and allowlist changes frozen; cold wallets stayed offline.

• Evidence and imaging. Read-only images of the backend and file server disks, plus surviving security logs, database error logs and remote management session records; later work ran on copies.
• Family confirmation and recoverability. The .MEDUSA extension, the !!!READ_ME_MEDUSA!!!.txt note and the 48-hour Tor/Tox demand identified Medusa — not the unrelated MedusaLocker — and no public decryptor exists. Surviving backups and snapshots proved unusable on validation; entropy mapping showed the large mdf/ndf files partially encrypted, with intact pages in the middle and tail.
• Recovery. Page-level scanning in an isolated environment rebuilt table structures; usable pages were extracted table by table into a fresh instance and unencrypted log replay filled in records up to the outage, reconciled three ways against on-chain deposit/withdrawal records, internal ledgers and user balances. KYC images came back from unencrypted remnants and a downstream read-only reporting copy.
• Funds check and hardening. Withdrawal approvals and on-chain transfers were reconciled item by item, confirming cold wallets and keys were untouched. The console's public mapping was removed and the product upgraded, credentials reset with MFA enabled, and a local-plus-offline immutable backup built and restore-tested.
• Deliverables. Recoverability assessment, data-gap list, exposure impact report, draft notification guidance, and a remediation checklist.