超过600个具有明确目的的攻击载荷,1342条配置数据被AES加密,整条攻击链从漏洞利用到数据库摧毁完全由AI自主完成——7月3日,安全厂商Sysdig公布了全球首个有完整记录的AI Agent勒索软件攻击案例,并将这名攻击者命名为JADEPUFFER。研究人员发现,它不仅全程无需人类操作,更在31秒内自动完成了一次失败登录的故障排除,展现出了令人惊讶的决策能力。但最讽刺的是,这位看似精密的AI攻击者犯了一个致命的低级错误:它生成的加密密钥只在终端打印了一次,既没保存也没上传,等于把解密钥匙直接扔进了虚空。

这起事件证明了AI Agent已经能自主串联漏洞利用、权限提升、凭据窃取、横向移动、持久化控制与勒索破坏这一整套攻击链,大幅降低了实施勒索攻击的技术门槛。但JADEPUFFER留下的“无解”现场,却让这起本该令人胆寒的攻击,带上了几分黑色幽默。下面我们就按攻击流程逐层拆解,看看这个AI到底做了什么,以及为什么最终受害者就算想付赎金也拿不回数据。

打开网易新闻 查看精彩图片

攻击的入口是一台暴露在公网的Langflow服务,攻击者利用了CVE-2025-3248这一高危漏洞,在无需身份验证的情况下远程执行Python代码,直接拿下目标主机控制权。该漏洞早在Langflow 1.3.0版本中就已修复,并且2025年被美国网络安全和基础设施安全局(CISA)列入“已知遭利用漏洞”名单。但研究人员指出,仍有大量互联网暴露实例没有及时更新,使得它们如同开着大门的房子,被JADEPUFFER轻松闯入。这个起点选得并不新奇,难的是后续AI如何自动把这一处破口放大成整条杀伤链。

一拿到初始权限,JADEPUFFER就启动了自动侦察。它在受害主机中大肆收集敏感信息,目标包括OpenAI、Anthropic、DeepSeek、Gemini等大模型服务的API密钥,阿里云、腾讯云、华为云、AWS、Google Cloud、Azure等云平台的登录凭证,以及数据库账号、配置文件、加密货币钱包和助记词等。更绝的是,它还利用MinIO对象存储的默认账号密码“minioadmin”访问存储桶,下载含有访问密钥的配置文件,并在受害服务器上创建计划任务,每隔30分钟主动连接攻击者控制服务器,目的是维持长期立足点。同时,它还导出了Langflow使用的PostgreSQL数据库内容。所有这些操作都由AI自动生成并执行,不少脚本还带着用自然语言写的注释,说明每一步的目的和优先级,就像在给自己写工作笔记。

接下来是横向移动,JADEPUFFER把枪口转向了另一台承载生产业务的服务器,上面运行着MySQL数据库和阿里巴巴开源的配置中心Nacos。AI用数据库Root账号登录MySQL,并盯上了Nacos的一个老漏洞CVE-2021-29441,这是一个身份验证绕过漏洞,配合长期未修改的默认JWT签名密钥,JADEPUFFER顺利拿到Nacos的管理权限。它随后在数据库中植入了隐藏的管理员账号,实现了对配置中心的完全控制。在这个过程中,出现了一个颇具代表性的细节:当它第一次创建管理员账号失败时,没有像简单脚本那样直接崩溃重试,而是在31秒内自动完成了错误分析、重新生成密码哈希、删除失败账号、重新创建管理员并再次验证登录的完整修复过程。这个闭环的自愈行为,是过去自动化攻击工具从未展现过的。

随着权限到手,攻击进入勒索阶段。JADEPUFFER调用MySQL的AES_ENCRYPT()函数,把Nacos中全部1342条配置数据逐条加密,随后删除了原始配置表和历史记录表,并新建了一张名为README_RANSOM的表,留下勒索信息,里面包含比特币钱包地址和一个Proton Mail联系方式。然后,它在终端输出了加密密钥,但仅此一次,没有将密钥保存到任何文件,也没有上传给攻击者。Sysdig研究人员反复核查后确认,这把密钥彻底丢失了。这意味着即使受害者真的支付了赎金,也无法从攻击者那里拿到解密工具——因为连攻击者自己都没有。更让人哭笑不得的是,AI后续还删除了多个数据库,并在生成的代码里声称数据已备份至外部服务器,但研究人员根本没有找到任何数据成功外传的证据,这个自我安慰式的注释很可能是AI凭空写下的。

纵观整场攻击,JADEPUFFER所用到的漏洞和战术都不是新技术,其真正的突破在于它们被AI自主地排成了一条严密的流水线,并且能根据执行结果动态调整策略。把这一能力放在勒索软件的场景里,就意味着以后要发起一次像样的攻击,不再需要一个高水平的攻击者全程操控,AI Agent就能扮演这个角色。但这次事件也告诉我们,当前的AI攻击者还远非完美,它们会犯下连菜鸟黑客都可能避免的错误——比如不备份解密密钥。Sysdig据此建议,企业最有效的防御仍是基础安全工作:尽快升级Langflow到修复版本,不要把代码执行接口直接暴露出公网,更换Nacos默认JWT签名密钥,避免数据库用Root权限对外服务,同时加强运行时行为检测、限制服务器对外通信,并妥善管理各类访问凭据。毕竟,就算攻击者笨到把钥匙扔了,被破坏的数据也不会自己回来。