跳转到主要内容

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

舍末无勒SheMo Noransom

勒索病毒家族

DragonForce 勒索病毒解密与数据恢复

  • 活跃中
  • 极高危
  • 暂无公开解密工具

DragonForce 是当前最活跃的勒索卡特尔之一,2025 年起以「白牌」模式向附属团伙输出加密器与基础设施,深度打击虚拟化环境,并因英国零售业连环攻击而广为人知;目前无公开解密工具。

首次出现
2023-08
加密后缀
.dragonforce_encrypted .df_win .[9位随机字符]
勒索信文件
readme.txt
受影响平台
Windows / Linux / VMware ESXi / NAS 存储

家族档案

加密后缀
  • .dragonforce_encrypted
  • .df_win
  • .[9位随机字符]
勒索信文件
  • readme.txt
  • README.txt
  • Contact Us.txt
联系方式模式
  • Tor (.onion) 谈判门户 + 受害者专属 token
  • 暗网泄露站 DragonForce / RansomBay
  • 附属团伙自定义品牌与联系方式(卡特尔模式)
  • 电话骚扰与语音社工(配合 Scattered Spider 类初始访问方)
别名 / 版本
DragonForce Ransomware Cartel、RansomBay(白牌服务)、DragonForce ESXi Locker
首次出现
2023-08
活跃状态
活跃中
威胁等级
极高危
受影响平台
  • Windows
  • Linux
  • VMware ESXi
  • NAS 存储
标签
  • 活跃中
  • 勒索即服务
  • 双重勒索
  • 针对虚拟化
  • 漏洞利用
  • 供应链攻击
  • 泄露站常客
解密工具
暂无公开解密工具

目前没有任何公开免费的 DragonForce 解密工具。其加密器基于泄露的 LockBit 3.0 构建器与 Conti v3 源码改造,采用非对称密钥保护每个文件的对称密钥,密码学实现未发现可利用缺陷。网络上出现的所谓「DragonForce 解密器」均不可信,部分是携带二次勒索或窃密模块的恶意程序。恢复必须走备份与快照、虚拟磁盘与数据库结构修复、未加密副本与底层碎片提取等技术路线,并以实际样本评估为准。

最新动态

  1. 赛门铁克披露 DragonForce 使用 Go 后门 Backdoor.Turn,将 C2 流量伪装为 Microsoft Teams 的 TURN 中继通信,在一家美国服务企业潜伏约两个月;入侵自 MSSQL 漏洞起步,并借易受攻击驱动关停 EDR。受害者应回溯 Teams 中继连接与驱动加载记录,仅靠出站流量告警难以发现。

    参考来源
  2. 深度分析指出,DragonForce 已修补此前在公开论坛披露、曾与 Akira 相关的加密实现缺陷,并利用 truesight.sys、rentdrv2.sys 等易受攻击驱动关停安全软件。这意味着靠实现漏洞解密的可能性进一步关闭,恢复仍须依靠备份与结构化修复。

    参考来源
  3. ReliaQuest 报告称 DragonForce 与 LockBit、Qilin 结成联盟,共享工具、基础设施并互相导流附属。对受害者意味着勒索信品牌与实际加密器的对应关系更加混乱,家族判定必须依赖样本分析而非品牌名。

    参考来源

家族概述

DragonForce 最早于 2023 年 8 月出现,起步阶段直接使用泄露的 LockBit 3.0 构建器生成载荷,2024 年 6 月开放附属计划,7 月推出自研加密器(基于修改后的 Conti v3 源码),11 月出现针对 VMware ESXi 的 Linux 变种。

真正的转折点是 2025 年 3 月:DragonForce 宣布转型为「勒索卡特尔」,推出名为 RansomBay 的白牌服务——附属团伙可以用自己的品牌运营,加密器、谈判门户、泄露站托管与技术支持由 DragonForce 提供,附属按约 80/20 分成。这意味着受害者看到的勒索信品牌可能千差万别,底层却是同一套加密器和基础设施,给家族识别带来实际困难。

2025 年春季,DragonForce 因英国零售业连环攻击进入主流视野:Marks & Spencer、Co-op 与 Harrods 在数周内接连受创,公开分析认为由 Scattered Spider 一类以语音社工、服务台冒充和 MFA 疲劳攻击见长的英语系团伙负责初始访问,DragonForce 负责投放与勒索。这种「社工型初始访问 + 成熟加密器」的组合,绕开了传统以漏洞扫描为核心的防线。

活跃度方面,DragonForce 在 2026 年上半年仍保持每月约 28–30 家受害单位的发布节奏,累计受害者已达约 650 家,覆盖 65 个国家,行业集中在专业服务、制造与科技。目前没有公开报告确认其对中国大陆企业的定向攻击,但其偏好的入口——Ivanti、Log4j 一类边界漏洞,被入侵的 RMM 远程管理平台(供应链式扩散),以及暴露的 ESXi——在国内同样普遍存在,跨国企业的中国分支尤其需要关注。

如何识别

后缀与文件名:自研加密器会把原文件名整体替换为随机 Base32 字符串并追加 .dragonforce_encrypted,例如 合同.pdf 变成 3krbgdxb.dragonforce_encrypted——原文件名不可从加密文件本身恢复,这对恢复后的业务归位影响很大。也观察到 .df_win 等后缀;早期基于 LockBit 3.0 构建器的版本则使用随机字符后缀。

勒索信:readme.txt(部分样本为 Contact Us.txt),落在桌面、各加密目录,常额外投放到 inetpub、wwwroot 等网站根目录,便于外部访问时也能看到。信中给出 Tor 门户与受害者专属 token,不提供邮箱。

卡特尔带来的识别难点:RansomBay 白牌下,勒索信可能署名完全陌生的品牌,泄露站也不同,但加密器行为、文件尾部结构与 ESXi 端命令特征一致。因此判定必须依赖样本分析而非品牌名。

其他迹象:Mimikatz、PsExec、OpenVAS 扫描痕迹、异常 SMB 流量、注册表与安全软件被篡改;ESXi 场景可见 /vmfs/volumes 下虚拟机文件被加密且宿主仍可启动(加密器有白名单以保住宿主可引导)。

传播与入侵方式

DragonForce 的附属生态庞大,入口方式随附属而异,但公开分析反复出现以下几类:

  • 边界设备漏洞利用:Ivanti Connect Secure 系列漏洞(CVE-2023-46805、CVE-2024-21887、CVE-2024-21893)、Apache Log4j2 等,用于直接拿下 DMZ 立足点;
  • 社工型初始访问:与 Scattered Spider 一类团伙合作,通过冒充员工致电 IT 服务台重置密码、MFA 疲劳轰炸、SIM 交换等方式获取合法账号——这类入侵在日志上「看起来完全合法」,是英国零售业连环事件的关键;
  • RMM 远程管理平台:利用 SimpleHelp 等 RMM 产品的漏洞进入服务商环境,再经其管理通道批量下发到下游客户,构成供应链式扩散,对 MSP 与集团 IT 共享平台威胁极大;
  • 被窃凭据与 VPN:来自信息窃取木马与暗网市场的账号;
  • 横向移动与提权:Mimikatz 凭据转储、PsExec、RDP、域管权限接管,优先拿下域控与虚拟化管理平台;
  • 数据外传:在加密前完成,用于双重勒索与电话骚扰施压。

从国内视角看,最值得警惕的是后两条:集团型企业与制造企业普遍存在「IT 共享服务平台 + 大量远程运维工具」的结构,一旦管理通道被打穿,扩散速度远快于逐台入侵。

加密特点

算法:自研加密器采用 ChaCha8 做文件内容加密,以 RSA-4096 保护每个文件的对称密钥;早期 LockBit 3.0 构建器版本则沿用 LockBit 的加密方案。两者都属于在没有攻击者私钥时无法逆推的设计。

速度优化:对大文件采用分块/间歇加密(配置参数中可见块大小与跳跃设置),以便在有限时间窗口内打完整个环境。对恢复而言,这意味着虚拟磁盘与数据库文件内部仍可能保留大段未被覆盖的数据,是结构化修复的主要依据,但可利用程度需按实际样本测定。

虚拟化:Linux/ESXi 变种直接针对 /vmfs/volumes 路径加密虚拟机文件,并保留系统目录、扩展名与文件名白名单以保证宿主仍可启动——攻击者故意让宿主活着,只让业务停摆,从而保留谈判通道。

破坏恢复能力:删除卷影副本、禁用启动时恢复选项、停止数据库与备份服务,尽可能加密可直连的备份存储与网络共享。

文件名随机化:原文件名被整体替换,恢复阶段需要依靠备份索引、数据库内部元数据或文件内容特征来重建目录结构。

双重勒索及以上:除加密与泄露外,DragonForce 生态还提供针对受害者的电话骚扰服务和数据分析服务,以提高施压效果。

先评估,再动手

可恢复性评估

DragonForce 没有公开解密工具,DragonForce勒索病毒解密在密码学层面不可行。我们不支付赎金、不代为谈判,只做可验证的技术恢复。

1)备份、快照与卷影(优先级最高):DragonForce 会主动破坏可直连的备份,但真正被打掉的往往只是「在线可达」的那一份。需要系统排查:离线介质与异地副本、备份平台的不可变存储、存储阵列/NAS 的卷快照、虚拟化平台快照与孤立的快照文件、云端同步的历史版本、被排除在域认证之外的备份服务器。实践中这条路径的恢复比例最高。

2)虚拟机与数据库文件的结构化修复(视加密方式而定):由于对大文件采用分块加密,vmdk/vhdx 内部的文件系统元数据与数据区常保留大段完好内容,可修复分区与元数据后挂载提取内部文件;SQL Server、Oracle、MySQL 的数据文件可做页级抽取与逻辑重建,配合事务日志补齐时点。关键结构被覆盖时恢复比例会明显下降,必须先做抽样测试再给预期。

3)未加密副本与日志回放:文件服务器回收站与旧版本、终端本地缓存、BI 与报表中间库、ERP 与 MES 的归档导出、邮件服务器副本、上下游往来的对账单与合同副本,都可用于关键数据重建。

4)底层碎片恢复:加密器若以新建文件加删除原文件的方式落盘,原始内容可能仍在未分配空间,可通过原始扇区扫描提取。ESXi 场景下这要求绝不重新初始化数据存储、不在原 LUN 上新建虚拟机。

5)文件名重建:由于原文件名被随机化,恢复出来的内容还需要重新归位。可借助备份索引、数据库内部表名、文档内嵌元数据与内容指纹批量还原目录结构,这部分工作量常被低估,应纳入项目排期。

关于 DragonForce 数据恢复,我们提供的是基于实测的评估结论与明确恢复范围,不承诺「100% 解密」,也不存在「保证恢复」的技术手段。

我们的处置方案

中了 DragonForce 勒索病毒怎么办?

  1. 隔离与取证固定

    切断 ESXi 宿主、域控、备份服务器与业务网络及存储的连接,吊销可疑账号会话与 VPN 令牌,暂停 RMM/远程运维平台的下发能力(防止经管理通道二次投放)。不要重启、不要重新初始化数据存储。对数据存储与关键卷做只读镜像或存储快照,导出 ESXi、vCenter、AD、VPN、RMM 与服务台工单日志——服务台记录对识别社工型入侵尤为关键。保留 3–5 个加密文件与 readme.txt。

  2. 家族识别与加密分析

    在卡特尔模式下不能只看勒索信品牌。通过加密文件尾部结构、文件名随机化方式、ESXi 端命令特征与二进制指纹确认是否为 DragonForce 系载荷,并区分是自研版本还是早期 LockBit 3.0 构建器版本。测量分块加密的块大小与跳跃步长,标定 vmdk 与数据库文件中完好数据的分布,作为修复方案的输入。

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

    全面盘点备份与快照的实际可用性(不只看备份任务状态,要实际挂载验证),对核心虚拟机与数据库做抽样修复测试,评估文件名重建的可行路径与工作量。输出书面评估:每个业务系统走备份回滚、结构修复还是碎片恢复,可预期恢复比例区间、所需时间与恢复顺序,并同步给出数据外泄范围的初步结论供合规决策。

  4. 数据恢复实施

    在干净环境与镜像上作业,原数据存储保持只读。ESXi 场景优先修复虚拟磁盘结构并挂载提取数据,把结果落到新建的干净存储再重建虚拟机;数据库走页级抽取 + 事务日志补齐;文件系统数据在提取后执行文件名与目录结构重建。恢复顺序按业务影响排:身份与网络基础设施 → 核心生产与财务系统 → 协同与归档。每批完成后做完整性校验与业务抽验。

  5. 溯源加固与验收

    还原完整攻击链,重点核查三类入口:边界设备是否存在未修补漏洞、服务台是否发生过被冒充的密码或 MFA 重置、RMM/远程运维平台是否被用作投放通道。加固措施:边界设备补丁与配置基线、服务台身份核验流程(回拨、二次验证)、RMM 平台账号隔离与操作审计、ESXi 管理网隔离与锁定模式、全域凭据重置与强 MFA、备份重建为 3-2-1 并具备不可变副本与独立凭据。最后出具事件报告、外泄范围结论与验收清单。

风险提示

中招后切勿操作

  • 不要重新初始化 ESXi 数据存储、不要在原 LUN 上新建虚拟机、不要扩容或重建存储池——这会让虚拟磁盘的结构化修复与碎片恢复同时失去可能。
  • 不要下载使用任何声称能解密 DragonForce 的工具;公开渠道不存在有效解密器,这类程序多为二次勒索或窃密载荷。
  • 不要仅凭勒索信上的品牌名判断家族。卡特尔白牌模式下,陌生品牌可能使用的是同一套 DragonForce 加密器,误判会直接导致恢复方案选错。
  • 不要急于恢复 RMM / 远程运维平台的下发功能,也不要用原有管理凭据重新接入——攻击者常保留这条通道用于二次投放。
  • 不要把备份介质或备份服务器接回未清理的网络;DragonForce 会主动搜索并加密可直连的备份存储。
  • 不要在未界定外泄范围前对外发布口径,也不要私下联系攻击者谈判;数据已外传的事实不会因付款而消除。

紧急响应

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

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

相关场景方案

相关行业方案

相似勒索家族

常见问题

DragonForce 常见问题

  • DragonForce 加密的文件有解密工具吗?

    没有。DragonForce 的加密器由泄露的 LockBit 3.0 构建器和 Conti v3 源码改造而来,采用 ChaCha8 加密文件内容、RSA-4096 保护密钥,目前没有公开的实现缺陷可利用,也没有任何可信的免费解密工具。网上出现的「DragonForce 解密器」应一律视为恶意程序。现实的 DragonForce 数据恢复路径是备份与快照、虚拟磁盘与数据库结构修复、未加密副本与底层碎片提取。

  • 勒索信上不是 DragonForce 的名字,为什么你们说是 DragonForce?

    因为 2025 年 3 月起 DragonForce 转型为卡特尔,通过 RansomBay 向附属团伙提供白牌服务:附属可以用自己的品牌、自己的泄露站运营,但加密器和基础设施是 DragonForce 的。所以品牌名不具备识别价值,判定要靠加密文件尾部结构、文件名随机化方式、ESXi 端命令特征与二进制指纹。识别准确与否直接影响恢复方案,这也是我们坚持先做样本分析的原因。

  • 文件名全变成乱码了,恢复出来还能对得上吗?

    可以,但需要额外工序。DragonForce 自研加密器会把原文件名整体替换为随机字符串,加密文件本身不保留原名。重建路径包括:备份系统的文件索引与目录清单、数据库内部的表结构与元数据、文档内嵌属性(作者、标题、创建时间)、内容指纹与业务编号匹配,以及与上下游系统的交叉比对。这部分工作量常被低估,我们会在方案评估阶段单独列出所需时间。

  • 我们的 ESXi 宿主还能正常启动,是不是问题不大?

    不是。DragonForce 的 ESXi 加密器带有系统目录与文件白名单,故意保住宿主可引导,只加密 /vmfs/volumes 下的虚拟机文件,这样受害者仍能登录管理界面看到勒索信、维持谈判通道。宿主能启动不代表损失小,实际情况通常是其上全部虚拟机无法开机。此时最关键的是立刻停止对数据存储的写入,不要重新初始化、不要新建虚拟机,先确认快照与备份状态。

  • 攻击者是通过电话冒充 IT 进来的,这种入侵还能查出来吗?

    能,但取证重点和传统入侵不同。社工型初始访问在终端上往往没有恶意程序痕迹,线索主要在:服务台工单与通话记录、密码与 MFA 重置的操作日志、身份平台的设备注册与登录地理特征、VPN 会话与异常时间段登录、以及首次出现的可疑管理操作。我们会把这些与后续横向移动痕迹串联成完整时间线,既用于定位入口,也用于界定数据外泄范围与合规上报依据。