跳转到主要内容

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

舍末无勒SheMo Noransom

勒索病毒家族

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

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

Payload 是 2026 年 2 月出现的新兴双重勒索家族，基于泄露的 Babuk 源码改写，以 .payload 后缀和 RECOVER_payload.txt 勒索信为标志，同时提供 Windows 与 ESXi 加密器，目前没有公开解密工具。

首次出现
2026-02
加密后缀
.payload
勒索信文件
RECOVER_payload.txt
受影响平台
Windows / Linux / VMware ESXi

家族档案

加密后缀
  • .payload
勒索信文件
  • RECOVER_payload.txt
  • RECOVERY-xx0001.txt
联系方式模式
  • Tor (.onion) 谈判门户「Payload Rescue」+ 受害者专属账号口令
  • Tor (.onion) 泄露博客（发布文件树与倒计时）
  • 勒索信内嵌的 onion 地址（样本中以 RC4 加密存放）
  • 不使用邮箱、TOX 或即时通讯联系
别名 / 版本
Payload Ransomware、Payload Rescue（谈判 / 泄露门户品牌）、Babuk 衍生加密器（部分引擎归类为 Babuk）
首次出现
2026-02
活跃状态
活跃中
运营状态
新近出现
威胁等级
高危
受影响平台
  • Windows
  • Linux
  • VMware ESXi
标签
  • 近期冒头
  • 活跃中
  • 双重勒索
  • 针对虚拟化
解密工具
暂无公开解密工具

目前没有针对 Payload 的公开免费解密工具，No More Ransom 与各厂商均未收录。

多份独立逆向分析给出的结论一致：加密器采用 Curve25519 ECDH 协商 + ChaCha20 的组合，每个文件独立生成密钥对与随机数，密钥材料通过 CryptGenRandom 产生，加密结果写入一个 56 字节的 RC4 混淆尾部。研究者未发现随机数熵不足、密钥复用或尾部结构可逆等可利用缺陷，因此不存在类似 Rhysida、早期 Babuk 那样「靠实现缺陷破解」的路径。

需要提醒的是：Payload 的代码源自 2021 年泄露的 Babuk 源码，但这不意味着公开的 Babuk 解密器可用——Babuk 解密器依赖当年一并泄露的私钥，而 Payload 使用的是自己的全新密钥对。把 Babuk 工具套在 .payload 文件上只会造成二次损坏。

因此，Payload 的处置重点不在「找解密器」，而在评估备份、快照、对实际样本实测加密覆盖范围后所确认的修复空间，以及数据外泄影响。若后续出现执法行动缴获密钥或公开工具，我们会重新评估。

最新动态

  1. 泄露站追踪显示 Payload 仍在持续投放：8 月 20 日新增瑞士数据中心服务商等受害者，累计公布受害组织约 75 家、覆盖 36 个国家，第二季度环比增长约五成。

    参考来源

  2. Payload 将南非工程咨询公司 CKR Consulting Engineers 列入泄露站，声称窃取 55 GB 内部数据；该公司参与过多个大型基础设施与数据中心项目，事后未公开确认该事件。

    参考来源

  3. Payload 在其暗网泄露站公布对巴林 Royal Bahrain Hospital 的攻击，声称窃取约 110 GB 内部数据，是该团伙出现后影响最大的医疗行业案例。

    参考来源

家族概述

Payload 于 2026 年 2 月 17 日首次公开出现，同期即有 Windows 加密器样本与泄露站受害者条目。360 数字安全在 2026 年 2 月的勒索软件流行态势月报中，将其列为当月全球新增的双重勒索家族之一。

加密器构建在 2021 年 9 月泄露的 Babuk 源码之上，部分引擎因此可能把样本归类为 Babuk，但泄露站、谈判门户与运营品牌均属全新。现有研究倾向认为它并非 RaaS，规模更接近单一操作者或小型封闭团队。至 2026 年 9 月初，第三方泄露站追踪累计列出 70 余家受害组织、覆盖 30 多个国家，行业分布以制造业居首；可查到的最新一条泄露站条目发布于 2026 年 8 月 20 日，此后约三周未见新增，但其泄露站与谈判站点仍可访问。

需如实说明：该家族的公开信息仍然有限——只有少数逆向分析与泄露站统计，尚无执法机构或一线厂商通告，入侵路径缺乏公开的事件响应报告。也没有报告确认其对中国大陆企业的定向攻击，但机会型打法意味着中资企业的海外分支同样处在其打击面内。

如何识别

后缀与勒索信：加密文件在原名之后追加 .payload（report.xlsx 变为 report.xlsx.payload），文件名主体不改写。主要勒索信为 RECOVER_payload.txt，常见于 C:\ 根目录与各加密目录，另有 RECOVERY-xx0001.txt 变体；信中要求 72 小时内取得联系、给出 240 小时谈判窗口，不留邮箱，只能通过 Tor 门户以专属口令登录。ESXi 加密器的后缀未被公开分析一致确认，可能与 Windows 端不同。

样本层特征（可用于与其他 Babuk 衍生锁定器区分）：

  • 互斥量名称为 MakeAmericaGreatAgain；
  • 每个加密文件尾部追加 56 字节结构，以静态 RC4 密钥混淆，内含受害者公钥与随机数；
  • 加密器把自身改名为 NTFS 备用数据流（追加 :payload）并标记待删除，从普通目录列表中隐身。

判定要点：.payload 后缀 + RECOVER_payload.txt 基本可锁定家族。但由于代码同源，部分杀毒引擎可能将其标记为 Babuk，不要据此去找 Babuk 解密器——两者密钥体系不同。请保留 3–5 个加密文件与勒索信原件供版本判定。

传播与入侵方式

必须如实说明：Payload 的初始入侵路径目前没有公开归因。截至 2026 年 9 月，尚无厂商或应急机构公布其完整入侵链与事件响应报告，现有资料只覆盖「加密之后」的部分。

可参考的间接线索有两点：第三方泄露站追踪显示，其列出的受害组织中约四成能在信息窃取木马日志中找到对应的凭据暴露记录（相关性而非因果）；ESXi 加密器专门解析 vmInventory.xml 枚举虚拟机磁盘，说明攻击者预期能取得宿主管理权限或 SSH 访问。

在入侵路径明确之前，务实做法是按高可能性通用入口收口：远程访问与 VPN 强制多因素认证、边界设备及时修补、虚拟化管理口与办公网隔离并关闭不必要的 SSH、域管理员凭据分层、对终端信息窃取木马做专项排查与凭据轮换。这些措施不依赖家族级归因，也覆盖同期大量新兴团伙。

加密特点

算法：Curve25519 ECDH + ChaCha20 的混合方案。对每个文件单独生成 32 字节临时私钥与 12 字节随机数，协商出的对称密钥不经派生函数直接用于 ChaCha20，密钥材料使用后从内存清除；文件尾部 56 字节结构以静态 RC4 密钥混淆，保存受害者公钥与随机数，供攻击者事后解密。逆向分析未发现可利用的密码学缺陷。

加密覆盖范围（公开分析存在分歧，必须实测）：各方一致的是加密按 1 MB 分块进行。但覆盖比例说法不一——有分析描述大文件采用「文件大小 / 5」的部分加密策略，另有分析则描述为整个文件顺序加密后再写入尾部。两种情形对恢复的含义完全相反：若实测确认为部分加密，数据库文件、虚拟磁盘与邮件库可能仍保留大量未被覆盖的原始区块，为结构级修复留出空间；若为全文件加密，则这条路径并不成立。因此必须对实际样本逐个测量加密偏移，不能按任何比例想当然；即便确认为部分加密，可修复程度仍取决于页头、元数据、分区表等关键结构是否恰好落在被加密区段。

反取证与破坏恢复能力：执行 vssadmin 删除全部卷影；经 wevtapi 清空事件日志；在内存中对 ETW 打补丁以致盲遥测；批量停止 40 余个服务，其中明确包含 SQL 数据库、Veeam 备份与多家终端防护产品。这意味着现场证据消失得很快，越早保全镜像越有价值。

虚拟化与双重勒索：Linux/ESXi 加密器是约 39 KB 的精简 ELF，专为 VMware ESXi 环境编写，借助 libxml2 解析 /etc/vmware/hostd/vmInventory.xml，枚举虚拟机磁盘路径后加密——一台宿主被打穿即等于其上全部虚拟机同时停摆。有分析指出该 ELF 并不具备 Windows 端那样完整的反恢复功能，因此宿主侧的日志与快照未必同样被清理，值得优先排查。数据先外传后加密，泄露站发布文件树与倒计时，未付款则分批公开。

先评估，再动手

可恢复性评估

Payload勒索病毒解密的可行性必须逐样本判断。我们不支付赎金、不代为谈判，只做技术恢复与取证。按优先级：

1）公开解密器：目前不存在。 加密方案未发现可利用缺陷，Babuk 的公开解密器也不适用（密钥对不同）。任何号称能解 .payload 的第三方工具，都须先在隔离副本上验证来源与效果，切勿直接对原盘运行。

2）加密覆盖范围决定的修复空间（须先实测）。 公开分析对 Payload 是否只加密大文件的一部分存在分歧，因此这条路径是否成立，必须先在实际样本上测量加密偏移，不能预设。若实测显示大文件仅被部分覆盖，数据库文件（MDF/LDF、DBF、ibd）、虚拟磁盘（vmdk/vhdx）与邮件库可能保留大量完好区块：可对数据库尝试页级抽取与逻辑重建，对虚拟磁盘先修复分区表与文件系统元数据再挂载提取。若实测显示整个文件被加密，则应直接转向备份、快照与未加密副本。恢复比例从零到相当高都有可能，先评估再界定范围。

3）备份、快照与卷影。 卷影几乎必被删除，但离线与异地备份、存储阵列或 NAS 卷快照、虚拟化平台快照、备份服务器上未被触达的副本、云端历史版本仍值得逐一核查。其服务终止清单明确包含 Veeam，务必先确认备份链路是否已被接触，切勿把备份介质接回尚未清理的网络。

4）未加密副本与日志回放。 文件服务器回收站、终端缓存、报表与 BI 中间库、ERP 归档导出、数据库事务日志与业务操作日志，都可能支撑关键数据的重建或时点回放。

5）底层碎片恢复。 部分落盘方式会在未分配簇留下原始数据，可做原始扇区扫描提取，前提是第一时间停止对受影响卷的写入。

6）数据外泄影响评估。 即便文件全部恢复，外泄部分仍需独立处理：界定外传范围与时间线、评估通报义务、轮换账号密钥与客户凭据。

关于 Payload 数据恢复，我们提供的是可验证的评估结论与明确的恢复范围，不承诺「全部解密」，也不存在能确保数据完整复原的技术路径。

我们的处置方案

中了 Payload 勒索病毒怎么办？

  1. 隔离与取证固定

    断开受影响主机与 ESXi 宿主的业务网络与存储链路，不要重启、不要关机。Payload 会清空事件日志、内存打补丁致盲 ETW 并把自身移入 NTFS 备用数据流，现场证据消失极快，越早保全越有价值。优先对域控、备份服务器、虚拟化管理机做磁盘镜像或快照，导出边界设备、VPN 与 AD 日志（若本地日志已被清空，以网络侧与集中日志平台为准），并保留 3–5 个 .payload 文件与 RECOVER_payload.txt 原件。

  2. 家族识别与加密分析

    以后缀、勒索信结构、56 字节 RC4 尾部与互斥量特征确认为 Payload，并区分 Windows 加密器与 ESXi 加密器。特别注意排除「引擎误报为 Babuk 而误用 Babuk 解密器」的风险。同时实测加密的块大小与实际覆盖范围——公开分析对「是否只加密大文件的一部分」说法不一，必须以样本实测为准，这一步直接决定关键数据库与虚拟磁盘走结构修复还是走备份回滚。

  3. 可恢复性与外泄影响评估

    盘点备份、存储快照、虚拟化快照与未加密副本，重点核实备份链路是否已被攻击者接触（其服务终止清单明确包含 Veeam）。对关键数据库与虚拟机做抽样修复测试，量化可恢复比例区间。同步评估数据外泄：从流量与日志中界定外传时间窗与量级，对照泄露站公示内容判断影响面。输出书面评估，说明哪些系统走结构修复、哪些走备份回滚、哪些走碎片恢复，以及预期时间与业务恢复优先级。

  4. 恢复实施与业务验收

    全程在镜像或副本上作业，原盘保持只读。按业务优先级恢复：先身份与域基础设施，再 ERP/MES 等核心数据库，最后是文件与邮件系统。ESXi 场景下优先修复 vmdk 结构并挂载提取内部数据，不要重新初始化数据存储、不要在原 LUN 上新建虚拟机。每恢复一批即做完整性校验与业务侧抽验（对账、报表比对、应用启动测试），形成可追溯的恢复清单。

  5. 溯源加固与验收

    由于 Payload 的入侵路径尚无公开归因，溯源需从暴露面反推：核查远程访问与 VPN 是否缺少多因素认证、边界设备是否存在未修补漏洞、虚拟化管理网是否可从办公网直达、域内是否存在信息窃取木马导致的凭据泄露。清除新增账号、计划任务与备用数据流残留，重置全域凭据，隔离 ESXi 管理网并关闭不必要的 SSH，重建符合 3-2-1 且具备不可变副本的备份体系，最后出具事件报告与验收清单。

风险提示

中招后切勿操作

  • 不要重启或关机受影响主机与 ESXi 宿主——内存中的进程、连接与残留痕迹一旦丢失，取证与外泄范围界定会同时失去依据。
  • 不要因为杀毒软件把样本报成 Babuk 就去跑 Babuk 解密器；两者密钥体系不同，错误工具会造成文件二次损坏。
  • 不要下载来路不明的「.payload 解密工具」在原盘上试跑；目前没有公开免费解密器，任何验证都必须在隔离副本上进行。
  • 不要删除 RECOVER_payload.txt 与加密样本，也不要急于「杀毒清理」——它们是版本判定与恢复可行性评估的唯一依据。
  • 不要格式化、重装系统或重建 RAID 与存储池；对 ESXi 不要重新初始化数据存储，这会让结构修复与碎片恢复彻底失去机会。
  • 不要自行登录勒索信中的 Tor 门户谈判或支付赎金；付款既不必然换来可用密钥，也不能阻止已外传数据被公开或转售。

紧急响应

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

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

15639272850查看联系方式

相关场景方案

相关行业方案

相似勒索家族

常见问题

Payload 常见问题

  • .payload 后缀的文件能解密吗？

    目前没有公开免费解密工具。Payload 使用 Curve25519 协商 + ChaCha20 加密，每个文件独立生成密钥，逆向分析未发现可利用的实现缺陷，因此不存在「靠漏洞破解」的路径。现实的恢复方向是：备份与各层快照、实测加密覆盖范围后可能留下的数据库与虚拟磁盘修复空间（公开分析对覆盖比例说法不一，须以样本实测为准）、未加密副本与日志回放、以及底层碎片恢复。我们会先用真实样本做评估，再给出可验证的恢复范围，而不是先承诺结果。

  • 杀毒软件把样本报成 Babuk，用 Babuk 的免费解密器行不行？

    不行，这是最常见也最危险的误判。Payload 确实基于 2021 年泄露的 Babuk 源码改写，引擎因此产生误报；但公开的 Babuk 解密器依赖当年一并泄露的私钥，而 Payload 使用的是自己的全新密钥对，二者不通用。把 Babuk 工具套在 .payload 文件上，轻则无效，重则破坏文件尾部结构，使后续的结构级修复也一并失效。任何工具在使用前都必须先在隔离副本上验证。

  • ESXi 上的虚拟机被 Payload 加密了，还有救吗？

    有评估空间。Payload 的 Linux 加密器会解析 vmInventory.xml 枚举全部虚拟机磁盘，一台宿主被打穿即全部虚拟机停摆。处置顺序是：先确认数据存储快照、存储阵列或 NAS 侧卷快照、备份平台的虚拟机级备份是否可用；若都没有，再实测 vmdk 的加密覆盖范围（公开分析对大文件是否只被部分加密说法不一），据此判断能否做结构级修复——修复分区表与文件系统元数据后挂载提取内部文件，可恢复比例取决于关键结构是否被覆盖。关键是不要重新初始化数据存储，也不要在原 LUN 上新建虚拟机。

  • 看到 RECOVER_payload.txt，第一个小时该做什么？

    四件事。一、断网隔离：切断业务网与存储链路、封停远程访问账号，但不要关机重启。二、保护现场：优先对域控、备份服务器与 ESXi 管理机做镜像或快照；Payload 会清空事件日志并致盲 ETW，本地日志很可能已不可信，应同时导出网络侧与集中日志平台的记录。三、保留 3–5 个 .payload 文件与勒索信原件。四、确认备份是否还在、是否已被接触（其服务终止清单明确包含 Veeam），在确认干净前不要把备份介质接回网络。我们提供 24 小时应急响应。

  • Payload 会公开我们的数据吗？付款能让它撤下来吗？

    Payload 是双重勒索家族，加密前已外传数据，勒索信给出 72 小时联系期限与 240 小时谈判窗口，逾期在泄露站分批公开文件树与数据。付款并不能真正消除风险：数据副本仍在对方手中，可能被转售或被其他团伙复用于二次勒索。我们不支付赎金、不代为谈判。更有价值的动作是尽快界定外传时间窗与数据范围，据此完成内部通报与监管、合同层面的合规处置，并对涉及的账号、密钥与客户信息做轮换与告知。

参考来源

外部链接仅供参考，内容由第三方发布，不代表本站立场。

更新于