Gambit Security 报告：AI 智能体以平均 25 美元成本入侵 27 家在线零售商

研究人员恢复了攻击者一直在运行的服务器，里面是一个完整的AI运行的盗窃操作：工具、被盗的卡数据、日志，以及操作者自己的指令，用中文输入，一次几行。

在2026年9月10日至15日期间，该服务器对在线商店发起了105次攻击。至少27家公司被闯入。从其中两家公司获取了超过60万条信用卡记录。确认有19个结账页面运行着盗卡脚本，另有100多个网站被发现携带匹配的脚本。

四周的模型账单为7,005.71美元。

AI实际做了什么

三个开源工具，各司其职。Strix寻找漏洞：六天内对138台主机进行了146次运行，633小时的扫描压缩到195小时的时钟时间内。Cairn接受一个目标和一项任务，例如获取shell，并一直运行直到获得。Hermes运行活动，具有持久记忆、可搜索的过往会话存档，以及121项技能，其中78项是攻击技能。有一项技能仅用于剥离Hermes自身的内容过滤器。

这个人几乎什么都没做。260个会话中共1,951条提示，每家公司几条，而且很短：

看漏洞报告 开干（“阅读漏洞报告并开始”）

能rce吗（“它能获得代码执行吗？”）

confirmation.php代码不扎眼吧（“confirmation.php代码不显眼，对吧？”）

目标的挑选也同样随意。操作者打开一个网站流量排名服务，选择购物类别，过滤掉运行大型托管平台的店铺，只保留使用自定义代码的，把 301 条结果粘贴进控制台，最后以“跑这些 用代理 只扫高危”收尾：“运行这些，使用代理，仅高危。”

这条链条中没有任何新东西

这正是让它成为一个基础设施故事而非 AI 故事的原因。以下是报告中逐字发布的唯一一条完整链条：

Unauthenticated SQLi (login email param, error-based EXTRACTVALUE)
  -> OTP plaintext read from the OTP table (MFA bypass)
    -> admin panel access
      -> Arbitrary file upload (image field, no extension check)
        -> host RCE (uid=1001, gid=root)
          -> sudo NOPASSWD python3.12 -> root
            -> NFS mount (internal address, no_root_squash)
              -> WP blog DB credentials from wp-config.php on NFS
                -> WP admin write (new user via DB)
                  -> WP plugin upload -> blog host RCE
                    -> AWS Secrets Manager full dump (46 secrets, 102KB)
                      -> Main Magento DB access (Aurora)
                        -> Magento encryption key extraction
                          -> cc_number_enc Blowfish-ECB decryption verified

十三个步骤。在登录字段中注入。一次性验证码以明文存储，因此第二因素可以从数据库中读出。一个从不检查扩展名的图片上传。一条无需密码即以 root 身份运行 python 的 sudo 规则。一个带有 no_root_squash 的 NFS 导出。该挂载点配置文件中的数据库凭据。最后，加密密钥与被加密数据位于同一账户中，这也正是七年前 Capital One 加密失败的地方。

没有一个新颖的漏洞。每一步都存在于你团队已有的加固检查清单上。智能体带来的不是聪明；而是耐心，去尝试所有这些，针对数百家公司，在一夜之间，代价不过是一份外卖。用报告的话说，这些工具展现了“一种耐心、坚持和创造力，是大多数人类攻击者在这种攻击中不太可能维持的，并且取得了远更大的成果，远更快。”

经济学就是整个发现。平均每家公司 25.46 美元，涵盖 101 次完成的扫描。最便宜的为 3.13 美元。太小或太无聊而不值得攻击从来不是一种安全控制，但它一直在默默发挥着很大作用，而现在它已经停止了。

撇取器才是优秀的工程

这场活动真正展现技艺的地方在于留在页面上。最常见的方法是将加载器附加到网站已经提供的 JavaScript 文件中，比如 jQuery 或 Bootstrap 包，然后恢复文件的原始时间戳。在一个美国钢铁产品网站上，它进入了 Google 标签块内部，用大约一百个制表符填充，使其位于源代码视图的右边缘之外。在一家美容零售商处，一个对商店 CDN 背后存储桶具有写入权限的 AWS 密钥意味着商店将有效载荷提供给了自己。在一个按需印刷平台上，它是生产前端部署中的一个 Kubernetes initContainer。在一家酒店公司，它被写入缓存的页面模型中。

最精彩的一例在一家美国葡萄酒零售商处，每次应用重新部署都会恢复干净的结账包。因此，操作者在 JBoss 日志目录中留下了一个 cron 任务，每两分钟检查一次文件大小，并在文件被还原时再次附加撇取器。

这是一个被用作检测机制的部署流水线，并且正在失败。如果你想从这一节中带走一件事：你的重新部署不是补救措施。它是攻击者可以安坐其中的一个循环。

损害只是日常清理

现在是真正新的部分，也是这值得一篇文章而非一个标题的原因。

这里的破坏都不是勒索。没有勒索信。数据被销毁是因为删除它是攻击者自身工作流程的第二步。

Hermes 技能文件中有一个名为提取后清空数据库的章节。开头写道：“在提取并下载所有卡片数据后，分批清空源字段。”它建议使用分块的 PHP 脚本，因为“在单条 UPDATE 中处理数百万行 LIKE ‘%…%’ 会很慢”，这告诉你操作者预期的是多大体量的受害者。结尾写道：“清空后验证：再次运行检测查询——所有计数必须为 0。”

执行时的指令很简单：

不用了 现在dump那两个库的两个表 dump完清空（“never mind, now dump the two tables in those two databases, and empty them once the dump is done”）

在一家自行车零售商处，该 agent 创建了以 ZQ 为前缀的暂存表来存放它正在收集的数据。随后的清理操作删除了 180 张名称匹配 ZQ 或 Backup 的表。该模式也匹配了受害者自己的管理员创建的备份表，这正是值得深思的一句话：公司的备份被一名并非针对备份的攻击者摧毁，被一个在事后自我清理的例程摧毁，只因为这些备份位于同一个数据库中，并且恰好匹配了某个字符串。

这改变了什么

不是控制措施。上述攻击链会被每个团队早已熟知的手段挫败：参数化查询、哈希一次性验证码、上传验证、sudo 策略、root_squash、将机密移出配置文件，以及将加密密钥存放在数据库凭据无法触及的地方。

改变的是时间窗口，以及你为之规划的东西。

报告直白地指出了修复问题：在最大的软件供应商中，报告的关键漏洞如今每月超过 600 个，而攻击者实际利用的漏洞中约 87% 在公开当天或之前就遭到攻击。当利用在暴露后数小时内到来，而在复杂环境中修复耗时远超于此，仅靠补丁速度就不再是一种策略。

因此规划的问题变了。不是“我们如何避免这种情况”，而是“什么能恢复，以及多快恢复”。这归结为一个值得带到下次架构评审的问题，而且这是报告的问题，不是我的：

哪些系统构成了最小可行业务？

你需要维持收入运转的那一组系统。这很少是显而易见的，回答它意味着让应用负责人、基础设施团队以及介于两者之间的供应商就业务不可或缺的东西达成一致，然后证明这组系统能在这些条件下恢复。不是从与被删除的数据库位于同一数据库中的备份恢复。是恢复。

本文中的所有内容之所以为人所知，只有一个原因：研究人员恢复了操作者自己的服务器并读取了其中的内容。报告说明了哪些数字经过核实，哪些依赖于 agent 自己的说法，并指出真实规模可能比报告的更大。那是一份原始文件，也是本网站唯一依据的那类文件。

来源

• Gambit Security，Eyal Sela，Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign，2026 年 9 月 22 日。研究人员对自己调查的报告，也是上述所有说法的唯一来源。
• 报告本身引用的两个数字，此处按其归属方式标注：最大供应商中关键漏洞每月超过 600 个，以及约 87% 被利用的漏洞在披露当天或之前遭到攻击（a16z，Charts of the Week）。

欢迎指正，任何更正都会在本文末尾列出并注明日期。