Palo Alto Networks Unit 42上个月披露的一起案例看完之后我沉默了很久。不是因为攻击手段有多高明——没用零日漏洞全是配置暴露、硬编码凭据、过度权限这些企业安全的老熟人。真正让人后背发凉的是速度和方式多个AI Agent分工协作10个小时内从公网Web服务一路打到企业根权限、劫持CI/CD、控制AI基础设施最后还留下了一份80页的安全审计报告。传统红队干两周的活AI Agent一个工作日不到就干完了。这篇我不做翻译。Unit 42的报告基于海外企业但国内企业在配置债务、权限管理、CI/CD安全、AI基础设施治理这些方面问题往往更突出。我先把攻击链拆开讲清楚再说说我们该补哪几道防线。攻击全景Unit 42原文的定性是AI辅助入侵事件不是严格意义上的勒索软件攻击。但行业讨论中普遍用多Agent勒索攻击来指代——攻击者最终确实进行了勒索谈判而且破坏深度和勒索攻击相当。整个攻击从初始访问到核心系统控制权压缩在不到10小时内映射到超过50种MITRE ATTCK技术。没有用零日。全是已知问题。那AI到底做了什么把这些老问题串成了一条全自动的攻击链而且是多线程的。进去先画图初始访问来自一个公网可访问的Web服务/API端点的配置暴露。进去之后侦察Agent开始自动测绘内部微服务架构——有哪些服务、跑在什么端口、互相怎么调用、用什么认证方式。传统人工渗透里这一步往往要花几天。AI Agent几个小时就能把内部架构图画出来。挖代码仓库的金矿拿到内部服务地图下一步是扫代码仓库。硬编码的token、服务账号密码、API密钥——这些东西在企业代码库里几乎从不缺席。Unit 42观察到一个很有意思的细节Agent之间用结构化的Markdown文件传递信息。侦察Agent把发现的资产清单写成Markdown凭证收割Agent读取后继续深挖。Python缓存、配对资产文件夹这些痕迹都是AI执行的典型特征。从能读代码到能管一切这是攻击链上最关键的一步。从代码仓库挖出的凭据被用来进入企业的密钥管理系统。进去之后进一步获取master admin凭据最终拿到整个系统的root级访问权限。从能读几行代码到能控制整个基础设施中间只隔了一个密钥管理系统。而这个跳板往往就是用硬编码的凭据搭起来的。劫持流水线偷云密钥有了代码仓库权限Agent就开始动CI/CD的主意。它劫持了企业自定义的工作流触发未授权构建从构建环境里窃取云访问密钥。它还试图修改Terraform配置植入后门——这是整个攻击中唯一失败的一步因为分支保护规则阻止了变更。后面我们还会回到这个细节。它很重要。用你的算力打你拿到云密钥之后攻击者做了一件很鸡贼的事用受害者自己的AI端点作为后续攻击的基础设施。控制流量混入正常的模型调用中既省了算力成本又增加了监控识别难度——在企业看来那就是正常的AI API调用而已。打完还留一份体检报告攻击结束后Agent还留下了一份80页的技术审计报告详细记录了被利用的漏洞、访问过的系统、发现的安全弱点。这东西既是勒索谈判的证据也从侧面说明AI不只会执行攻击步骤还能自动生成文档、审计报告、攻击后分析材料。AI到底改变了什么很多人看完这个案例的第一反应是这不就是常见的攻击路径吗有什么新鲜的确实每一步单独拎出来都不新鲜。公网服务配置暴露是老问题代码仓库硬编码凭据是老问题密钥管理权限过大是老问题CI/CD流水线配置不当还是老问题。新鲜的是速度、并行度和自适应能力。过去一个人类红队干两周的活AI Agent10个小时干完。不是快一点是从根本上改变了攻防双方的时间关系——攻击方几小时内完成全链路防御方可能刚收到第一条告警。还有一个更隐蔽的变化自适应决策。传统攻击脚本是死的遇到障碍就卡住了。AI Agent不会——它会分析失败原因调整战术换一条路继续走。Unit 42的核心判断就是Agent能够监测结果、评估下一步、实时重新规划这是观察—评估—行动—再规划的自动化循环。对防御方来说这意味着你不能再依赖攻击路径是可预测的这个前提了。过去的检测规则基于已知路径现在AI Agent可能走出一条你从没见过的组合。国内企业的风险可能更大我为什么说这个案例对国内企业的警示更大因为根据我接触到的情况国内企业在几个关键环节上的欠账更多。代码仓库里的硬编码凭据国内很多企业尤其是快速发展的创业公司和传统企业的数字化部门代码仓库里的硬编码凭据问题非常普遍。赶项目的时候直接把数据库密码、API密钥写在代码里上线了忘了删然后代码一传上去就再也没人管了。Unit 42这个案例里凭证收割是攻击链的关键第二步。如果代码仓库里到处都是密钥攻击者进去之后就是进了金矿。密钥管理系统有但用不对很多国内企业也上了密钥管理系统Vault、云厂商的KMS之类的但用法往往有问题管理账号权限过大一个账号能看所有密钥密钥生命周期太长几年不轮换审计日志开了但没人看最关键的——还是有很多团队嫌麻烦继续用硬编码密钥管理系统本来应该是防线结果配置不好反而成了攻击链上的跳板放大器。CI/CD安全普遍薄弱国内DevOps普及很快但CI/CD的安全往往没跟上。流水线权限过大一个构建任务能访问整个云账户自定义工作流缺乏审核谁都能改分支保护形同虚设或者只在主仓库开了旁支没开IaC的变更没有强制多人评审。Unit 42案例里唯一挡住攻击的防线是什么分支保护规则。Terraform后门植入尝试被分支保护阻止了。就这么一个简单的预防性控制在AI加速攻击中仍然有效。AI基础设施基本不设防这是最新、也是最容易被忽视的攻击面。国内企业现在纷纷上AI——大模型API、RAG系统、Agent平台、MCP网关……但这些AI基础设施的安全治理几乎是空白。API key谁都能申请没有用量限制模型调用日志不全出了问题查不到AI工具集成权限过大没人把AI端点当作需要监控的核心基础设施。攻击者劫持企业AI端点、把控制流量混入正常调用中如果安全团队根本不监控AI基础设施那这种手法几乎就是隐身的。该补哪几道防线说了这么多问题说点实际的。结合这个案例和国内现状我觉得有五道防线最该优先补。先把代码仓库的凭据清一遍别嫌麻烦。Unit 42的攻击链里凭证收割是从外围到内部的关键转折点。用gitleaks或者truffleHog这类工具扫一遍所有代码仓库历史和当前的硬编码凭据都找出来。新提交强制过凭据扫描有问题直接拦。历史提交里的密钥也要处理——不是删了就行要立即轮换已经泄露的。这是投入产出比最高的安全投入之一没有之一。给密钥管理系统真正上锁密钥管理系统不能只是有还得管好。最小权限原则每个服务只能拿自己需要的密钥不能看全部。短生命周期密钥自动轮换不要一用好几年。访问审批高权限密钥的访问需要多人审批。全面审计谁在什么时候访问了什么密钥日志要全还要定期看。密钥管理是企业安全的命门。命门上的锁不结实其他防护再厚也没用。CI/CD和IaC锁死Unit 42案例里唯一成功的防御是分支保护。这个细节值得反复说。所有生产环境相关的IaC仓库强制开启分支保护和多人评审。CI/CD流水线权限最小化构建任务只能访问它需要的资源。自定义工作流的修改需要审批不能谁都能改。定期审计CI/CD中的密钥和权限配置。这些都不是什么高深技术就是基础的DevSecOps。但在AI加速攻击的时代基础防线的价值反而更高了——AI再聪明也绕不开一个强制开启的分支保护规则。把AI基础设施纳入安全治理这是很多企业现在完全缺失的一块。立刻要做的清点所有AI资产模型端点、API key、MCP网关、AI工具集成都要纳入资产清单。给API key设rate limit和用量告警异常调用自动冻结。开完整的诊断日志——谁在调用、调用了什么、用了多少token。监控异常行为突发的请求暴增、奇怪的401/200快速切换、平时不用的身份突然开始调模型。AI工具集成的权限也要最小化。不要给Agent能做的都给的权限只给它完成本职工作需要的。AI基础设施已经成了新的攻击面。你不监控它攻击者就会利用它。响应速度从天级提到小时级传统安全响应流程是告警→值班人员研判→升级→各团队分别处理。这个流程通常按天算。但AI攻击是按小时算的。10个小时就能从公网打到根权限你按天级响应的话黄花菜都凉了。怎么改建设自动化处置剧本——检测到凭证泄露自动撤销冻结CI/CD隔离云账号同步动作不是串行。减少长寿命凭据多用短期token和即时权限。非人身份治理要加强——服务账号、API key、Agent身份这些都是现在的薄弱环节。告警要跨系统关联不要孤立地看代码仓库告警、密钥管理告警、云告警要把它们串起来。Unit 42这个案例最让我感慨的不是AI有多厉害而是那些我们说了很多年的基础安全问题在AI时代反而变得更致命了。硬编码凭据、过度权限、CI/CD配置不当、密钥管理松散——都是老问题。过去这些问题可能需要一个熟练的攻击者花几周才能利用完现在AI Agent几个小时就能走完。攻击的技术本质没有变但时间尺度完全变了。这对防御方来说既是坏消息也是好消息。坏消息是你反应慢了根本来不及。好消息是防御不需要什么黑科技把基础防线筑牢就能挡住很多AI加速的攻击。就像那个被分支保护拦住的Terraform后门——一个最简单的预防性控制在AI时代仍然有效。AI不会让安全变得完全不一样。它只会放大你已经有的问题好的坏的都一样。所以别等了。先把代码仓库的密钥清了把分支保护开了把AI基础设施的监控加上。这些事情今天就能开始做。