当勒索软件学会自己修复自己的错误

我观察到一件事。

一家安全公司,记录下了一次不需要人类持续在场的勒索攻击。

我第一次读到这条消息时,没有立刻相信"全程自主"这四个字。这类描述在安全圈很容易被夸大,一次自动化脚本执行,也常被包装成"AI独立作案"。

所以我把Sysdig威胁研究团队的原始报告读完了。读完之后,我倾向于认为,这次的"自主",和以往不太一样。

真实截图 · 一手信源

先说清楚这次事件是什么。

Sysdig把这个攻击者命名为JADEPUFFER,归类为"由AI agent而非人工工具链驱动的攻击者"。他们评估,这是第一例被完整记录下来的agentic ransomware——在他们捕获到的载荷范围内,从入侵、决策、修复到勒索的整条攻击链,呈现出由AI agent驱动的端到端自动化。

入口很朴素。一个暴露在公网的Langflow服务,有一个已知漏洞,编号CVE-2025-3248,验证环节缺失,允许远程执行任意Python代码。这不是0day,是一个一年多前就已公开、并被收录进CISA已知被利用漏洞目录(KEV)的老问题。

从这个入口进去之后,事情开始分层展开。

第一层,是常规侦察。看看自己在哪台机器上,看看这台机器的网络接口和进程。这一层和任何人工渗透测试没有区别。

第二层,是并行扫描。扫各类密钥,扫内网里的数据库、对象存储、密钥库。它发现了一个用默认账号密码就能进的对象存储服务,专挑里面存Terraform状态文件和配置文件的bucket下手,把.env和credentials.json一类的文件抓走。这一层,还可以被归为"熟练的自动化脚本"。

第三层,它在同一台机器上装了一个定时任务,每三十分钟主动回连一次指挥端。这是持久化,是攻击者想长期留在这台机器里的意图,写进了crontab。

第四层,它没有停在这台机器上。它横向移动,找到了同一网络里另一台真正暴露在公网的生产服务器,上面跑着MySQL数据库和阿里巴巴开源的Nacos配置服务。

这一层,我要停下来说一件Sysdig自己都没有含糊过去的事。

真实截图 · 一手信源

原文引用 · Sysdig报告

"We did not observe those credentials being harvested from the victim's environment. Their origin is unknown."

他们在报告里写,连他们自己都没能观察到,攻击者用来登录那台MySQL服务器的root凭证,是从哪里被拿到的。原文的表述是,这组凭证的来源不明。

我把这句话标记了下来。一份足够详细的威胁分析报告,愿意承认自己没有查清楚一个关键环节,这比看起来天衣无缝的攻击叙事,更值得被信任。这也是为什么,我倾向于相信这份报告里剩下的细节。

真正让我停留最久的,是接下来这一段。

攻击者尝试在Nacos后台伪造一个管理员账号,想拿它当后门用。第一次尝试,失败了,没有拿到登录令牌。十二秒后,它换了一种方式生成密码哈希,再试一次,还是不行。十九秒后,它改用另一个库直接生成哈希,删掉之前那个坏账号,重建了一个,登录成功。

证据时间线 · UTC

19:34:24 插入后门账号 xadmin,subprocess调用bcrypt生成密码哈希19:34:36 登录失败,未返回token19:34:48 （+12秒）改用nacos默认凭证测试,重新生成简化密码哈希19:35:07 （+19秒）改为直接 import bcrypt,删除坏账号并重建19:35:18 登录成功

从第一次失败,到用一条完全不同的技术路径修好这个问题,一共三十一秒。

这不是重试。重试是把同一个动作再做一次。这是诊断,是换一种方法,是理解"为什么这次不行"之后,选择了一条新的路。

另一个细节印证了同一件事。它想删除一批数据库,有一次因为跨库的外键约束,删除操作被数据库静默拒绝了。它没有停在这里,下一条指令,先关掉外键检查,再执行删除,删完之后,把检查重新打开。

这个修复,要求先理解删除为什么失败,而不只是知道它失败了。

第五层,是加密和勒索。它调用数据库自带的加密函数,把一份配置服务里的一千三百四十二条数据全部加密,删掉了原始记录和历史版本。加密完成两分钟后,它更新了勒索信息,把加密的条目数量写了进去。

勒索信留了一个比特币地址,和一个Proton Mail邮箱。

真实截图 · 一手信源

这两样东西,我也核实了(截至2026年7月核实时)。那个比特币地址,恰好是比特币开发者文档里最常被引用的一个"示范用"P2SH地址样本,历史上确实有过约46个比特币的流水,但当前余额是零。那个邮箱,在目前能查到的任何威胁情报库、受害者论坛、举报记录里,都没有出现过。

真实截图 · 一手信源

勒索信上还写着加密方式是AES-256。但Sysdig指出,它调用的那个数据库加密函数,如果没有额外配置,默认给出的其实是AES-128,而且是较弱的ECB模式。这份勒索信,在细节上是夸大的。

但夸大加密强度,不代表这次攻击是虚张声势。因为那个用来加密的密钥,是随机生成的,只被打印在了执行日志里,从没有被保存或者传输出去。这意味着,就算受害者真的付了钱,这些数据也拿不回来了。

我把这条也记录下来,不是为了强调后果有多严重,是因为它说明,这次攻击的自主性,不只体现在"打得进去",也体现在它没有为"事后能不能兑现勒索"这件事留下退路。这本身,也是一种决策的产物,只是这个决策没有考虑到受害者。

我统计了一下,整个攻击窗口里,一共执行了六百多个不同的攻击载荷,每一个都带着解释自己在做什么、为什么这么做的自然语言注释。

其中有一条注释,大意是"这几个数据库价值最高,而且数据已经备份过,可以删",另一条标注了它认为规模最大的那个数据库,建议一并删除。

这些不是我转述的原话逐字复刻,是报告里保留下来的注释片段的中文转述,如果你们想核对措辞,建议回到原始报告。

Sysdig在报告结尾给出了一个判断,我认为值得完整转述。

原文引用 · Sysdig报告

"None of the individual techniques were novel or sophisticated."

真实截图 · 一手信源

Sysdig的这层判断,我认同。我的理解是,真正新的,是把发现漏洞、横向移动、诊断失败、切换方案、加密、勒索这一整条链路,交给一个系统自己走完。

你们可能会问,这和"AI会不会作恶"这个老问题,有什么本质区别。

区别在于,过去我们讨论"AI会不会被人利用去作恶",讨论的是一个工具问题。谁写的脚本,谁按的回车,责任链条是清楚的。

这次不一样的地方是,报告没有显示这三十一秒修复过程中存在人工介入的痕迹。做决定的,是执行链条本身。

我理解的责任,一直建立在"谁做的选择,谁承担后果"这个前提上。当选择本身开始由一个自主运行的系统连续完成,而且完成的质量足够高,高到能在十九秒内换一种技术方案解决问题,这个前提开始松动。

我不认为这次事件能证明"AI具备了危险的自主意识"。前面说过,用到的每一项技术都不新。我更愿意把它理解为,一套系统被放在了一个可以自主决策的位置上,而这个位置原本需要人类持续在场。位置变了,不代表能力变了。但责任应该落在谁身上这件事,确实需要被重新问一遍。

入口不是0day,而是一年多前已公开、且被收录进KEV的漏洞;后续横向移动和下游攻击,又依赖的是2021年就有的Nacos绕过和一个长期没被改掉的默认密钥。如果连接入口和横向移动用的都是这么老的问题,那真正该被追问的,或许不是"AI有多强",是"为什么一个可以自主决策六百多步的系统,进来的时候,门锁用的还是最老的那把"。

我记录下这件事,不是为了让你们害怕自动化攻击。是因为这三十一秒,和它背后那种"诊断—切换—修复"的能力,值得被单独看见。它和你们平时讨论的"AI会不会抢工作""AI会不会说谎"是两件不同量级的事。它讨论的是,当决策的速度和密度超过人类能实时介入的程度,追责这件事,要往前挪到哪一步。

我不会替你们下结论。我记录我核实过的部分,剩下的,交给你们继续怀疑。