Ransomware family
RansomHub Ransomware Decryption & Data Recovery
- Inactive
- High
- No public decryptor
RansomHub launched in February 2024 as a rebrand of Knight/Cyclops and rapidly absorbed affiliates from ALPHV and LockBit with a 90% revenue share, accumulating hundreds of victims within a year. Its infrastructure went offline in early April 2025 and the operation has been dormant since, with affiliates largely migrating to Qilin and DragonForce.
- First seen
- 2024-02
- File extensions
- .[6位随机字符]
- Ransom notes
- README_[6位随机字符].txt
- Affected platforms
- Windows / Linux / VMware ESXi / NAS storage
Family profile
- File extensions
- .[6位随机字符]
- Ransom notes
- README_[6位随机字符].txt
- Contact patterns
- Tor client portal (per-victim client ID)
- .onion leak site (3–90 day publication deadline)
- No mailbox address given
- Aliases / versions
- Cyclops、Knight、Water Bakunawa
- First seen
- 2024-02
- Status
- Inactive
- Operational status
- Operation shut down
- Threat level
- High
- Affected platforms
- Windows
- Linux
- VMware ESXi
- NAS storage
- Tags
- Defunct
- Ransomware-as-a-Service
- Double extortion
- Targets virtualization
- Exploits vulnerabilities
- Phishing
No public, free RansomHub decryptor exists.
RansomHub uses Curve25519 elliptic-curve key agreement with AES or ChaCha20 for file content depending on the target platform, and encrypts intermittently for speed. Key material is protected by the operators' private key, there is no publicly exploitable weakness on the ciphertext side, and NoMoreRansom lists no decryptor.
Beyond that, RansomHub's infrastructure went offline in late March to early April 2025 — its leak site was briefly taken over by DragonForce — so the negotiation portal and key service are no longer available, meaning payment may produce no key at all. If you encounter an apparent "RansomHub" event after April 2025, re-run family identification: it is most likely former affiliates operating under another platform such as Qilin or DragonForce.
Recovery must come from backups and snapshots, intact blocks left by intermittent encryption, and unencrypted copies and logs.
Latest activity
Re-checked 11 Sep 2026: RansomLook and Ransomware.live show every RansomHub .onion mirror still fully offline, with the last victim post dated 1 April 2025 (~842 victims, 73 countries). No portal and no key service remain — recovery is technical only.
SourcesGroup-IB's 2026 ransomware report revisits RansomHub's collapse: DragonForce claimed the takeover, RansomHub publicly alleged sabotage and law-enforcement cooperation, and affiliates scattered to Qilin and DragonForce. RansomHub is absent from 2026's eight leading groups.
SourcesRansomHub's EDRKillShifter has evolved into a shared EDR killer now used by eight gangs including Qilin, DragonForce, Medusa, BlackSuit, INC and Lynx. The brand is gone, but its main weapon still disables Defender and SentinelOne today.
Sources
Overview
RansomHub launched in February 2024; the CISA advisory identifies Cyclops and Knight as its predecessors (Trend Micro tracks the operators as Water Bakunawa). Its timing was telling: LockBit had just been disrupted by international law enforcement and ALPHV/BlackCat was preparing its exit scam, leaving many experienced affiliates in need of a platform. RansomHub absorbed them quickly with unusually affiliate-favourable economics — widely reported at a 90% share — and a model where affiliates collect first and remit afterwards. Among them was the affiliate behind the February 2024 Change Healthcare breach whose ransom ALPHV had pocketed; he brought a copy of the data to RansomHub and re-extorted the same victim.
Growth was rapid. By the time CISA published advisory AA24-242A in August 2024, at least 210 victim organisations had been recorded across healthcare, government, water systems, financial services and critical manufacturing; cumulative leak-site claims exceeded 800. Through the second half of 2024, RansomHub was among the most prolific groups worldwide by published victims.
The ending was just as fast. Around 31 March 2025 its negotiation portal and leak site began going offline, with full disruption by 1 April. DragonForce promptly claimed on the RAMP forum that RansomHub had "joined our cartel" and took over or defaced its site. Group-IB and others observed a large affiliate migration into Qilin — one of the direct reasons Qilin's volume doubled from Q2 2025 and it went on to lead global rankings. RansomHub has not resumed operations and should be treated as dormant.
Two practical implications. First, where data encrypted by RansomHub remains unresolved, there is no counterparty left to pay for keys — only technical recovery. Second, and more important: the people who attacked you are still operating. RansomHub affiliates carried the same playbook to Qilin, DragonForce and others, and its core path — known Citrix, Fortinet and Confluence flaws, VPN without MFA, password spraying, destroy backups then hit virtualisation — remains exactly what regional enterprises most need to close.
How to identify it
Extension. Encrypted files gain a random six-character uppercase alphanumeric suffix, differing per victim or per deployment. Extension alone cannot establish the family; it must be cross-checked against the note name.
Ransom note. The filename takes the form README_[the same six-character string].txt, dropped in every encrypted directory. That correspondence between extension and note filename is the most reliable RansomHub identifier — mechanically similar to BlackCat's seven-character scheme but with a different length.
Note content. No email address is provided, only a .onion client portal link and a victim-specific client ID. The publication deadline is typically between 3 and 90 days, set by the affiliate.
Host-side artefacts.
- Volume shadow copies deleted (vssadmin / wmic).
- Traces of EDRKillShifter-class BYOVD tooling — loading a vulnerable signed driver to terminate EDR — a signature tool of RansomHub affiliates.
- PsExec, AnyDesk, Atera and Splashtop-style remote and bulk-execution tools.
- Large volumes of failed logons left by password spraying and brute force.
Platform footprint. Encryptor payloads were generated per platform from the operator panel, with Windows, Linux/NAS, ESXi and SFTP builds — so a single incident can hit Windows hosts, Linux servers, ESXi guests and NAS devices simultaneously.
Timeline note. RansomHub went dormant in early April 2025. RansomHub-like events after that date need fresh family identification, and usually reflect migrated affiliates operating under Qilin, DragonForce or another platform.
Infection vectors
RansomHub's affiliate base was heterogeneous — many arrived from ALPHV and LockBit — so tradecraft varied, but the main lines in the CISA advisory are clear.
1. Mass exploitation of known vulnerabilities, including:
- CVE-2023-3519 (Citrix ADC/Gateway remote code execution)
- CVE-2023-27997 and CVE-2020-12812 (Fortinet FortiOS)
- CVE-2023-46604 (Apache ActiveMQ)
- CVE-2023-22515 (Atlassian Confluence)
- plus classics such as Zerologon and EternalBlue for internal escalation and lateral movement.
2. Password spraying and credential attacks against webmail, VPN and RDP gateways, using accounts sourced from breach dumps — essentially free where MFA is absent.
3. Phishing for initial payload delivery or credential theft.
4. Initial access brokers, buying established network access outright.
The typical post-compromise chain:
- terminate EDR with BYOVD tooling such as EDRKillShifter to clear the field;
- harvest credentials with Mimikatz-class tools and escalate to domain admin;
- enumerate and destroy backups first (backup servers, backup storage, cloud sync), then delete shadow copies;
- exfiltrate with Rclone or cloud-storage clients;
- generate per-platform encryptors from the operator panel and deploy them simultaneously across Windows, Linux, ESXi and NAS via PsExec, scheduled tasks or remote tools.
Worth stressing: although the RansomHub brand is dormant, its affiliates took this entire path with them to Qilin, DragonForce and elsewhere. Auditing against this list defends against attacks that are still live today.
Encryption behavior
Algorithms. Key agreement via Curve25519, with file content encrypted using AES or ChaCha20 depending on platform. Compared with traditional RSA constructions, Curve25519 uses shorter keys and faster operations — part of why RansomHub encrypted so quickly. Key material can only be recovered with the operators' private key, and no exploitable weakness is public.
Intermittent encryption. The CISA advisory records intermittent encryption explicitly: files are processed in chunks with sections skipped, covering the most hosts in the least time. For large files — VMDKs, database data files, archives — that means a meaningful proportion of original data was never overwritten, which is the main opening for recovery. The skip ratio varies with build parameters and must be measured per case.
Multi-platform builds. Encryptors were generated on demand from the operator panel in Windows, Linux/NAS, ESXi and SFTP variants with differing command-line options and features. The practical consequence is that a single incident often encrypted the Windows domain, Linux application servers, ESXi guests and NAS shares almost simultaneously, so recovery must address several technology stacks at once.
Destructive actions.
- Deletes volume shadow copies (vssadmin / wmic).
- Locates and destroys backup servers and backup storage as a priority.
- Terminates EDR through BYOVD tooling such as EDRKillShifter.
- Stops database and backup-agent services.
Double extortion and deadlines. Exfiltration preceded encryption, with a publication deadline set by the affiliate, typically 3 to 90 days, after which data appeared on the .onion leak site. Note that both the leak site and the negotiation portal have been unavailable since April 2025.
Assess before you act
Recoverability assessment
One premise comes first: RansomHub's infrastructure has been dormant since April 2025, its negotiation portal and key service no longer exist, and payment is likely to buy nothing. All work is therefore technical.
1. Backups, snapshots and shadow copies. RansomHub affiliates destroyed backups as a priority, so "we have backups" must be validated copy by copy rather than counted. Focus on offline and off-site backups, tape, immutable or object-locked cloud backups, snapshots on storage arrays and NAS controllers (beyond the encryptor's reach), and overlooked historical copies. For older incidents, relevant snapshots may already have aged out under retention policy — confirm and freeze immediately.
2. Intact blocks left by intermittent encryption — the primary source. CISA documents intermittent encryption explicitly, so large files retain substantial original data:
- map the encryption layout of VMDKs, locate covered blocks against intact ranges, rebuild partition tables and filesystems, and export guest databases, shares and business files;
- repair SQL Server, Oracle and MySQL data files at page and extent level, discarding overwritten pages, rebuilding indexes and metadata, then merging unencrypted transaction and archive logs to consistency;
- extract usable objects from PST, ZIP/RAR, imaging and CAD files by walking format structures.
It depends on the layout. A large skip ratio with critical metadata untouched yields a high recoverable share; the reverse reduces it sharply. Measure first, assess second; no percentage promised.
3. Parallel handling across stacks. Because Windows, Linux, ESXi and NAS may all have been encrypted together, recovery must be sequenced by business priority — typically core databases and ERP/MES first, file shares and archives second. NAS devices need separate assessment of their snapshot mechanism and RAID/volume integrity.
4. Unencrypted copies and log replay. Dev/test databases, read-only reporting instances, downstream warehouses, ERP/OA staging tables and interface files, endpoint-local copies, mail attachments and scan archives; transaction and interface logs can rebuild key documents.
5. Low-level carving. Deleted originals, purged backup directories and removed VM snapshots may leave recoverable clusters.
6. Attribution still matters. Even with the brand dormant, the original entry point and persistence may well still be in place — unpatched Citrix/Fortinet/Confluence, VPN without MFA, attacker-created accounts — while the same affiliates operate under Qilin and others. Leaving those open simply means the next incident arrives under a different name.
Our limits. No claim of 100% decryption, no guaranteed recovery, no ransom payment, no negotiation on your behalf.
Our response plan
Hit by RansomHub ransomware? What to do
Containment and multi-stack scene preservation
RansomHub frequently hit the Windows domain, Linux servers, ESXi and NAS in a single incident, so containment and preservation must span every stack rather than just the host that was noticed first.
Take read-only images of ESXi datastores, database files, NAS volumes and backup volumes; preserve README_*.txt, encrypted samples, records of EDR termination and driver loads, logs from edge systems such as Citrix, Fortinet and Confluence, and the failed-logon records left by password spraying. Suspend automatic snapshot reclamation on storage and NAS immediately. Do not power off, do not rebuild.
Family confirmation, timeline and encryption measurement
Confirm RansomHub from the six-character extension matching README_[same string].txt, and establish when encryption occurred. If the event postdates April 2025, re-evaluate the family — RansomHub is dormant, and later lookalike events usually involve former affiliates now operating under Qilin or DragonForce. Getting this wrong derails both the recovery plan and the attribution work.
Then run per-block entropy and structure comparison on representative large files across each stack (vmdk, mdf/ndf, dbf, ibd, large files on NAS) to measure the real skip ratio and distribution of the intermittent scheme, whether critical metadata was overwritten, and whether writes were in place.
Recoverability assessment and plan
State the core fact to leadership first: RansomHub's negotiation and key infrastructure no longer exist, so "pay to decrypt" is not an available option. Then consolidate measured results: copy-by-copy backup and snapshot validation, the reach of partial-encryption repair, what unencrypted copies and logs can backfill, and opportunities in carving and NAS volume structure.
The deliverable is a recoverability assessment broken out by Windows, Linux, ESXi and NAS: recoverable scope, achievable point in time, consistency risks, what cannot be recovered, timeline, and a cross-stack recovery priority order.
Recovery execution and business validation
Work through priorities in an isolated clean environment: restore from validated backups, storage snapshots or NAS snapshots; rebuild VMDK extents and export guest data; repair databases at page level with log merging and consistency checks; restore Linux application servers and NAS shares in priority batches by directory.
Business owners sample-verify each recovered system against core tables, key documents and recent activity before production cutover, with a data-gap list issued for any system that cannot reach the latest point in time.
Attribution, hardening and sign-off (focus: successor families)
Even with RansomHub dormant, entry points and persistence must be fully cleared — because the same affiliates operate under Qilin and DragonForce with an identical playbook.
Checklist: are Citrix (CVE-2023-3519), Fortinet (CVE-2023-27997 / CVE-2020-12812), Apache ActiveMQ (CVE-2023-46604) and Confluence (CVE-2023-22515) patched; are domain controllers still exposed to Zerologon; what is MFA coverage and spray protection on VPN, webmail and RDP gateways; have attacker-created accounts and remote tools been removed.
Hardening priorities: edge-system patching and end-of-life governance, MFA everywhere with lockout policies, backups moved off-domain onto immutable storage, isolated management planes for ESXi and NAS, driver-load monitoring against EDRKillShifter-class BYOVD tooling, and detections for bulk Rclone egress. We close with a sign-off report and observation-period guidance.
Risk warning
What not to do
- Do not attempt to pay RansomHub. Its negotiation portal and leak site have been offline since April 2025 (and were briefly taken over by DragonForce), so payment is very likely to yield neither a key nor any commitment.
- Do not deal only with the first machine found encrypted. RansomHub's encryptor shipped in Windows, Linux/NAS, ESXi and SFTP builds, and a single incident commonly hit several stacks at once — missing one leads to re-encryption or incomplete recovery.
- Do not let snapshots on storage arrays and NAS expire automatically. The encryptor cannot reach that layer, but retention policy reclaims them — freeze snapshot deletion the moment encryption is found.
- Do not reboot or rebuild encrypted hosts, and do not run disk-repair utilities on encrypted volumes. The intact blocks skipped by intermittent encryption are the primary recovery source, and any write may overwrite them.
- Do not skip attribution and hardening because "the family is dormant". The same affiliates now operate under Qilin and DragonForce, and the same Citrix/Fortinet/Confluence flaws and MFA-less VPNs will be exploited again.
- Do not delete README_*.txt, encrypted samples, records of EDR termination and driver loads, or edge-device logs. They are the key evidence for family identification, timeline reconstruction and compliance notification.
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
ESXi / Hyper-V Virtualization Encrypted by Ransomware
Hypervisor-level encryption causes the widest blast radius of any ransomware event: dozens of production VMs go dark within an hour or two. This page covers what Linux ESXi encryptors actually do — shut down guests, encrypt vmdk, delete snapshots — the recovery value of flat disk files, and how Hyper-V and Proxmox cases differ.
File Servers and NAS Encrypted by Ransomware
When shared folders on a file server or NAS are encrypted, drawings, contracts, archives, quotations and design sources all become unusable at once — and mapped drives spread the impact to every endpoint. This page covers how to gauge spread, what shadow copies and snapshots realistically offer, and how to sequence recovery by business value.
Backups Deleted or Destroyed
Modern ransomware follows a fixed sequence: destroy the backups, then encrypt the data — deleting shadow copies, encrypting repositories, disabling jobs, and exploiting backup software flaws to steal credentials. This page covers what can still be inventoried once backups fail, why replication propagates encrypted files off-site, and what offline and immutable copies are really worth.
Database Encrypted by Ransomware
When database files are encrypted, every business system that depends on them stops at once. This page explains how we triage an encrypted database, how recoverability is assessed, and when file repair, backup-plus-log restore, or rebuild is the right path.
Related industries
Healthcare Ransomware Response and Recovery
When a hospital is hit, registration, consultation, orders, billing, laboratory and imaging fail at the same moment and care falls back to paper. This page covers the healthcare threat picture, a recovery priority built around clinical continuity, and the handling of patient data and compliance obligations.
Government and Public Sector Ransomware Response
Public sector ransomware incidents run on three lines at once: service interruption, data security and mandatory reporting. When document circulation, archives and integrated service platforms stop, both public services and internal operations are affected. This page covers the handling sequence, reporting duties and hardening priorities.
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Similar families
- No public decryptor
BlackCat
BlackCat (ALPHV) was the first major Rust-based ransomware-as-a-service operation, active from November 2021. It seized accounts through help-desk social engineering, encrypted ESXi and Windows estates under double extortion, and shut down in a March 2024 exit scam after keeping the Change Healthcare ransom — its key infrastructure no longer exists.
- No public decryptor
Qilin
Qilin (formerly Agenda) is a Rust-rewritten cross-platform RaaS operation focused on VMware ESXi and Linux estates. It has ranked as the world's most active ransomware group for several consecutive quarters since 2025, with confirmed victims among electronics manufacturers in Taiwan and Hong Kong.
- No public decryptor
DragonForce
DragonForce is one of the most active ransomware cartels today. Since 2025 it has offered white-label encryptors and infrastructure to affiliates, hits virtualisation estates hard, and became widely known through the chain of UK retail attacks. No public decryptor exists.
FAQ
RansomHub Frequently asked questions
RansomHub is dormant — can data it encrypted still be recovered?
It is worth attempting, but only through technical routes — there is no counterparty left to pay for keys. RansomHub's negotiation portal and leak site went offline between late March and early April 2025, its site was briefly taken over by DragonForce, and it has not resumed.
Technical opportunities come from three places. Snapshots on storage arrays and NAS controllers — beyond the encryptor's reach, though retention policy may already have expired them. Intact blocks left by intermittent encryption — CISA documents the intermittent scheme explicitly, so VMDKs and database files typically retain substantial original data recoverable by layout mapping and structured repair. Unencrypted copies and logs.
If the data was shelved at the time and never written over, conditions are actually better now. We can run a recoverability assessment against images and state explicitly what can and cannot be recovered.
How does RansomHub relate to BlackCat and Qilin?
They form a migration chain of the same operators across platforms.
In early 2024, LockBit was disrupted by law enforcement and ALPHV/BlackCat ran its exit scam — keeping roughly USD 22 million from Change Healthcare and shutting down — leaving many affiliates in need of a platform. RansomHub launched in February 2024 and absorbed them with an unusually generous revenue share, including the Change Healthcare attacker ALPHV had cheated, who brought a copy of the data across and re-extorted the same victim.
After RansomHub's infrastructure went offline in early April 2025, affiliates migrated en masse into Qilin — Group-IB observed its leak volume double — with some moving to DragonForce.
The defensive lesson: build defences around paths, not brands. From BlackCat to RansomHub to Qilin, the core tradecraft barely changed — known edge-device flaws, VPN without MFA, password spraying, BYOVD to kill EDR, destroy backups then hit virtualisation. Closing those matters far more than tracking which brand is currently alive.
Our Windows servers, ESXi and Synology NAS were all encrypted at once — is that normal?
For RansomHub this is typical. Its encryptor was generated per platform from the operator panel in Windows, Linux/NAS, ESXi and SFTP builds, and affiliates could deploy across every stack in one operation.
Two handling implications follow. First, containment and forensics must cover all stacks — dealing only with the host noticed first can miss a still-running encryption process or a live persistence channel. Second, assess per stack and sequence centrally: on ESXi, the intermittent coverage of VMDKs and storage-layer snapshots; on NAS, controller snapshots (such as Btrfs snapshots), volume and RAID integrity, and the scope of encryption across shares; on Windows, database file repair and the extent of domain-wide spread.
One warning specific to NAS: do not run filesystem repair or RAID rebuild operations on the device, and do not reinstall firmware over the top. Many failed NAS recoveries are lost not to the ransomware but to remediation attempts made afterwards.
Are RansomHub attacks still happening?
New attacks under the RansomHub brand have essentially stopped — the platform has been dormant since April 2025 and its leak site is no longer updated. But the same attacks continue under different names.
If you encounter a RansomHub-looking event after April 2025 (a random six-character extension with a README_ note), re-run family identification. It may be former affiliates using another platform's encryptor under Qilin or DragonForce, or an imitator. A wrong family call skews decryption expectations, the recovery plan and the attribution work alike.
More usefully, audit against RansomHub's entry-point list, because that path was inherited wholesale: are Citrix CVE-2023-3519, Fortinet CVE-2023-27997/CVE-2020-12812, Apache ActiveMQ CVE-2023-46604 and Confluence CVE-2023-22515 patched; is MFA enforced with spray protection on VPN, webmail and RDP; are backups off-domain and immutable; does your EDR monitor driver loads.
Sources
- #StopRansomware: RansomHub Ransomware (AA24-242A) — CISA/FBI/MS-ISAC/HHS
- RansomHub Went Dark April 1; Affiliates Fled to Qilin, DragonForce Claimed Control — The Hacker News
- RansomHub ransomware-as-a-service — Group-IB
- RansomSnub: RansomHub's Affiliate Confusion — GuidePoint Security
External links are provided for reference only. The content is published by third parties and does not represent our position.
Updated