跳转到主要内容

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

舍末无勒SheMo Noransom

勒索病毒家族

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

  • 已停止活动
  • 高危
  • 部分版本可解

Conti 是 2020–2022 年全球破坏力最强的勒索软件即服务团伙之一,由 Wizard Spider(TrickBot 团伙)运营,累计受害单位超千家、赎金逾 1.5 亿美元;2022 年内部聊天与源码遭泄露后品牌解散,人员分流至 Black Basta、Royal、Akira 等后继组织。

首次出现
2019-12
加密后缀
.CONTI .[5位随机大写字母] .[5位随机大小写字母数字]
勒索信文件
CONTI_README.txt
受影响平台
Windows / Linux / VMware ESXi

家族档案

加密后缀
  • .CONTI
  • .[5位随机大写字母]
  • .[5位随机大小写字母数字]
  • .KREMLIN
  • .RUSSIA
  • .PUTIN
勒索信文件
  • CONTI_README.txt
  • readme.txt
  • R3ADM3.txt
  • CONTI.txt
联系方式模式
  • 勒索信中直接给出的 Tor (.onion) 一对一谈判门户链接
  • Tor 泄露站「Conti News」及其 clearnet 镜像域名(均已于 2022 年下线)
  • 早期版本在勒索信中留下的境外加密邮箱地址
  • 仅接受比特币(BTC),按受害者生成收款地址
  • 源码泄露后的衍生变种改用自建 .onion 站点或自有邮箱,与原团伙无关
别名 / 版本
Conti Ransomware、Conti v2、Conti v3、Wizard Spider(运营团伙,亦称 GOLD BLACKBURN / FIN12 / DEV-0193)、Conti News(暗网泄露站)、MeowCorp(源码泄露衍生变种)
首次出现
2019-12
活跃状态
已停止活动
运营状态
已停止运营
威胁等级
高危
受影响平台
  • Windows
  • Linux
  • VMware ESXi
标签
  • 已停止
  • 老旧家族
  • 勒索即服务
  • 双重勒索
  • 针对虚拟化
  • 钓鱼邮件
  • RDP 爆破
  • 漏洞利用
解密工具
部分版本可解

原版 Conti 没有公开免费解密工具。加密器用受害者专属 RSA-4096 公钥封装每个文件的对称密钥;2022 年 2 月 27 日泄露的是内部聊天记录、3 月初泄露的是加密器源码与管理后台,都不包含运营者手中的 RSA 私钥,因此无法据此还原任何真实案例的密钥。No More Ransom 的解密工具清单至今也未收录 Conti。

例外只有一类:源码泄露后由第三方改造的衍生变种 MeowCorp(加密后缀为 .KREMLIN、.RUSSIA、.PUTIN)。2023 年初有人在俄语论坛公开了该变种的 258 把私钥,卡巴斯基随后将其并入 RakhniDecryptor 免费工具,可覆盖约 257 名该变种受害者。它只对这一支变种有效,对原版 Conti、对其他源码衍生变种一概无效。

此外,部分低水平仿制者在编译衍生变种时把密钥硬编码或遗留在本地,这类个案有逐一分析后自研解密程序的可能,但必须以真实样本逆向结论为准,不能按后缀想当然。任何声称「能解 Conti」的工具,都应先在隔离环境用您自己的副本做可验证试跑。

参考来源

最新动态

  1. 美国法院判处乌克兰籍 Conti 成员 Oleksii Lytvynenko 4 年监禁(最高刑期 20 年)。他自 2021 年 9 月起参与 Conti,开发加载器、经手至少 12 家受害单位的窃取数据并发送勒索信,2023 年 7 月在爱尔兰被捕后引渡受审。

    参考来源
  2. 同一名乌克兰籍 Conti 成员在美国认罪,承认共谋实施电信欺诈。美国司法部在通报中给出 Conti 的总体规模:全球受害单位逾 1000 家,累计勒索金额超过 1.5 亿美元。

    参考来源

家族概述

Conti 最早于 2019 年 12 月被记录,2020 年起大规模使用,技术上脱胎于 Ryuk,由俄语背景的 Wizard Spider(TrickBot 团伙)以勒索软件即服务模式运营:核心团队维护加密器、谈判门户与「Conti News」泄露站,附属成员负责入侵投放并分成。

2021 年 5 月 14 日的攻击迫使爱尔兰国家医疗服务体系(HSE)关停全国 IT 系统,到当年 9 月才恢复约 95% 的服务器与终端;同年 9 月 CISA、FBI 与 NSA 发布联合通告 AA21-265A,初版记录 400 余起攻击,2022 年 2 月更新时升至 1000 余起;2022 年 4 月 17 日起对哥斯达黎加多个政府机构的攻击,促使该国于 5 月 8 日宣布进入全国紧急状态。

转折点是 2022 年 2 月 27 日:Conti 公开声援俄罗斯后,一名乌克兰研究者放出其 Jabber 后台 6 万余条内部聊天(约 60,694 条),数日后加密器源码与管理后台也被公开,史称 ContiLeaks。同年 5 月美国国务院发布悬赏——针对头目身份与位置最高 1000 万美元,针对参与者的抓捕与定罪最高 500 万美元;5 月 19 日谈判与管理后台关停,泄露站与谈判站于 6 月 23 日整体下线。FBI 估算截至 2022 年 1 月,相关受害者逾千家、已支付赎金逾 1.5 亿美元。

品牌消失但人没散:公开研究将 HelloKitty、AvosLocker、Hive、BlackCat、BlackByte、Karakurt 与 Conti 的人员或基础设施关联,Black Basta 与 Royal/BlackSuit 亦被普遍认为承接了 Conti 的班底;Arctic Wolf 在 2023 年 7 月以赎金资金流向与代码相似度为据,高置信度地将 Akira 与 Conti 附属成员关联。执法仍在推进:2025 年 5 月德国联邦刑警点名该体系头目「Stern」为 Vitaly Nikolaevich Kovalev;2026 年 9 月 11 日,乌克兰籍成员 Oleksii Lytvynenko 因参与 Conti 攻击在美被判 4 年监禁(他 2023 年 7 月在爱尔兰科克被捕,2026 年 6 月认罪)。Conti 今天的意义是「遗产」——手法被后继团伙完整继承,源码仍在滋生新变种,2021—2022 年封存的旧数据仍等待处置结论。

如何识别

后缀:早期版本追加 .CONTI;2021 年起改为随机 5 位大写字母(如 .RHMLM、.UAKXC);2022 年 1 月起进一步改为 5 位大小写混合的字母数字(如 .ZG7Ak、.wjzPe),以绕开只匹配全大写模式的检测规则。「后缀看上去像一串随机字符」恰恰是 Conti 的典型特征,不能据此排除。

勒索信:加密后在各目录留下 CONTI_README.txt、readme.txt、R3ADM3.txt 或 CONTI.txt,英文内容声称已窃取数据并给出 Tor 谈判门户链接,早期版本另列加密邮箱地址;一般不改写桌面壁纸。

衍生变种:.KREMLIN、.RUSSIA、.PUTIN 属于源码泄露后的第三方改造版 MeowCorp,不是原团伙所为,却是目前唯一有公开解密工具的一支。

判定要点:2022 年 6 月之后出现的「Conti」,绝大多数是源码衍生变种,或被误标的后继家族(Black Basta、Royal、Akira 的模式各不相同)。必须取 3–5 个加密文件、勒索信原件与相关日志做样本级判定。

传播与入侵方式

Conti 的入口组合在 2021—2022 年被整个勒索生态复制,至今仍是国内企业最常见的失陷路径:

  • 钓鱼邮件投递加载器:恶意文档或链接先落地 TrickBot、BazarLoader 或 IcedID,再拉起 Cobalt Strike;2021 年起 BazarLoader / BazarBackdoor 逐步取代 TrickBot 成为主要投递通道。
  • 被窃或弱口令的 RDP 账号:直接用合法凭据登录,无需漏洞。CISA 通告把它与钓鱼并列为两大主要入口。
  • 公网服务漏洞:ProxyShell 系列 Exchange 漏洞(CVE-2021-34473 / 34523 / 31207,Sophos 有完整入侵记录)、FortiGate 的 CVE-2018-13379 与 CVE-2018-13374。
  • 横向移动与提权:Mimikatz、ProcDump 抓取 lsass 凭据,Zerologon(CVE-2020-1472)、PrintNightmare(CVE-2021-34527)提权,PsExec、MS17-010 与 AnyDesk / Atera / Splashtop / Remote Utilities 等商用远控铺开。Log4Shell(CVE-2021-44228)在 Conti 手里是内网横向手段而非初始入口——2021 年 12 月有情报厂商记录其在已失陷网络中用它打 VMware vCenter。
  • 窃密外传:加密前用 Rclone 把数据同步到 Mega 等云盘。

The DFIR Report 记录的一起真实入侵中,从初始感染到全域投放仅约 5 天,加密器由备份服务器上的批处理脚本统一推送到全部域内主机——先打备份、再打全网,是 Conti 系团伙的固定套路。

加密特点

算法与速度:2020 年的早期样本中同时出现 AES-256 与 ChaCha 变体的痕迹,2021 年初仍有厂商按 AES-256 记录;2022 年 1 月的更新版本已确认为「每文件一把 256 位 ChaCha 对称密钥」。无论哪一版,文件密钥都以受害者专属 RSA-4096 公钥封装,私钥从不落地。加密器通过 I/O 完成端口起最多 32 个并发工作线程,属最快一档——从发现异常到全盘被覆盖,窗口常常只有几十分钟。

加密范围可调:加密器接受命令行参数,The DFIR Report 记录的实际投放命令为 -m -net -size 10 -nomutex -p \\主机名\C$,其中 -size 10 表示按比例只加密文件的一部分;更新版本还增加了 -safeboot / -disablesafeboot 等开关。是否部分加密取决于投放参数,不能默认所有文件都只被部分覆盖,必须实测。

恢复抑制:通过 vssadmin / WMI 删除卷影,停止最多 146 项安全、备份、数据库与邮件相关服务,并用 Windows 重启管理器释放文件句柄,使运行中的数据库文件也能被加密;2022 年 1 月起的版本还可重启进入带网络的安全模式以规避安全软件。

横向与虚拟化:沿同网段 SMB 445 端口连接其他主机并加密可写共享;公开研究亦记录了针对 VMware ESXi 宿主的 Linux 变种,可直接加密宿主上的虚拟机文件。数据在加密前已被外传,未付款则在 Conti News 分批公开。

先评估,再动手

可恢复性评估

Conti 的恢复评估有一个别家没有的前提:这个团伙已经不存在了。泄露站 2022 年下线、谈判门户失效,即便想付款也找不到对手方;现在自称「Conti 官方客服」「代购密钥」的基本都是二次诈骗。我们不支付赎金、不代谈判,只做技术恢复与取证。

1)公开解密器(仅限一支变种):卡巴斯基 RakhniDecryptor 覆盖源码衍生变种 MeowCorp(.KREMLIN / .RUSSIA / .PUTIN),基于 2023 年公开的 258 把私钥;原版 Conti 无解密器——源码泄露不等于密钥泄露。

2)部分加密带来的修复空间:若投放时用了 -size 类参数,数据库文件、虚拟磁盘与邮件库可能保留大量未覆盖区块,可尝试页级抽取与逻辑重建;但 Conti 同样常做全量加密,须先测量实际覆盖模式。

3)备份、快照与卷影:卷影通常已被删除,但离线与异地备份、存储层快照、虚拟化快照与云端版本历史仍是恢复比例最高的路径;Conti 惯常先破坏备份系统,务必核实介质完好。

4)未加密副本与日志回放:回收站、终端缓存、BI 中间库、ERP 归档导出与数据库事务日志都可能支撑数据重建;陈年案件还应排查异地分支与合作方手中的历史副本。

5)底层碎片恢复:部分投放「新建加密文件 + 删除原文件」,原始数据可能仍留在未分配簇中,前提是原盘此后没有被大量写入——封存多年的离线磁盘反而最有希望。

我们给出的是可验证的评估结论与明确的恢复范围。

我们的处置方案

中了 Conti 勒索病毒怎么办?

  1. 隔离与取证固定

    对仍在发生的加密,先断开受影响主机、ESXi 宿主与存储链路,不要重启、不要关机;Conti 系工具链常留有 Cobalt Strike、AnyDesk、Atera 等驻留。优先对域控、备份服务器与虚拟化管理机做磁盘镜像或快照,导出边界设备、VPN、Exchange 与 AD 日志,并保留 3–5 个加密文件与勒索信原件。对 2021—2022 年的陈年案件,重点是确认原盘是否被写入过、离线介质是否仍在。

  2. 家族识别与变种判定

    用后缀模式、勒索信结构、文件尾部标记与样本逆向确认是原版 Conti、源码泄露衍生变种(如 MeowCorp),还是后继家族(Black Basta、Royal、Akira)被误标为 Conti——三者的恢复路径完全不同。同时逆向确认加密算法(AES-256 或 ChaCha20)与投放参数,判断是否存在密钥硬编码或本地残留的低水平实现。

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

    在隔离环境中测量实际加密覆盖模式(全量还是按比例),对关键数据库与虚拟磁盘做抽样修复测试;若判定为 MeowCorp 变种,用真实样本试跑 RakhniDecryptor 验证。同步盘点备份、存储快照、虚拟化快照与未加密副本,核实备份介质是否被破坏。输出书面评估:哪些系统走解密、哪些走数据库页级重建、哪些走备份回滚或碎片恢复,给出可预期恢复比例区间、所需时间与业务恢复优先级,经确认后再动手。

  4. 恢复实施与数据处置

    全程在镜像或副本上作业,原盘只读。按业务优先级恢复:先域控与身份体系,再 ERP/MES 等核心数据库,最后是文件与邮件系统;ESXi 场景优先修复虚拟磁盘结构并挂载提取内部数据,而非覆盖原数据存储。每恢复一批即做完整性校验与业务侧抽验(对账、报表比对、应用启动测试)。同时评估数据外传影响——Conti 的泄露站虽已下线,早年被公开的数据仍可能在镜像站与情报社区流转,需据此判断通报义务与凭据轮换范围。

  5. 溯源加固与验收

    还原完整攻击链:入口是钓鱼加载器、被窃 RDP 凭据还是未修补的 Exchange/FortiGate 漏洞,域管理员凭据在何处泄露,备份系统是何时被打掉的。清除远控工具、新增账号、计划任务与 GPO 后门,全域重置凭据并强制 VPN/RDP 多因素认证,隔离 ESXi 管理网并关闭对外 SSH,补齐边界设备补丁,重建符合 3-2-1 且具备不可变副本的备份体系。最后出具事件报告与验收清单——由于 Conti 手法已被后继团伙完整继承,这一步的加固结论对防御 Black Basta、Akira 等同样有效。

风险提示

中招后切勿操作

  • 不要相信任何自称 Conti「官方客服」或「能代购密钥」的联系方式——该团伙 2022 年已解散、谈判门户早已失效,现在出现的一律按二次诈骗处理。
  • 不要在原盘上直接试跑网上下载的「Conti 解密工具」;除卡巴斯基 RakhniDecryptor 对 MeowCorp 变种有效外,绝大多数是伪造工具或二次投毒,试跑必须在副本上进行。
  • 不要重启或关机仍在加密的主机与 ESXi 宿主;也不要因为「事情过去很久了」就把封存的受害磁盘拿来重装或做其他用途,那会彻底断送碎片恢复的机会。
  • 不要删除勒索信(CONTI_README.txt、readme.txt 等)与加密样本,也不要急于清理「病毒文件」——它们是判定原版、衍生变种还是后继家族的唯一依据。
  • 不要在未确认备份介质完好前把备份服务器、磁带或移动硬盘接回网络;Conti 系攻击的标准动作就是先从备份服务器发起全域投放。
  • 不要仅凭随机后缀就自行断定是 Conti;2022 年 6 月之后的绝大多数案例其实是源码衍生变种或 Black Basta、Akira 等后继家族,误判会直接导致恢复方案选错。

紧急响应

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

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

相关场景方案

相关行业方案

相似勒索家族

常见问题

Conti 常见问题

  • .CONTI 后缀的文件还能解密吗?

    原版 Conti 没有公开解密工具。文件密钥由受害者专属 RSA-4096 公钥封装,2022 年泄露的是加密器源码而非私钥,因此不存在通用解密途径。唯一的例外是源码衍生变种 MeowCorp(后缀 .KREMLIN / .RUSSIA / .PUTIN),卡巴斯基 RakhniDecryptor 基于 258 把公开私钥可覆盖该变种的部分受害者。实际能否恢复,要靠备份、快照、部分加密下的数据库修复与碎片恢复等路径,需要先做样本级评估。

  • Conti 早就解散了,为什么我现在还会中招?

    通常是三种情况之一:一是 2022 年 3 月泄露的源码被第三方改造后重新投放,后缀和勒索信可能仍带 Conti 痕迹;二是实际作案的是 Conti 的后继团伙(Black Basta、Royal/BlackSuit、Akira 等),检测规则沿用旧家族名而被标成 Conti;三是纯粹的品牌冒用,攻击者借旧名字施压。这三种情况的恢复可行性差别很大,必须做样本级判定,不能按名字直接套方案。

  • 源码都泄露了,为什么不能自己写个解密器?

    因为泄露的是加密端代码,不包含运营者保管的 RSA 私钥。源码只让研究者看清算法实现和密钥封装流程,确认其中没有可利用的实现缺陷;没有私钥,ChaCha20/AES 的文件密钥就无法还原。真正可解的个案,是某些低水平仿制者在编译衍生变种时把密钥硬编码、或在受害主机上留下了密钥残留,这需要逐案逆向确认,不能一概而论。

  • 2022 年被加密、一直封存的老数据现在还有救吗?

    值得评估,而且封存本身是有利条件。密钥仍在攻击者手中,但恢复不止解密一条路:如果当时的投放使用了按比例部分加密,数据库与虚拟磁盘可能保留大量完好区块;离线备份、异地磁带、分支机构与合作方手里的历史副本常常还在;原盘封存后没有被写入,底层碎片恢复的成功率反而高于新案。建议先做一次不改动原盘的只读评估,再决定投入。

  • 被 Conti 加密的 ESXi 虚拟机怎么处理?

    公开研究记录了 Conti 的 Linux 变种,可直接加密 ESXi 宿主上的 vmdk、vmx 等文件,一台宿主被打穿就意味着其上全部业务系统停摆。处置要点:不要重新初始化数据存储、不要在原数据存储上创建新虚拟机;先对数据存储做整卷镜像,再在副本上尝试修复虚拟磁盘的分区表与文件系统结构、挂载后提取内部数据;同时检查存储层快照、备份软件中的虚拟机级副本与复制链路。恢复前务必确认管理网已隔离、SSH 已关闭,避免二次加密。