勒索病毒家族
RansomHub 勒索病毒解密与数据恢复
- 已停止活动
- 高危
- 暂无公开解密工具
RansomHub 于 2024 年 2 月由 Knight/Cyclops 改头换面推出,凭借 90% 高分成迅速吸纳 ALPHV 与 LockBit 的附属成员,一年内受害者数百家;2025 年 4 月初基础设施下线后转入停摆,附属成员大多迁往 Qilin 与 DragonForce。
- 首次出现
- 2024-02
- 加密后缀
- .[6位随机字符]
- 勒索信文件
- README_[6位随机字符].txt
- 受影响平台
- Windows / Linux / VMware ESXi / NAS 存储
家族档案
- 加密后缀
- .[6位随机字符]
- 勒索信文件
- README_[6位随机字符].txt
- 联系方式模式
- Tor 客户端门户(受害者专属 client ID)
- .onion 泄露站点(3–90 天公布期限)
- 不留邮箱地址
- 别名 / 版本
- Cyclops、Knight、Water Bakunawa
- 首次出现
- 2024-02
- 活跃状态
- 已停止活动
- 运营状态
- 已停止运营
- 威胁等级
- 高危
- 受影响平台
- Windows
- Linux
- VMware ESXi
- NAS 存储
- 标签
- 已停止
- 勒索即服务
- 双重勒索
- 针对虚拟化
- 漏洞利用
- 钓鱼邮件
没有公开免费的 RansomHub 解密工具。
RansomHub 使用 Curve25519 椭圆曲线做密钥协商,配合 AES 或 ChaCha20(按目标平台选择)加密文件内容,并采用间歇加密提高速度。密钥材料由攻击者私钥保护,密文侧无公开可利用缺陷,NoMoreRansom 等平台未收录相关解密器。
此外,RansomHub 的基础设施已于 2025 年 3 月底至 4 月初下线(其泄露站点一度被 DragonForce 接管),协商门户与密钥服务不再可用——这意味着即使支付赎金也可能拿不到任何密钥。若你在 2025 年 4 月之后遇到「疑似 RansomHub」的加密事件,应重新做家族判定,很可能是迁移后的附属成员在其他平台(如 Qilin、DragonForce)下的行动。
恢复只能走备份与快照、间歇加密留下的完好数据块、未加密副本与日志。
最新动态
复核泄露站点监测:RansomLook 与 Ransomware.live 显示 RansomHub 的全部 .onion 镜像近 30 天可用率为 0%,最后一条受害者公布仍停留在 2025 年 4 月 1 日(累计约 842 家、覆盖 73 国)。协商门户与密钥服务确已不存在,历史受害者不存在可付款的对手方,只能走技术恢复路径。
参考来源Group-IB 年度勒索报告回溯 RansomHub 崩解:DragonForce 曾在 RAMP 宣称其「已迁入我方基础设施」,RansomHub 则公开指责对方破坏、背叛并与执法机关合作;失散的附属成员分流至 Qilin 与 DragonForce。报告列出的 2026 年八大活跃团伙(Qilin、Akira、Cl0p、DragonForce 等)已不含 RansomHub,印证该品牌未复活。
参考来源研究人员披露:RansomHub 自研的 EDR 杀手 EDRKillShifter 已演化出通用版本,被 Qilin、DragonForce、Medusa、BlackSuit、INC、Lynx 等八个团伙共用,用带毒签名驱动关停 Defender、SentinelOne、卡巴斯基等主流终端防护。品牌虽已停摆,其核心武器仍在打击今天的受害者,驱动加载监控与防篡改保护必须开启。
参考来源
家族概述
RansomHub 于 2024 年 2 月上线,CISA 公告指出其前身为 Cyclops 与 Knight(Trend Micro 将其运营方追踪为 Water Bakunawa)。它出现的时间点极具代表性:LockBit 刚被国际执法行动打击、ALPHV/BlackCat 正在酝酿退出骗局,大批熟练附属成员急需新平台。RansomHub 用对附属成员极为有利的分成比例(普遍报道为 90%)和「先收款、再分账」的模式迅速吸纳了这批人,其中就包括在 2024 年 2 月入侵 Change Healthcare、被 ALPHV 独吞赎金的那名附属成员——他带着数据副本转投 RansomHub,对同一受害者发起了二次勒索。
规模增长极快。CISA 于 2024 年 8 月发布 #StopRansomware 公告(AA24-242A)时,已记录至少 210 家受害组织,覆盖医疗、政府、供水、金融、关键制造等多个关键基础设施领域;其泄露站点累计声称的受害者总数达 800 家以上。2024 年下半年,RansomHub 一度是全球公布受害者最多的勒索团伙之一。
结局同样迅速。2025 年 3 月 31 日前后,RansomHub 的协商门户与泄露站点陆续离线,4 月 1 日全面中断;DragonForce 随即在 RAMP 论坛宣称 RansomHub「已加入我们的卡特尔」,并接管/篡改了其站点。Group-IB 等机构观察到大量附属成员迁入 Qilin——这正是 Qilin 从 2025 年二季度起攻击量翻倍、继而长期占据全球第一的直接原因之一。此后 RansomHub 未恢复运营,应视为已停摆。
对企业的现实含义有两层。其一,若历史上被 RansomHub 加密的数据仍未处理,现在没有任何可付款换密钥的对手方,只能走技术恢复。其二,也是更重要的一点:打你的那批人还在。RansomHub 的附属成员带着同样的手法迁到了 Qilin、DragonForce 等平台,其核心路径——Citrix/Fortinet/Confluence 等已知漏洞、无 MFA 的 VPN、密码喷洒、先毁备份再打虚拟化——今天依然是国内企业最需要堵的口子。
如何识别
后缀特征:加密后文件追加一段随机 6 位大写字母/数字作为后缀(每个受害者或每次投放不同)。仅凭后缀无法定家族,必须与勒索信名对照。
勒索信:文件名形如 README_[与后缀相同的 6 位串].txt,散布于每个被加密的目录。「后缀串 = 勒索信名中的串」这一对应关系是识别 RansomHub 最可靠的依据,与 BlackCat 的 7 位串机制类似但位数不同。
勒索信内容特征:不留邮箱地址,只给 .onion 客户端门户链接与受害者专属 client ID;给出的数据公布期限通常在 3 到 90 天之间,由附属成员自行设定。
主机侧痕迹:
- 卷影副本被删除(vssadmin / wmic);
- 出现 EDRKillShifter 类的 BYOVD 工具痕迹——加载易受攻击的签名驱动来终止 EDR,这是 RansomHub 附属成员的标志性工具;
- 常见 PsExec、AnyDesk、Atera、Splashtop 等远控与批量执行工具;
- 密码喷洒与暴力破解留下的大量失败登录记录。
平台特征:加密器由控制面板按平台生成,存在 Windows、Linux/NAS、ESXi、SFTP 等构建版本,因此同一事件中 Windows 主机、Linux 服务器、ESXi 虚拟机与 NAS 可能被同时命中。
时间线提示:RansomHub 于 2025 年 4 月初停摆。此后出现的「RansomHub 样」事件需重新判定家族,多为迁移后的附属成员在 Qilin、DragonForce 等平台下的行动。
传播与入侵方式
RansomHub 附属成员来源复杂(大量来自 ALPHV 与 LockBit),手法覆盖面广,但 CISA 公告归纳的主线很清楚。
1. 已知漏洞的规模化利用。公告列出的包括:
- CVE-2023-3519(Citrix ADC/Gateway 远程代码执行)
- CVE-2023-27997、CVE-2020-12812(Fortinet FortiOS)
- CVE-2023-46604(Apache ActiveMQ)
- CVE-2023-22515(Atlassian Confluence)
- 以及 Zerologon、EternalBlue 等经典内网提权/横向漏洞。
2. 密码喷洒与凭据攻击。对邮箱、VPN、RDP 网关做密码喷洒,并使用从数据泄露中获取的账号——无 MFA 时这条路几乎零成本。
3. 钓鱼邮件。用于投递初始载荷或窃取凭据。
4. 初始访问经纪人。直接购买已建立的内网访问权限。
进入内网后的典型链条:
- 用 EDRKillShifter 等 BYOVD 工具终止 EDR,为后续动作清场;
- 用 Mimikatz 类工具抓取凭据、提权至域管;
- 枚举并优先破坏备份(备份服务器、备份存储、云同步),删除卷影副本;
- 用 Rclone 或云存储客户端外传数据;
- 从控制面板按平台生成加密器,通过 PsExec、计划任务或远控工具,在 Windows、Linux、ESXi 与 NAS 上同时投放。
需要强调:虽然 RansomHub 品牌已停摆,但上述路径被其附属成员完整带到了 Qilin、DragonForce 等平台。按这份清单做自查,防的其实是今天仍在活跃的攻击。
加密特点
算法:以 Curve25519 椭圆曲线完成密钥协商,文件内容按平台使用 AES 或 ChaCha20 加密。相较传统 RSA 方案,Curve25519 的密钥更短、运算更快,这也是 RansomHub 加密速度快的原因之一。密钥材料只能由攻击者私钥还原,无公开可利用缺陷。
间歇加密:CISA 公告明确记录 RansomHub 采用间歇加密——按块处理文件并跳过部分区段,以最短时间覆盖最多主机。对大文件(vmdk、数据库数据文件、归档包)而言,这意味着相当比例的原始数据未被覆盖,是后续恢复的主要空间。具体跳过比例随构建参数变化,必须逐例实测。
多平台构建:加密器由控制面板按需生成,存在 Windows、Linux/NAS、ESXi、SFTP 等版本,命令行参数与功能各不相同。实践中常见的后果是:一次事件里 Windows 域、Linux 应用服务器、ESXi 虚拟机与 NAS 共享几乎同时被加密,恢复时必须同时处理多个技术栈。
破坏动作:
- 删除卷影副本(vssadmin / wmic);
- 优先定位并破坏备份服务器与备份存储;
- 用 BYOVD 方式(如 EDRKillShifter)终止 EDR;
- 停止数据库与备份代理服务。
双重勒索与期限:先外传后加密,勒索信中的数据公布期限由附属成员设定,通常 3–90 天,逾期在 .onion 泄露站点公布。注意:该泄露站点与协商门户自 2025 年 4 月起已不可用。
先评估,再动手
可恢复性评估
RansomHub 的可恢复性评估有一个前提必须先讲清楚:其基础设施自 2025 年 4 月起已停摆,协商门户与密钥服务不复存在,支付赎金很可能换不到任何东西。因此所有工作都在技术侧。
1. 备份、快照与卷影副本。RansomHub 附属成员会优先破坏备份,所以「有备份」必须逐份验证而非清点数量。重点核查:离线与异地备份、磁带、启用不可变/对象锁的云备份、存储阵列与 NAS 控制器上的快照(加密器删不到这一层)、以及被忽略的历史副本。若事件发生在较早时期,相关快照可能已按保留策略过期,需第一时间确认并冻结。
2. 间歇加密留下的完好数据块——主要恢复来源。CISA 已明确记录其采用间歇加密,因此大文件中保留可观原始数据。可行做法:
- 对 vmdk 做加密图谱测绘,定位被覆盖块与完好区段,从完好区段重建分区表与文件系统,导出虚拟机内的数据库、共享目录与业务文件;
- 对 SQL Server / Oracle / MySQL 数据文件做页级、区段级修复,剔除被覆盖页后重建索引与元数据,再与未加密的事务日志、归档日志合并至一致状态;
- 对 PST、ZIP/RAR、影像与图纸文件,按格式结构从完好区段抽取可用对象。
视加密方式而定:跳过比例大、关键元数据未被覆盖时可恢复比例较高;反之下降明显。先测后评,不承诺百分比。
3. 多技术栈并行处理。由于 Windows、Linux、ESXi、NAS 可能同时被加密,恢复必须按业务优先级统筹:通常核心数据库与 ERP/MES 优先,其次是文件共享与归档。NAS 侧要单独评估其快照机制与 RAID/卷结构是否完好。
4. 未加密副本与日志回放。开发测试库、只读报表库、下游数据仓库、ERP/OA 中间表与接口文件、终端本地副本、邮件附件与扫描归档;业务流水与接口日志可用于重建关键单据。
5. 底层碎片恢复。被删除的原文件、被清空的备份目录与虚拟机快照,可能在卷上留有可挖掘的簇。
6. 溯源不能省。即便品牌已停摆,当年的入口与驻留很可能仍然存在(未修补的 Citrix/Fortinet/Confluence、无 MFA 的 VPN、攻击者自建账号),而原班附属成员正在 Qilin 等平台继续作业。不补这些口子,下一次事件只是换个名字。
我们的边界:不承诺 100% 解密、不保证恢复、不支付赎金、不代谈判。
我们的处置方案
中了 RansomHub 勒索病毒怎么办?
隔离取证与多栈现场保全
RansomHub 常在一次事件中同时命中 Windows 域、Linux 服务器、ESXi 与 NAS,因此隔离与固证必须覆盖全部技术栈,而不是只处理「最先发现的那台」。
同时对 ESXi 数据存储、数据库文件、NAS 卷与备份卷做只读镜像;封存 README_*.txt、加密样本、EDR 被终止的记录与驱动加载痕迹、Citrix/Fortinet/Confluence 等边界系统日志、密码喷洒留下的失败登录记录。立即暂停存储与 NAS 的快照自动回收策略。不要关机、不要重装。
家族确认、时间线判定与加密测定
用「6 位随机后缀 = README_[同一串].txt」的对应关系确认 RansomHub,并核对加密发生时间。若事件在 2025 年 4 月之后,须重新判定家族——RansomHub 已停摆,此后的类似事件通常是迁移到 Qilin、DragonForce 的原附属成员所为,家族判错会让恢复方案与溯源方向同时跑偏。
随后对各栈的代表性大文件(vmdk、mdf/ndf、dbf、ibd、NAS 上的大文件)做逐块熵值与结构比对,测定间歇加密的实际跳过比例与分布,确认关键元数据是否被覆盖,以及是否原地覆写。
可恢复性评估与方案确定
先向管理层说明核心事实:RansomHub 协商与密钥基础设施已不存在,不存在「付款解密」这个选项。随后汇总技术路径的实测结果:备份与快照逐份验证结果、间歇加密修复的可达程度、未加密副本与日志的补位能力、底层碎片与 NAS 卷结构机会。
交付可恢复性评估报告:按 Windows / Linux / ESXi / NAS 分栈说明可恢复范围、可回到的时间点、一致性风险、不可恢复部分与工期,并给出跨栈的恢复优先级排序。
数据恢复实施与业务验证
在隔离的干净环境中按优先级推进:从经校验的备份、存储快照或 NAS 快照还原;对 vmdk 做区段重建并导出虚拟机内数据;对数据库做页级修复、日志合并与一致性校验;对 Linux 应用服务器与 NAS 共享按目录优先级分批恢复。
每个系统恢复后交业务方按核心表、关键单据与近期业务抽样验证,通过后再回切生产;对无法恢复到最新时间点的系统输出数据缺口清单,便于业务侧补录。
溯源加固与验收(重点:防后继家族)
即便 RansomHub 已停摆,入口与驻留必须彻底清理——因为原班附属成员仍在 Qilin、DragonForce 等平台作业,手法完全一致。
核查清单:Citrix(CVE-2023-3519)、Fortinet(CVE-2023-27997 / CVE-2020-12812)、Apache ActiveMQ(CVE-2023-46604)、Confluence(CVE-2023-22515)等是否已修补;域控是否仍受 Zerologon 影响;VPN/邮箱/RDP 网关的 MFA 覆盖与密码喷洒防护;攻击者自建账号与远控软件是否清除。
加固重点:边界系统补丁与 EOL 治理、全面 MFA 与账号锁定策略、备份离域并启用不可变存储、ESXi 与 NAS 管理面隔离、开启驱动加载监控应对 EDRKillShifter 类 BYOVD 工具、对 Rclone 大流量外传建立检测。交付验收报告与观察期建议。
风险提示
中招后切勿操作
- 不要尝试向 RansomHub 支付赎金。其协商门户与泄露站点自 2025 年 4 月起已下线(一度被 DragonForce 接管),付款极可能既拿不到密钥也换不来任何承诺。
- 不要只处理「最先发现被加密的那台机器」。RansomHub 的加密器有 Windows、Linux/NAS、ESXi、SFTP 多个构建版本,一次事件中多个技术栈常被同时命中,遗漏会导致二次加密或恢复不完整。
- 不要让存储阵列与 NAS 上的快照自动过期。加密器删不到这一层,但保留策略会自动回收——发现加密后应第一时间冻结快照删除。
- 不要重启、重装被加密主机或对被加密卷跑磁盘修复工具。间歇加密跳过的完好数据块是主要恢复来源,任何写入都可能覆盖它们。
- 不要因为「这个家族已经停摆」就跳过溯源与加固。原班附属成员已迁至 Qilin、DragonForce 等平台,同样的 Citrix/Fortinet/Confluence 漏洞与无 MFA 的 VPN 会被再次利用。
- 不要删除 README_*.txt、加密样本、EDR 被终止与驱动加载的记录、边界设备日志。这些是家族判定、时间线还原与合规通报的关键证据。
紧急响应
数据已被加密?先别动,让工程师看一眼
我们不支付赎金、不代为谈判。工程师会先做免费评估,判断可恢复范围后再给出处置方案与报价。
相关场景方案
ESXi / Hyper-V 虚拟化平台被勒索病毒加密
虚拟化平台被加密是破坏面最大的一类事件:几十台业务虚拟机会在一两个小时内同时不可用。本页说明 ESXi 被 Linux 版加密器攻击时的典型行为(关机、加密 vmdk、删快照)、平面磁盘文件的恢复价值,以及 Hyper-V 与 Proxmox 场景的差异。
文件服务器与 NAS 被勒索病毒加密
文件服务器与 NAS 上的共享目录被加密,会让图纸、合同、档案、报价单、设计源文件同时不可用,而且通过映射盘影响所有终端。本页说明共享加密的扩散判断、卷影与快照的实际可用性,以及按业务价值排序的恢复方式。
备份被删除或损坏
现代勒索攻击的固定动作是「先毁备份、再加密数据」:删卷影、加密备份仓库、停用备份作业、利用备份软件漏洞窃取凭据。本页说明备份失效后还能清点哪些资源、为什么备份同步会把加密文件带到异地,以及离线与不可变副本的真实价值。
数据库被勒索病毒加密
数据库文件一旦被勒索病毒加密,ERP、OA、HIS 等所有依赖它的业务系统会同时停摆。本页说明数据库被加密后的判断顺序、可恢复性评估依据,以及「加密文件修复 / 从备份与日志恢复 / 重建」三条路径各自的适用条件。
相关行业方案
医疗机构勒索病毒应急与恢复
医院被勒索病毒攻击时,挂号、就诊、医嘱、收费、检验、影像会在同一时刻失效,诊疗必须降级为手工流程。本页说明医疗行业的威胁态势、以诊疗连续性为核心的恢复优先级,以及患者数据与合规方面的处置要点。
政企机构勒索病毒应急与恢复
政企机构的勒索事件同时涉及业务中断、数据安全与合规报送三条线。公文流转、档案管理、一体化政务服务平台一旦停摆,对外服务与内部办公同时受影响。本页说明处置顺序、报送要求与加固重点。
制造业勒索病毒应急与恢复
制造业的勒索事件几乎总是同时命中信息系统与生产节奏:ERP 停了开不了单,MES 停了排不了产,图纸库被加密则整条产品线的工艺文件不可用。本页说明制造企业的资产特点、恢复优先级排序与针对性防护。
相似勒索家族
- 暂无公开解密工具
BlackCat
BlackCat(ALPHV)是首个用 Rust 编写的大型 RaaS 勒索病毒,2021 年 11 月起活跃,以社工电话夺取账号、加密 ESXi 与 Windows 并双重勒索;2024 年 3 月在独吞 Change Healthcare 赎金后以退出骗局关停,密钥基础设施已不复存在。
- 暂无公开解密工具
Qilin
Qilin(原名 Agenda)是用 Rust 重写的跨平台 RaaS 勒索病毒,专攻 VMware ESXi 与 Linux 虚拟化环境;自 2025 年起连续多个季度位居全球最活跃勒索团伙首位,并已在台湾、香港的电子制造企业中造成受害。
- 暂无公开解密工具
DragonForce
DragonForce 是当前最活跃的勒索卡特尔之一,2025 年起以「白牌」模式向附属团伙输出加密器与基础设施,深度打击虚拟化环境,并因英国零售业连环攻击而广为人知;目前无公开解密工具。
常见问题
RansomHub 常见问题
RansomHub 已经停摆了,被它加密的数据还能恢复吗?
可以尝试,但只能走技术路径——付款换密钥这条路已经没有对手方了。RansomHub 的协商门户与泄露站点在 2025 年 3 月底至 4 月初陆续下线,其站点一度被 DragonForce 接管,此后未恢复运营。
技术上的机会来自三处:一是存储阵列与 NAS 控制器上的快照(加密器删不到这一层,但要注意保留策略是否已让它们过期);二是间歇加密留下的完好数据块——CISA 公告明确记录 RansomHub 采用间歇加密,vmdk 与数据库文件中往往保留可观原始数据,可通过加密图谱测绘与结构化修复取回;三是未加密副本与日志。
若数据当年被封存、之后没有二次写入,恢复条件反而更好。我们可以基于镜像做一次可恢复性评估,明确写出可恢复范围与不可恢复部分。
RansomHub 和 BlackCat、Qilin 是什么关系?
是同一批人在不同平台之间的迁移链条。
2024 年初,LockBit 遭执法打击、ALPHV/BlackCat 上演退出骗局(独吞 Change Healthcare 约 2200 万美元赎金后关停),大批附属成员需要新平台。RansomHub 于 2024 年 2 月上线,用极高的分成比例吸纳了这批人——包括那名被 ALPHV 坑掉分成的 Change Healthcare 攻击者,他带着数据副本转投 RansomHub 发起了二次勒索。
2025 年 4 月初 RansomHub 基础设施下线后,附属成员又大规模迁入 Qilin(Group-IB 观察到其泄露量随之翻倍),部分转向 DragonForce。
对防守方的意义在于:不要按「家族」来做防护,要按「路径」来做。从 BlackCat 到 RansomHub 再到 Qilin,核心手法几乎没变——边界设备已知漏洞、无 MFA 的 VPN、密码喷洒、BYOVD 关 EDR、先毁备份再打虚拟化。堵住这些,比记住哪个品牌还活着有用得多。
我们的 Windows 服务器、ESXi 和群晖 NAS 同时被加密了,这正常吗?
对 RansomHub 来说是典型情况。它的加密器由控制面板按平台生成,存在 Windows、Linux/NAS、ESXi、SFTP 等多个构建版本,附属成员可以在同一次行动中对各栈同时投放。
这带来两个处置要点。第一,隔离与取证必须覆盖全部技术栈,只处理最先发现的那台会漏掉仍在活动的加密进程或驻留通道。第二,恢复要分栈评估、统一排序:ESXi 侧看 vmdk 的间歇加密比例与存储层快照;NAS 侧看控制器快照(如 Btrfs 快照)、卷与 RAID 结构是否完好、以及共享目录的加密范围;Windows 侧看数据库文件修复与域内扩散范围。
NAS 这块要特别提醒:不要在 NAS 上执行「修复文件系统」「重建 RAID」等操作,也不要覆盖式重装固件——很多 NAS 数据恢复的失败都不是败给勒索病毒,而是败给中招后的补救操作。
现在还会遇到 RansomHub 攻击吗?
以 RansomHub 品牌出现的新攻击基本不会了——该平台自 2025 年 4 月起停摆,泄露站点也不再更新。但相同的攻击仍在发生,只是换了名字。
如果你在 2025 年 4 月之后遇到「看起来像 RansomHub」的事件(随机 6 位后缀 + README_ 开头的勒索信),请务必重新做家族判定:可能是迁移到 Qilin、DragonForce 的原附属成员使用了新平台的加密器,也可能是模仿者。判错家族会导致解密预期、恢复方案与溯源方向全部偏离。
更值得做的是按 RansomHub 的入口清单自查,因为这套路径被完整继承了:Citrix CVE-2023-3519、Fortinet CVE-2023-27997/CVE-2020-12812、Apache ActiveMQ CVE-2023-46604、Confluence CVE-2023-22515 是否已修补,VPN/邮箱/RDP 是否全面启用 MFA 并有密码喷洒防护,备份是否离域且不可变,EDR 是否具备驱动加载监控能力。
参考来源
- #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
外部链接仅供参考,内容由第三方发布,不代表本站立场。
更新于