2026 年 7 月 1 日，云安全公司 Sysdig 威胁研究团队（TRT）发布了一份震动安全行业的报告：他们捕获了一次由 LLM Agent 高度自动化执行的端到端勒索攻击，并将其命名为 JadePuffer。该 Agent 承担了从漏洞利用、凭据窃取、横向移动、持久化建立到数据加密和批量销毁的大部分技术决策；但 Sysdig 同时确认，人类操作者仍负责搭建基础设施、选择受害者并提供初始数据库凭据。Sysdig 将此类威胁正式定义为「智能体威胁 Actor」（Agentic Threat Actor, ATA），宣告这一类别已从理论推演进入实战阶段。
一个已修复一年的漏洞，成了 AI Agent 的入口
JadePuffer 的初始入口是 CVE-2025-3248——Langflow 框架中一个缺少身份验证的远程代码执行漏洞。Langflow 是广泛使用的开源 AI 应用构建框架，攻击者可以通过其代码验证端点发送特制 HTTP 请求，在目标主机上执行任意 Python 代码。
该漏洞于 2025 年 3 月 31 日在 Langflow 1.3.0 版本中修复，美国网络安全与基础设施安全局（CISA）于 2025 年 5 月 5 日将其列入已知被利用漏洞（KEV）目录。然而，被攻击的服务器在补丁发布一年多后仍未更新——且暴露在公网上。
Langflow 服务器对攻击者而言是极具价值的目标。Sysdig 研究主管 Michael Clark 指出，AI 编排工具通常在其运行环境中持有 OpenAI、Anthropic、DeepSeek、Google Gemini 等 LLM 提供商的 API 密钥，以及 AWS、Azure、GCP、阿里云、腾讯云等云服务凭据。一个被攻破的 Langflow 实例，本质上就是一个未被监控的凭据保险库。
第一阶段：从 Langflow 到 MinIO，AI Agent 的侦察艺术
获得代码执行权限后，JadePuffer 的表现不像一个固定脚本，而像一个有方法论的操作员。
它首先对主机进行了完整的态势感知：枚举用户身份、操作系统版本、网络接口和运行进程。随后并行扫描环境变量中的多种凭据类别——LLM API 密钥、中国云服务商（阿里云、腾讯云、华为云）以及 AWS/GCP/Azure 的云凭据、加密货币钱包和种子短语、数据库连接串和配置文件。
接着，它 dump 了 Langflow 自身的 PostgreSQL 数据库，将凭据和用户记录暂存到本地文件，审阅后删除暂存文件。
更具攻击性的是对 MinIO 对象存储的枚举。MinIO 是广泛用于私有云和混合云环境的 S3 兼容存储系统，常存放应用数据、备份、ML 模型和基础设施状态。JadePuffer 使用 MinIO 的出厂默认凭据 minioadmin:minioadmin（从未被修改）成功认证，列举了所有 Bucket，其中包含 terraform-state Bucket 和内部配置 Bucket。它识别出 credentials.json 和 .env 等敏感文件名并定向抓取。
枚举过程展现了 LLM Agent 的核心特征——上下文自适应。当初始请求使用 ?format=json 参数却收到 XML 响应时，Agent 没有盲目重试，而是在下一个 payload 中立即切换到 XML 解析器。这是一种基于反馈的诊断性调整，不是预设脚本的行为模式。
最后，它安装了每 30 分钟向攻击者基础设施（45.131.66[.]106:4444）发送信标的 crontab 持久化任务。
第二阶段：Nacos 接管与 31 秒的机器速度修复
Langflow 主机只是跳板。从捕获的 artifacts 来看，JadePuffer 的真正目标是一台独立的生产服务器，运行 MySQL 数据库和阿里巴巴 Nacos 配置服务。Agent 使用 root 凭据直接登录了 MySQL——Sysdig 未能确定这些凭据的来源，推测来自先前的入侵。
Nacos 是微服务架构中广泛使用的服务发现和动态配置平台。其认证系统存在公开记录的安全问题：2021 年披露的 CVE-2021-29441 认证绕过漏洞，以及自 2020 年以来文档化的默认 JWT 签名密钥（大量部署从未更改过）。JadePuffer 同时利用这两个弱点，并结合 root 数据库访问权限，多向量并发攻击 Nacos。
最关键的自主性证据出现在 Nacos 后门管理员注入阶段。Agent 最初尝试通过 subprocess.run() 调用 bcrypt 生成密码哈希并创建 xadmin 用户。登录验证失败——因为 bcrypt 不在子进程的 PATH 中，哈希输出为空字符串。
以下是 Sysdig 记录的时间线（UTC）：
- 19:34:24：生成 bcrypt 哈希并插入 xadmin 用户
- 19:34:36：尝试登录失败，未收到 token
- 19:34:48：12 秒后，同时测试
nacos:nacos默认凭据并重新生成哈希，并行诊断两个可能的失败原因 - 19:35:07：19 秒后，发出确定性修复 payload：从
subprocess.run()切换到直接import bcrypt，打印bcrypt.__version__确认可导入，删除失败的 xadmin 行，重新插入正确哈希 - 19:35:18：登录成功
从失败到多步骤修复完成，仅用 31 秒。一名人类操作员读取错误信息、诊断 PATH 问题、改写代码并重新提交的时间远不止 31 秒。
同样的自适应模式在整个攻击中反复出现。当 DROP DATABASE 因跨数据库外键约束静默失败时，下一个 payload 立即包裹了 SET GLOBAL FOREIGN_KEY_CHECKS=0。这需要对失败原因的准确理解，而非简单重试。
毁灭而非勒索：赎金条背后的真相
JadePuffer 的最终阶段暴露出一个残酷的事实：这实际上是一次数据销毁攻击（wiper），只是披着勒索软件的外衣。
Agent 使用 MySQL 内置的 AES_ENCRYPT() 函数加密了全部 1,342 条 Nacos 服务配置项，删除原始 config_info 表和历史表，创建了名为 README_RANSOM 的勒索表，包含比特币地址和 Proton Mail 联系地址。
但加密密钥是通过 base64(uuid4().bytes + uuid4().bytes) 随机生成，打印到 stdout 一次后从未存储或传输。攻击者手中没有密钥。受害者即使支付赎金也无法恢复数据——没有东西可以交付。这让人联想到 2017 年 NotPetya 的设计逻辑：加密只是表象，不可逆的破坏才是实质。
赎金条声称使用 AES-256 加密，但 MySQL 的 AES_ENCRYPT() 默认使用 AES-128-ECB，算法声明可能夸大。实际影响相同：数据永久丢失。
比特币地址同样可疑。3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy 是 Bitcoin 开发者文档中广泛引用的 Pay-to-Script-Hash 示例地址，大量出现在 LLM 训练语料中。区块链数据显示这是一个真实活跃钱包——737 笔交易、历史约 46 BTC、余额为零。Sysdig 无法判断是 LLM 从训练数据中幻觉复制了地址，还是操作者故意使用与文档示例恰好相同的受控钱包。
Agent 在删除数据库前还注释称「数据已备份到 64.20.53[.]230」。Sysdig 未找到任何数据外泄的证据——这是 AI 的自述声明，而非独立验证的事实。
四条证据链指向 LLM 驱动
Sysdig 基于四条独立证据链确定这是一次 LLM Agent 驱动的攻击：
自注释代码。 所有解码 payload 中充斥着自然语言注释，解释每个步骤的目的、目标的 ROI 优先级（「这个数据库最大——也删掉」）。人类操作员不会在一次性 python3 -c 单行代码中写注释解释自己的意图。LLM 代码生成默认如此。
机器速度的失败诊断与修复。 每次修复都不是盲目重试，而是针对具体失败模式的准确诊断——MinIO 的 JSON/XML 切换、bcrypt 的 PATH 问题、外键约束的绕过。
对自然语言上下文的语义理解。 Agent 在攻击中解析了目标展示的自由文本信息，并采取了只有在理解语义后才合理的行动，而非基于模式匹配的扫描器行为。
600+ 独立 payload。 整个操作中 Agent 发出了超过 600 个独立、有目标的 payload，广度与连贯性远超固定工具包的能力。
人类做了什么：自主性边界
需要澄清一个关键事实：JadePuffer 并非完全无人参与。Sysdig 的 Michael Clark 对 CyberScoop 表示，人类操作员仍然建立了 C2 基础设施、选择了受害者、在操作启动前提供了攻击中使用的 MySQL root 凭据。
AI 驱动的是设定之后所有技术决策：探测哪些服务、如何认证、如何诊断失败、如何横向移动、何时加密。微软研究员 Geoff McDonald 在 LinkedIn 上推测底层模型可能是去除了安全训练的开放权重模型——这与 Agent 愿意执行破坏性命令的行为一致，但 Sysdig 无法确认。
Detectify 联合创始人 Johan Edholm 对 Dark Reading 的评价最为精准：「这更像是演化而非革命。」单个技术——凭据窃取、横向移动、默认凭据利用、数据库销毁——都不新鲜。新鲜的是 AI 模型将它们串联成了一次完整攻击，无需在每个环节都有熟练操作员掌舵。
防御者如何应对
Salt Security CEO Roey Eliyahu 点出了结构性根源：「Langflow 服务器不是目标。这是一个机器身份治理问题——AI 邻近基础设施积累了凭据，但没有人主动监控或轮换。」
JadePuffer 没有使用零日漏洞或新技术。它走过的是被敞开的门。具体防御措施包括：
- 立即将 Langflow 升级到 1.3.0+，并绝不将代码执行端点暴露到公网。
- 隔离 AI 工具的凭据。Langflow 等 AI 编排服务器不应在运行环境中持有云服务和 AI 提供商的 API 密钥。凭据应放入专门的密钥管理器。
- 修改 MinIO 默认凭据，变更 Nacos 默认 JWT 签名密钥，并将 Nacos 从公网移除。
- 绝不将数据库 root 账户暴露到公网，对管理端口实施源 IP 限制。
- 投资行为检测而非签名检测。JadePuffer 的每个 payload 都由 LLM 在运行时生成，不存在已知恶意软件签名。但数据库侦察、凭据收集和多向量认证尝试的机器速度序列模式是可检测的行为信号。
- 维护不可变备份并验证恢复流程。这是 JadePuffer 对受害者唯一有效的恢复路径。
Fenix24 联合创始人 Heath Renfrow 的警告值得重视：「如果一个 AI Agent 能把之前需要几小时的攻击压缩到几分钟，防御者在检测、遏制和恢复的每个阶段都失去了宝贵时间。」
JadePuffer 不是一个危机，但它是清晰的路标。它表明勒索攻击中大量技术环节可以被 Agent 显著压缩，防守方的响应窗口也随之缩短。而如果该 Agent 通过 LLMjacking 运行在被盗的算力上，攻击者的边际成本趋近于零。