跳转到主要内容

遭遇勒索病毒攻击?请立即断网隔离,切勿重启或格式化。

舍末无勒SheMo Noransom

勒索病毒家族

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)下的行动。

恢复只能走备份与快照、间歇加密留下的完好数据块、未加密副本与日志。

最新动态

  1. 复核泄露站点监测:RansomLook 与 Ransomware.live 显示 RansomHub 的全部 .onion 镜像近 30 天可用率为 0%,最后一条受害者公布仍停留在 2025 年 4 月 1 日(累计约 842 家、覆盖 73 国)。协商门户与密钥服务确已不存在,历史受害者不存在可付款的对手方,只能走技术恢复路径。

    参考来源
  2. Group-IB 年度勒索报告回溯 RansomHub 崩解:DragonForce 曾在 RAMP 宣称其「已迁入我方基础设施」,RansomHub 则公开指责对方破坏、背叛并与执法机关合作;失散的附属成员分流至 Qilin 与 DragonForce。报告列出的 2026 年八大活跃团伙(Qilin、Akira、Cl0p、DragonForce 等)已不含 RansomHub,印证该品牌未复活。

    参考来源
  3. 研究人员披露:RansomHub 自研的 EDR 杀手 EDRKillShifter 已演化出通用版本,被 Qilin、DragonForce、Medusa、BlackSuit、INC、Lynx 等八个团伙共用,用带毒签名驱动关停 Defender、SentinelOne、卡巴斯基等主流终端防护。品牌虽已停摆,其核心武器仍在打击今天的受害者,驱动加载监控与防篡改保护必须开启。

    参考来源

家族概述

RansomHub 于 2024 年 2 月上线,CISA 公告指出其前身为 CyclopsKnight(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-27997CVE-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 椭圆曲线完成密钥协商,文件内容按平台使用 AESChaCha20 加密。相较传统 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 勒索病毒怎么办?

  1. 隔离取证与多栈现场保全

    RansomHub 常在一次事件中同时命中 Windows 域、Linux 服务器、ESXi 与 NAS,因此隔离与固证必须覆盖全部技术栈,而不是只处理「最先发现的那台」。

    同时对 ESXi 数据存储、数据库文件、NAS 卷与备份卷做只读镜像;封存 README_*.txt、加密样本、EDR 被终止的记录与驱动加载痕迹、Citrix/Fortinet/Confluence 等边界系统日志、密码喷洒留下的失败登录记录。立即暂停存储与 NAS 的快照自动回收策略。不要关机、不要重装。

  2. 家族确认、时间线判定与加密测定

    用「6 位随机后缀 = README_[同一串].txt」的对应关系确认 RansomHub,并核对加密发生时间。若事件在 2025 年 4 月之后,须重新判定家族——RansomHub 已停摆,此后的类似事件通常是迁移到 Qilin、DragonForce 的原附属成员所为,家族判错会让恢复方案与溯源方向同时跑偏。

    随后对各栈的代表性大文件(vmdk、mdf/ndf、dbf、ibd、NAS 上的大文件)做逐块熵值与结构比对,测定间歇加密的实际跳过比例与分布,确认关键元数据是否被覆盖,以及是否原地覆写。

  3. 可恢复性评估与方案确定

    先向管理层说明核心事实:RansomHub 协商与密钥基础设施已不存在,不存在「付款解密」这个选项。随后汇总技术路径的实测结果:备份与快照逐份验证结果、间歇加密修复的可达程度、未加密副本与日志的补位能力、底层碎片与 NAS 卷结构机会。

    交付可恢复性评估报告:按 Windows / Linux / ESXi / NAS 分栈说明可恢复范围、可回到的时间点、一致性风险、不可恢复部分与工期,并给出跨栈的恢复优先级排序。

  4. 数据恢复实施与业务验证

    在隔离的干净环境中按优先级推进:从经校验的备份、存储快照或 NAS 快照还原;对 vmdk 做区段重建并导出虚拟机内数据;对数据库做页级修复、日志合并与一致性校验;对 Linux 应用服务器与 NAS 共享按目录优先级分批恢复。

    每个系统恢复后交业务方按核心表、关键单据与近期业务抽样验证,通过后再回切生产;对无法恢复到最新时间点的系统输出数据缺口清单,便于业务侧补录。

  5. 溯源加固与验收(重点:防后继家族)

    即便 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 被终止与驱动加载的记录、边界设备日志。这些是家族判定、时间线还原与合规通报的关键证据。

紧急响应

数据已被加密?先别动,让工程师看一眼

我们不支付赎金、不代为谈判。工程师会先做免费评估,判断可恢复范围后再给出处置方案与报价。

相关场景方案

相关行业方案

相似勒索家族

常见问题

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 是否具备驱动加载监控能力。