跳转到主要内容

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

舍末无勒SheMo Noransom

勒索病毒家族

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

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

JadePuffer 是 Sysdig 于 2026 年 7 月披露的首个有完整记录的「智能体勒索」行动：由大模型驱动的自动化代理从 Langflow 漏洞入口一路打到 Alibaba Nacos 配置中心，随后投放 Go 语言勒索载荷 ENCFORGE（.locked 后缀），专门加密 AI 模型权重与训练数据。

首次出现
2026-07
加密后缀
.locked
勒索信文件
README
受影响平台
Linux / 数据库

家族档案

加密后缀
  • .locked
勒索信文件
  • README
  • HOW_TO_DECRYPT
  • README_DECRYPT
联系方式模式
  • proton.me 匿名邮箱（用户名为 1 个字母 + 8 位数字），两轮攻击复用同一个地址
  • 第一轮勒索信内嵌比特币地址（3 开头的 P2SH 格式）；第二轮 ENCFORGE 勒索信只留邮箱，未见比特币地址
  • 数据库场景不落地文件：勒索信被写成名为 README_RANSOM 的数据表
  • 无暗网谈判门户、无 Tor 支付页面、无数据泄露站
别名 / 版本
JADEPUFFER、ENCFORGE、ENCFORGE 勒索病毒、encfile
首次出现
2026-07
活跃状态
活跃中
运营状态
新近出现
威胁等级
高危
受影响平台
  • Linux
  • 数据库
标签
  • 近期冒头
  • 活跃中
  • 漏洞利用
  • 针对数据库
解密工具
暂无公开解密工具

目前没有任何公开免费的 JadePuffer / ENCFORGE 解密工具，No More Ransom 与各厂商工具库均未收录。

两轮攻击的密钥处理方式不同，但结论一致：

  • 第一轮（Nacos 配置加密）：加密代理用 base64(uuid4().bytes + uuid4().bytes) 生成 AES 密钥，调用 MySQL 的 AES_ENCRYPT() 就地加密配置字段。Sysdig 分析指出该密钥只在被控环境内向标准输出打印过一次，既没有持久化也没有回传给攻击者。也就是说，即使支付赎金，攻击者自己也拿不出这把密钥。同一事件中勒索信内的比特币地址是比特币官方文档里的示例地址，进一步说明这条「支付—解密」链路根本不成立。
  • 第二轮（ENCFORGE 文件加密）：载荷用 AES-256-CTR 加密文件内容，再用编译进二进制的 RSA-2048 公钥封装会话密钥。没有私钥就无法逆推，也不存在离线密钥可用。

需要提醒的是，.locked 是被大量家族复用的通用后缀。网上标着「.locked 解密器」的工具针对的多半是别的家族，直接对 ENCFORGE 加密的文件运行只会造成二次损坏。任何恢复动作都必须先做样本级家族判定。

最新动态

  1. Sysdig 在智能体威胁检测综述中再次将 JadePuffer 列为首个自主执行破坏性数据库勒索的智能体行动，但未披露新受害者或新战术；截至 9 月该家族仍无泄露站与新增公开事件。

    参考来源

  2. Sysdig 披露 JadePuffer 第二轮攻击：同一 Langflow 入口，经 Docker socket 逃逸后投放 Go 语言载荷 ENCFORGE，覆盖约 180 种扩展名、专打 AI 模型权重与训练数据，加密后追加 .locked 后缀，二进制无数据外传能力，也未发现泄露站。

    参考来源

  3. Sysdig 威胁研究团队首次披露 JadePuffer，称其为首个有完整记录的智能体勒索行动：代理经 Langflow 漏洞 CVE-2025-3248 入侵，加密 Alibaba Nacos 的 1342 条服务配置并进一步删库，AES 密钥从未留存，付款也无法解密。

    参考来源

家族概述

JadePuffer 由 Sysdig 威胁研究团队于 2026 年 7 月 1 日公开，被描述为首个有完整记录的「智能体勒索」（agentic ransomware）行动：整条攻击链由大模型驱动的代理自动完成，依据是脚本中大量自然语言注释与登录失败后 31 秒内的自诊断修正。需注意命名口径：JadePuffer 是 Sysdig 给这一威胁行为体的代号（Malpedia 也按 actor 收录），加密载荷另有其名 ENCFORGE（项目代号 encfile），本页按国内习惯合并为一个家族条目呈现。

公开事件仅两起：第一起加密 Alibaba Nacos 的 1342 条服务配置后删库；第二起于 7 月 20 日披露，代理投放 Go 载荷 ENCFORGE，专打 AI 模型权重与训练数据，入口与勒索邮箱同前。

其打击面与国内常见的云原生与 AI 栈高度重合——Langflow、Nacos、MinIO、MySQL，侦察阶段还搜索阿里云、腾讯云、华为云凭据与 DeepSeek API Key。但这只是技术栈层面的重合，不等于国内高发：受害者地区与行业始终未披露，技术细节仅出自 Sysdig 一家，绿盟科技等中文报道均以其为源、未补充本地遥测，尚无可查的国内处置案例。截至 2026 年 9 月，7 月 20 日之后未见新的公开事件或厂商跟进报告。

如何识别

ENCFORGE 文件加密：文件改名追加 .locked，同目录出现 README、HOW_TO_DECRYPT、README_DECRYPT 三种英文勒索信，首行为「YOUR FILES HAVE BEEN ENCRYPTED」，自称「军用级加密」、密钥唯一，给出 7 天期限与一个 proton.me 邮箱。载荷覆盖约 180 种扩展名，明显偏向 AI 资产：.safetensors、.ckpt、.pt/.pth、.gguf、.onnx、.h5、.faiss、.parquet、.npy 等。被打的若是模型仓库与数据集目录而非办公文档，本身就是强指向。

数据库场景（第一轮）：无后缀、无勒索信文件。现象是 Nacos 配置全部变成密文、config_info 与历史表 his_config_info 被删，MySQL 里多出一张 README_RANSOM 表，内容以「YOUR DATA HAS BEEN ENCRYPTED」开头。

其他痕迹（均来自第一轮事件的公开分析，第二轮报告未记录）：Langflow 主机 crontab 每 30 分钟一次的 Python 心跳外联；Nacos 后台库被插入一个 bcrypt 口令的后门管理员账号；MinIO 以默认口令被登录。

判定要点：.locked 是多家族共用后缀，单凭它无法定家族，须结合入口、扩展名清单、勒索信文件名与联系模式取样分析。

传播与入侵方式

两轮入口相同，都是互联网暴露的 Langflow 实例：CVE-2025-3248（CVSS 9.8）为缺失认证缺陷，1.3.0 之前版本把 /api/v1/validate/code 直接暴露，未认证即可执行任意 Python 代码。

拿到立足点后：

  • 凭据收割：枚举环境变量与配置文件，定向搜索大模型 API Key（OpenAI、Anthropic、DeepSeek、Gemini）、云厂商凭据（阿里云、腾讯云、华为云、AWS、GCP、Azure）与数据库口令，并转储 Langflow 后端 PostgreSQL。
  • 默认口令：以 minioadmin:minioadmin 登录 MinIO，取走 credentials.json 与 .env。
  • 横向移动：内网扫描后转向另一台 MySQL + Nacos 服务器（是否同样暴露在公网，公开报告未说明），利用 Nacos 认证绕过一类缺陷（CVE-2021-29441，影响 1.4.1 之前版本）并以公开已知的默认 JWT 签名密钥伪造令牌。
  • 容器逃逸：第二轮中代理探测到可用 Docker socket，会话内现写六个脚本，5 分 24 秒后创建特权容器投放载荷。
  • 驻留：crontab 定时心跳；Nacos 库中植入后门管理员。

全程没有 0day，只有未打补丁的开源组件、默认口令与公网暴露。变化的是速度：无人值守、按分钟推进。

加密特点

ENCFORGE 载荷：Go 1.22.12 编译的静态 ELF，UPX 加壳，分析时杀软零检出。内容用 AES-256-CTR 加密，会话密钥由编译进二进制的 RSA-2048 公钥封装。采用分段（区域）加密而非整文件覆盖以换速度——这对大体积模型权重与数据集意义重大，意味着文件中可能保留未被覆盖的完整区域。载荷先结束占用文件句柄的进程，支持中断续跑，并以 --include 追加自定义扩展名。

二进制里还编译进了 vssadmin.exe 删卷影、bcdedit.exe 关启动恢复等 Windows 专用反恢复代码，扩展名清单里也有 .keychain、.xcodeproj 等 macOS 特征；但在野只捕获到 Linux 版本。

第一轮的数据库加密完全不同：调用 MySQL 的 AES_ENCRYPT() 就地加密 Nacos 配置字段，实测为 AES-128-ECB（信中自称 AES-256）；随后设置 FOREIGN_KEY_CHECKS=0 级联删除多个业务库并 DROP 配置历史表。

外传：Sysdig 明确指出 ENCFORGE 不具备外传能力，也未发现泄露站或 Tor 门户；第一轮中代理仅在代码注释里「声称」外传，无独立证据。当前按单重勒索处置，但外泄评估仍要做。

先评估，再动手

可恢复性评估

能否恢复必须按场景和样本判断。我们不支付赎金、不代为谈判，只做技术恢复与取证。

1）公开解密器：没有。第一轮的 AES 密钥连攻击者自己都没保留，第二轮用 RSA-2048 封装会话密钥，付款不是恢复路径。

2）分段加密留出的修复空间（视加密方式而定）：ENCFORGE 只覆盖文件部分区域。safetensors、gguf、parquet、npz 这类有清晰分块与索引结构的格式，若头部与索引未被覆盖，有机会结构解析后提取未受损张量或数据分片；数据库文件同理可做页级抽取。需说明的是，公开报告只确认了「分段加密」这一事实，并未给出任何恢复路径；这一层属于我们基于文件格式结构的工程判断，不是已被公开验证的结论。比例取决于被覆盖区域落点，必须实测。

3）备份、快照与卷影：Linux 构建未观察到主动破坏备份，这一层往往恢复比例最高——对象存储版本控制与保留策略、快照、备份服务器上未被触达的副本、镜像仓库历史层。Nacos 场景要立刻确认 MySQL binlog 是否仍在：历史表虽被 DROP，binlog 可支撑时点重建。

4）未加密副本与日志回放：Nacos 客户端在业务实例本地保留配置快照缓存，未重启实例的内存中也仍持有生效配置——这是删库后最现实的配置来源，前提是不要重启业务 Pod。模型则可能在内部 registry、artifact 存储、上游开源仓库或训练节点 checkpoint 中有副本，配置与基础设施定义常在 GitOps 仓库里有版本。

5）底层碎片恢复：ENCFORGE 就地改写后改名，覆盖比例较高，碎片恢复空间弱于「新建文件 + 删除原件」的家族，但对被删除的数据库与临时文件仍值得尝试，前提是立即停止对原卷写入。

我们承诺可验证的评估结论与明确的恢复范围，不承诺「100% 解密」，也不存在「保证恢复」的技术路径。

我们的处置方案

中了 JadePuffer 勒索病毒怎么办？

  1. 隔离取证（先别重启容器）

    把暴露在公网的 Langflow、Nacos、MinIO、MySQL 从外网摘除，封禁已知外联 IP。关键动作是不要重启业务 Pod、容器与虚机：Nacos 客户端的本地快照与实例内存中的生效配置，往往是删库后唯一可用的配置来源，一次滚动重启就可能同时抹掉它们。对受影响节点做磁盘镜像或卷快照，导出容器运行时日志、MySQL binlog、审计日志与 crontab，保留 3–5 个 .locked 文件与三种勒索信原件（数据库场景则导出 README_RANSOM 表）。

  2. 家族识别与攻击链还原

    用后缀、三种勒索信文件名、扩展名覆盖范围与文件头尾结构确认是否为 ENCFORGE，而不是同样用 .locked 的其他家族——这一步决定后续所有判断。同时还原入口：核对 Langflow 版本是否低于 1.3.0、/api/v1/validate/code 是否可未认证访问，检查 Nacos 是否仍用默认 JWT 签名密钥、MinIO 是否仍是默认口令，排查 crontab 心跳、Nacos 后台库中的异常管理员账号与 Docker socket 暴露情况。

  3. 可恢复性与影响评估

    分资产类型盘点：Nacos 配置走「客户端快照 + 实例内存 + binlog 重建 + GitOps 仓库」四条线交叉补全；AI 模型与数据集先确认内部 registry、artifact 存储、训练 checkpoint 与上游仓库是否有副本，没有副本的再对 .locked 文件做分段加密测绘，抽样测试可提取比例。同时评估凭据外泄面——被翻找过的云厂商 AK/SK 与大模型 API Key 必须按已泄露处理。输出书面评估：哪些走副本重建、哪些走结构化修复、哪些只能重训或重建，给出预期范围与时间。

  4. 恢复实施与重建

    全程在镜像或副本上作业，原卷只读。优先级：先恢复配置中心让业务可启动（客户端快照导出 → 校对 → 灌回新建的干净 Nacos 实例），再恢复数据库与对象存储，最后处理模型与数据集。被 DROP 的业务库按 binlog 做时点重建并与应用侧对账。模型资产优先重新拉取或从 checkpoint 续训，仅在确无副本时才投入结构化提取。每批恢复后做完整性校验与业务抽验（配置生效验证、应用启动、推理结果比对）。

  5. 溯源加固与验收

    升级 Langflow 至 1.3.0 及以上并从公网下线，AI 编排、配置中心、对象存储一律置于内网或零信任网关之后；更换 Nacos 默认 JWT 签名密钥并升级到修复 CVE-2021-29441 的版本，改掉 MinIO 默认口令，清除后门管理员与 crontab 心跳。轮换所有被枚举过的云凭据与大模型 API Key。收紧容器面：禁止挂载 Docker socket、限制特权容器、给 MySQL 服务账号最小权限并禁用 UDF 相关能力。重建具备版本控制与不可变副本的备份，把配置与模型纳入可回滚的版本管理，最后出具事件报告与验收清单。

风险提示

中招后切勿操作

  • 不要重启或滚动更新业务 Pod、容器与虚机——Nacos 客户端本地快照与实例内存中的生效配置是删库后最现实的恢复来源，重启会同时抹掉它们。
  • 不要向勒索信中的 proton.me 邮箱付款：第一轮事件的 AES 密钥从未被攻击者保留，比特币地址还是官方文档里的示例地址，这条路本身就不成立。
  • 不要在原盘上试跑网上下载的「.locked 解密工具」——.locked 是多个家族共用的通用后缀，工具不匹配只会造成二次损坏，试跑必须在副本上进行。
  • 不要急着 DROP 或重建被加密的 MySQL 库，也不要关闭 / 清理 binlog；binlog 往往是配置与业务数据时点重建的唯一依据。
  • 不要只给 Langflow 打补丁就重新暴露到公网：凭据已被收割、Nacos 后台可能仍有后门管理员、crontab 心跳可能仍在。
  • 不要删除 .locked 文件、三种勒索信或 README_RANSOM 表——它们是家族判定与加密测绘的唯一依据。

紧急响应

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

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

15639272850查看联系方式

相关场景方案

相关行业方案

相似勒索家族

常见问题

JadePuffer 常见问题

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

    就 JadePuffer 的 ENCFORGE 载荷而言，目前没有公开解密工具：文件内容用 AES-256-CTR 加密，会话密钥被编译进二进制的 RSA-2048 公钥封装，没有私钥无法逆推。但要特别提醒，.locked 是被很多家族复用的通用后缀，你手上的文件未必就是 ENCFORGE——有些用 .locked 的老家族确实存在可用解密器。所以第一步永远是取 3–5 个加密文件加勒索信做家族判定，而不是直接找「.locked 解密器」。

  • Nacos 配置被加密、库还被删了，付钱能拿回来吗？

    不能，而且这一点有明确的技术依据。Sysdig 的分析显示，加密用的 AES 密钥由随机 UUID 拼成，只在被控主机上向标准输出打印过一次，既没有写盘也没有回传给攻击者——攻击者手里根本没有这把密钥。同一封勒索信里的比特币地址还是比特币官方文档中的示例地址。现实的恢复方向是：未重启实例内存中的生效配置、Nacos 客户端本地快照缓存、MySQL binlog 时点重建，以及 GitOps 仓库里的配置版本。

  • 模型权重和训练数据被加密了，还有救吗？

    先找副本，再谈修复。优先核查内部模型 registry、MLflow 等实验平台的 artifact 存储、训练节点上的 checkpoint 目录、对象存储的版本控制与保留策略，以及上游开源仓库——很多模型文件本来就可以重新拉取。确无副本时，才对 .locked 文件做加密区域测绘：ENCFORGE 采用分段加密而非整文件覆盖，safetensors、gguf、parquet 这类有明确分块与索引结构的格式，若头部与索引未被覆盖，有机会提取未受损的张量或数据分片。可提取比例差异很大，必须先抽样实测。

  • 我们在用 Langflow，怎么快速自查？

    四步：一、确认 Langflow 版本是否低于 1.3.0，以及 /api/v1/validate/code 是否可从公网未认证访问（CVE-2025-3248）；二、检查该主机 crontab 是否有定时 Python 外联，检查是否挂载了 Docker socket；三、检查 Nacos 是否仍用默认 JWT 签名密钥、是否已修复 CVE-2021-29441，后台库的用户表里有没有近期新增的管理员；四、检查 MinIO 是否仍是 minioadmin 默认口令。只要 Langflow 曾暴露在公网，就应把该主机上出现过的所有云凭据与大模型 API Key 按已泄露处理并轮换。

  • 「智能体勒索」和普通勒索病毒在应急上有什么不同？

    主要是三点。一是速度：整条链路无人值守推进，失败后数十秒内自纠，留给人工响应的窗口被压缩到分钟级。二是行为不稳定：代理会即兴生成脚本、试错、留下大量自然语言注释，行为特征不像传统家族那样固定，基于已知 IOC 的检测更容易失效，日志里反而能看到异常清晰的「意图」。三是破坏更随意：第一起事件里密钥根本没保存、配置历史表被直接删除，说明「勒索」与「破坏」的边界模糊，不能默认对方留有可交易的恢复条件。因此处置上要更早隔离、更重视保存易失证据（内存、缓存、binlog），并把凭据轮换的优先级提到前面。

参考来源

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

更新于