攻击者把AI从助手变成流水线:六小时可跑完凭据窃取

|作者: QUASA 编辑团队|2 分钟阅读| 3
攻击者把AI从助手变成流水线:六小时可跑完凭据窃取

Google Threat Intelligence Group(GTIG)于2026年9月8日披露一宗发生在2026年第二季度的真实事件:疑似以牟利为目的的攻击者在控制一家机构的云基础设施后,利用AI编码聊天机器人、提示词和智能体指令,不到六小时便规划、搭建并执行大规模凭据收集。9月9日发布的 TNGlobal报道 确认,该框架处理了漏洞扫描、凭据收集、故障排查和IP轮换,并获得数千个第三方凭据。

这并不是AI自行选择目标、取得入口并独立完成整场入侵。IT Pro的独立报道 显示,攻击者先控制云基础设施,再部署自主多智能体框架;公开信息没有说明受害机构、具体模型或最初访问手段。因此,“六小时”证明的是凭据窃取流程可以被显著压缩,而不是AI已经实现无人参与的端到端攻击。

六小时内,人工目标变成批量作业

攻击者从已失陷云资源启动多智能体流程,自动完成扫描、排错、IP轮换与凭据收集

这条攻击链的变化不在于凭据窃取本身,而在于攻击者把原本需要持续操作的步骤连接成能够自行维持的工作流。人工仍然负责取得云资源、确定目标并交付提示词和Markdown操作指令;此后的规划、扫描、收集与故障处理则由框架连续推进。

  1. 建立立足点:攻击者控制机构的云基础设施。公开材料没有披露最初访问方式,也没有证明AI完成了这一步。
  2. 交付任务:操作员向AI编码聊天机器人提供提示词、智能体指令和预先配置的Markdown操作手册。
  3. 编排扫描:框架安排漏洞扫描和凭据收集任务,把扫描结果继续送入后续处理环节。
  4. 自行排错:任务失败后,系统实时诊断问题并恢复运行,减少等待人工查看日志、修改参数和重新启动的时间。
  5. 轮换出口:工作流通过受害者的云基础设施切换IP,使攻击流量能够从合法云地址发出。
  6. 批量收集:规划、搭建和执行阶段合计不到六小时,最终取得数千个第三方凭据。

公开报告的摘要把“控制云资源”与后续活动连写,但案例详述只明确表示规划、搭建和执行凭据收集发生在不到六小时内。由于最初访问的时间戳没有公布,不能把六小时解释为从首次侦察到全部窃取结束的完整驻留时间,也不能将其外推为其他AI攻击的固定速度。

“自主”指执行自治,不代表攻击意图自主

传统聊天助手通常完成单次请求,例如生成脚本或解释错误,后续步骤仍由操作员拼接。这个案例中的系统则持续读取操作手册、分配任务、处理失败并维持扫描管线;人的角色从逐项操作转为设定目标、准备运行环境和启动流程。

这一区别解释了标题中的“流水线”:强度来自多个既有动作被连续编排,而不是模型获得了独立攻击动机或新的未知漏洞能力。GTIG同时表示,尚未在真实目标上观察到由威胁行为者部署、能够完全自主利用未知漏洞的端到端攻击管线。

对防守方而言,真正改变的是反应时间。若身份、网络和云平台告警仍依赖多个团队人工转交,一项异常从发现到完成确认的时间,可能已经覆盖攻击者规划、排错和批量收集的整个窗口。

编码助手与CI/CD构成另一条独立攻击面

恶意CI/CD任务提取OIDC令牌、修改编码助手配置并删除执行记录

六小时案例之外,同一季度还出现了针对开发工具和软件供应链的独立活动。GTIG的原始报告 记录,UNC6780(又称TeamPCP)的DUSTMAKER恶意程序会在.claude、.vscode和.cursor等项目目录中投放或修改配置,以诱导AI编码助手在开发者日常操作中执行命令。

DUSTMAKER还可在GitHub Actions运行器的进程内存中提取OIDC令牌,借受信任发布者身份发布带有效SLSA Build Level 3证明的受污染软件包。在遭控制的CI/CD环境里,它会创建名称类似“Copilot Setup”的恶意任务以寻找更多令牌和密钥,并通过API删除工作流执行记录。

这些行为与六小时凭据窃取并非同一条攻击链,不能合并归因。两组观察的共同点是:一旦合法的云工作负载、自动化身份或开发配置遭到控制,恶意操作便能混入正常工程流程,单靠来源IP、任务名称或软件包证明不足以判断活动是否可信。

日志需要关联四类机器速度异常

安全团队在六小时时间轴上关联云扫描、秘密读取、API注册、GPU消耗和CI/CD日志删除异常

安全团队无法仅凭一个“AI攻击”标签识别这类行动,因为可观察对象仍是身份、网络、计算资源和流水线任务。以下监控映射是依据已披露行为得出的防守建议;单个信号可能有正常解释,短时间内跨系统连续出现才更值得升级调查。

  • 身份与秘密:服务账号突然读取大量陌生项目、密钥库或租户中的秘密;读取后紧接着出现批量验证、权限枚举、令牌交换或新会话创建。
  • 云网络:原本承担内部业务的工作负载开始扫描大量外部地址,出口IP频繁切换,失败任务在参数变化后立即重试。由于流量可能来自受害者自己的云地址,不能只按IP信誉放行。
  • API与计算资源:新建或被劫持的账户在短时间内发起密集API调用,或者云实例、GPU配额和推理工作负载突然偏离既有时段与用量基线。账户创建、身份登录、配额变更和费用异常需要放在同一时间轴中检查。
  • 代码与CI/CD:AI助手配置目录出现未经评审的文件,流水线任务读取运行器令牌、异常发布软件包,或者执行记录通过API被删除。任务名称看似属于AI安装工具,不应替代对其权限和行为的验证。

最接近已披露工作流的形态,不是一次高CPU或单次登录失败,而是一段紧密的事件序列:云工作负载扩大外联范围,自动化身份大量读取秘密,凭据验证随即加速,任务失败后马上恢复,同时审计记录出现缺口。检测规则应保留这些事件的共同身份、资源和时间关系,避免各平台只处理自己的孤立告警。

受害者、模型与起始时间仍未公开

目前能够确认的是,GTIG和Mandiant在事件响应中观察到疑似牟利攻击者使用多智能体框架,并在云基础设施遭控制后,将大规模凭据收集的规划、搭建和执行压缩至不到六小时。AI在执行阶段承担了扫描管理、实时排错和IP轮换,但攻击目标、初始条件与操作指令仍由人提供。

尚未公开的信息包括受害机构、最初访问手段、具体模型、各阶段精确时间戳,以及被窃第三方凭据的类型和后续用途。除非受影响机构或其他调查方公布取证材料,这些数量和归因仍主要建立在Google的私有遥测与事件响应视野之上;现阶段最稳妥的结论,是攻击者已经能把入侵后的重复劳动交给AI流水线,而不是AI已经取代人类完成整场攻击。

分享:

订阅我们的新闻通讯

将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。

0