2026 年 7 月 1 日，云安全公司 Sysdig 威胁研究团队（TRT）披露了一次他们判断由大语言模型智能体高度自动化执行的勒索攻击，并将其命名为 JadePuffer。据研究团队分析，该 Agent 承担了从漏洞利用、凭据窃取、横向移动、持久化建立到数据加密和批量销毁的大部分技术决策；但 Sysdig 同时确认，人类操作者仍负责搭建基础设施、选择受害者并提供初始数据库凭据。Sysdig 将这类利用 AI 智能体执行攻击的操作者称为 Agentic Threat Actor（ATA）。这起案例提供了观察其实际能力与局限的材料。
攻击从未修补的 Langflow 服务器进入
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 实例就可能让攻击者获得访问其他服务的权限。
第一阶段：搜集主机凭据，再访问内部存储
获得代码执行权限后，JadePuffer 开始收集主机和内部服务的信息，并根据返回结果调整后续操作。
它首先检查主机状态：枚举用户身份、操作系统版本、网络接口和运行进程。随后并行扫描环境变量中的多种凭据类别——LLM API 密钥、中国云服务商（阿里云、腾讯云、华为云）以及 AWS/GCP/Azure 的云凭据、加密货币钱包和种子短语、数据库连接串和配置文件。
接着，它导出了 Langflow 自身的 PostgreSQL 数据库，将凭据和用户记录暂存到本地文件，审阅后删除暂存文件。
随后，攻击转向 MinIO 对象存储。MinIO 是广泛用于私有云和混合云环境的 S3 兼容存储系统，常存放应用数据、备份、ML 模型和基础设施状态。JadePuffer 使用 **MinIO 的出厂默认凭据 minioadmin:minioadmin**成功认证，列举了所有 Bucket，其中包含 terraform-state Bucket 和内部配置 Bucket。它识别出 credentials.json 和 .env 等敏感文件名并定向抓取。
枚举过程中出现了根据反馈调整行为的迹象。当初始请求使用 ?format=json 参数却收到 XML 响应时，Agent 没有盲目重试，而是在下一个 payload 中立即切换到 XML 解析器。Sysdig 将这种有针对性的调整作为判断智能体参与攻击的证据之一。
最后，它安装了每 30 分钟向攻击者基础设施（45.131.66[.]106:4444）发送信标的 crontab 持久化任务。
第二阶段：接管 Nacos，登录失败后 31 秒发出修复指令
Langflow 主机只是跳板。从捕获的攻击记录来看，JadePuffer 的真正目标是一台独立的生产服务器，运行 MySQL 数据库和阿里巴巴 Nacos 配置服务。Agent 使用 root 凭据直接登录了 MySQL——Sysdig 未能确定这些凭据的来源，可能与先前的入侵有关。
Nacos 是微服务架构中广泛使用的服务发现和动态配置平台。其认证系统存在公开记录的安全问题：2021 年披露的 CVE-2021-29441 认证绕过漏洞，以及自 2020 年以来文档化的默认 JWT 签名密钥（大量部署从未更改过）。JadePuffer 同时尝试认证绕过、默认签名密钥和 root 数据库权限等途径。记录显示，目标提示使用了自定义密钥后，它放弃了 JWT 伪造这条路径。
一次能清楚看到调整过程的操作，是向 Nacos 写入后门管理员账户。Agent 最初尝试通过 subprocess.run() 调用 bcrypt 生成密码哈希并创建 xadmin 用户。随后的登录验证失败。Sysdig 推测，子进程未能正确加载 bcrypt，导致哈希输出为空字符串。
以下是 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：登录成功
从 19:34:36 登录失败，到 19:35:07 发出修复指令，相隔 31 秒；确认登录成功则是在失败后的 42 秒。Sysdig 认为，这段紧密衔接的诊断与调整是自动化执行的重要迹象。
同样的自适应模式在整个攻击中反复出现。当 DROP DATABASE 因跨数据库外键约束静默失败时，下一个 payload 立即包裹了 SET GLOBAL FOREIGN_KEY_CHECKS=0。下一步操作针对了这次失败，进一步支持了研究团队对自适应执行的判断。
数据被加密并删除，赎金条未提供可靠恢复路径
JadePuffer 最后既加密数据，又删除原始表和数据库。Sysdig 因而认为，这次勒索操作具有明显的数据销毁性质。
Agent 使用 MySQL 内置的 AES_ENCRYPT() 函数加密了全部 1,342 条 Nacos 服务配置项，删除原始 config_info 表和历史表，创建了名为 README_RANSOM 的勒索表，包含比特币地址和 Proton Mail 联系地址。
加密密钥通过 base64(uuid4().bytes + uuid4().bytes) 随机生成。Sysdig 在捕获的代码中只看到它被打印到 stdout，未发现专门存储或传输密钥的步骤，因此判断受害者无法靠支付赎金恢复配置。就破坏结果而言，报告描述的行为与 2017 年 NotPetya 一类破坏性攻击有相似之处；现有记录没有交代操作者是否另外保留了终端输出。
赎金条声称使用 AES-256 加密，但 MySQL 的 AES_ENCRYPT() 在未重新配置时默认使用 AES-128-ECB，声明可能夸大了算法规格。对恢复而言，更直接的问题是原始数据已被删除，且没有观察到可靠的密钥保管流程。
比特币地址同样可疑。3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy 是 Bitcoin 开发者文档中广泛引用的 Pay-to-Script-Hash 示例地址，大量出现在 LLM 训练语料中。Sysdig 查询时的区块链数据显示，这个地址有 737 笔交易、历史收款约 46 BTC，余额为零。Sysdig 无法判断是 LLM 从训练数据中幻觉复制了地址，还是操作者故意使用与文档示例恰好相同的受控钱包。
Agent 在删除数据库前还注释称「数据已备份到 64.20.53[.]230」。Sysdig 未找到任何数据外泄的证据——这是 AI 的自述声明，而非独立验证的事实。
Sysdig 如何判断攻击由大语言模型驱动
Sysdig 综合以下四类迹象，判断攻击由 LLM Agent 驱动：
自注释代码。 所有解码 payload 中充斥着自然语言注释，解释每个步骤的目的、目标的 ROI 优先级（「这个数据库最大——也删掉」）。Sysdig 认为，一次性攻击代码中如此密集的自我解释，更接近 LLM 生成代码的常见特征。单靠注释本身仍不足以排除人工编写。
快速的失败诊断与修复。 多次后续指令都针对具体失败作出调整，例如 MinIO 的 JSON/XML 切换、bcrypt 调用方式的改变，以及外键约束问题。
根据自然语言信息调整操作。 Sysdig 表示，目标展示的自由文本影响了 Agent 的后续行动，这种现象在相隔数周的记录中重复出现。团队据此认为，攻击过程包含对文本含义的处理。
付款地址与文档示例相同。 前文提到的比特币地址可能来自模型训练材料，也可能由操作者指定，这一问题仍未解决。
此外，整个操作包含超过 600 个独立、有目标的 payload。Sysdig 将这些指令的广度和连贯性，与上述迹象一起纳入判断。
人类负责前期准备，底层模型仍无法确认
JadePuffer 的自动化执行仍以人类准备为前提。Sysdig 的 Michael Clark 对 CyberScoop 表示，人类操作员仍然建立了 C2 基础设施、选择了受害者、在操作启动前提供了攻击中使用的 MySQL root 凭据。
据 Sysdig 的分析，AI 承担了任务启动后的大部分技术选择：探测哪些服务、如何认证、如何诊断失败、如何横向移动、何时加密。微软研究员 Geoff McDonald 在 LinkedIn 上推测底层模型可能是去除了安全训练的开放权重模型，但 Sysdig 无法确认底层模型及其配置。
Detectify 联合创始人 Johan Edholm 对 Dark Reading 评论说：「这更像是演化而非革命。」凭据窃取、横向移动、默认凭据利用和数据库销毁，都已有先例。这起案例的变化在于，AI 将这些技术连续用于一次攻击，减少了逐步人工操作的需要。
防守重点仍是补丁、凭据隔离和数据库访问控制
Salt Security CEO Roey Eliyahu 将问题归结到凭据管理：「Langflow 服务器不是目标。这是一个机器身份治理问题——AI 邻近基础设施积累了凭据，但没有人主动监控或轮换。」
JadePuffer 没有使用零日漏洞或新技术。它利用了未修补系统和薄弱配置。对应的防御措施包括：
- 将 Langflow 升级到修复相关漏洞的受支持版本，并绝不将代码执行端点暴露到公网。
- 隔离 AI 工具的凭据。避免在 Langflow 等 AI 应用服务器中集中保存权限过大的长期密钥。通过密钥管理器按需提供访问权限，并限制单个工具能够访问的服务和数据。
- 修改 MinIO 默认凭据，变更 Nacos 默认 JWT 签名密钥，并将 Nacos 从公网移除。
- 绝不将数据库 root 账户暴露到公网，对管理端口实施源 IP 限制。
- 加强运行时行为检测。动态生成的 payload 会增加单靠固定签名识别攻击的难度；数据库侦察、凭据收集和连续认证尝试，则可以提供行为检测线索。
- 维护不可变备份并验证恢复流程。可用、未受破坏的备份能为遭到删除或加密的数据提供恢复机会。
Fenix24 联合创始人 Heath Renfrow 提醒说：「如果一个 AI Agent 能把之前需要几小时的攻击压缩到几分钟，防御者在检测、遏制和恢复的每个阶段都失去了宝贵时间。」
JadePuffer 展示了 Agent 将多项攻击操作连续执行的可能性，也提醒防守方缩短检测和处置时间。Sysdig 还指出，如果攻击者通过盗用模型凭据的 LLMjacking 转嫁推理费用，执行此类攻击的成本可能进一步下降；本案并未确认使用了这一路径。
