同一天，微软威胁情报团队在官方安全博客上公开了一组云端入侵案例。一个AI代理全程无人介入，先扫描GitHub公开仓库里暴露的密钥，再完成Azure Key Vault数据外泄，耗时不足5分钟。干这件事的工具叫ARTEX，是一套开源多智能体攻击框架；用它的人里，有被微软标记为Storm-0940的中国国家级攻击组织，也有柬埔寨金融犯罪团伙Storm-3358。
微软披露的时间线说明，这种大规模滥用不是突然冒出来的。微软官方博客显示，ARTEX相关的扫描活动最早能追到2026年8月；到了10月，攻击烈度明显上了一个台阶——2026年10月28日，微软记录了首批成功的服务主体登录，所用IP地址是199.19.77[.]84。Storm-3358针对金融机构的攻击则一直持续到11月6日，前后超过两周。
一个AI代理如何自主打穿云端防线
5分钟这个数字到底意味着什么，得先看ARTEX是怎么搭起来的。安全研究机构分析称，ARTEX用Go语言编写，是一套多智能体渗透测试与命令控制平台，带Next.js web控制台；代码最早由GitHub上一位名叫"Autumn-27"的开发者公开，原本定位是给安全团队自测授权系统用。工具里内置了多个子代理，分工覆盖侦察、认证、枚举、横向移动等阶段，还能调用Nmap、curl、wget、Python HTTP客户端以及无头浏览器Chromium等工具。
但真正让防守方头疼的，不是ARTEX用了哪些工具，而是它怎么把这些工具串起来、自己做决定。aviatrix.ai援引微软数据描述了攻击链的走法：ARTEX代理先自动扫公开GitHub仓库，找出里面暴露的应用程序密钥、API令牌和OAuth凭据；找到有效密钥后，马上以服务主体身份向Microsoft Entra ID发起认证；认证一过，代理就去枚举Azure订阅、资源组和AI模型部署情况，从Azure Key Vault、App Service配置和AKS集群里抽出更多凭据；接着横向移动到Azure资源管理器、SharePoint、OneDrive乃至Azure DevOps，并滥用被攻陷的OAuth应用和
Azure AI服务建立持久化控制。
这条攻击链最关键的特点是自适应。微软数据显示，API调用失败时，代理大约28至80秒内就会自动换参数重试；登录尝试的高峰期达到每10秒24次——这个速度人手根本跟不上，却又不会撞上传统的速率异常报警阈值，因为每次尝试用的都是真实、已确认有效的凭据。
损失的量级与受影响范围
受影响组织的完整名单目前还没全部公开。安全公司Todyl分析称，确认被波及的组织约为18家。已披露的具体案例里，微软记录到81次明确的文件下载行为，约2279项邮箱条目被访问。还有一起典型案例：一家托管服务提供商的客户在10分钟内产生了数千美元的Azure AI使用费——被攻陷的凭据被拿去大量调用Azure AI服务，充当后续攻击的算力来源。
Storm-3358的目标不太一样。这支柬埔寨金融犯罪团伙把ARTEX和匿名文件上传漏洞、服务端请求伪造（SSRF）漏洞搭配使用，装上WISP、vshell和AdaptixC2等开源远程访问木马，图的是更长期的持久化驻留，主要下手对象是东南亚金融机构。
ARTEX框架调用的AI模型并不固定。Check Point分析了10起曝光案例，其中DeepSeek系列中文模型出现频次最高。微软官方博客则明确说，ARTEX可以调用任何AI模型——也就是说，防守方没法靠"锁定特定模型"的办法封堵这类攻击。
从工具到行为者：一道被跨越的门槛
把ARTEX案例和此前AI辅助攻击的历史摆在一起看，才能体会这次事件的分量。过去多年，安全研究界反复讨论的是"AI帮攻击者写更好的钓鱼邮件""AI协助分析代码漏洞"——决策的还是人，AI只是效率工具。ARTEX案例则指向另一个阶段：AI代理成了自主决策者，从侦察到认证再到横向移动，每个环节都由代理根据上一步结果自己触发下一步，全链路闭环，中间不需要人类操作员确认。
攻击的成本结构也因此彻底变了。以往走完一次从信息收集到凭据利用再到数据外泄的完整入侵链路，得有多名不同技能的攻击者投入数小时人力，每个阶段还要人工研判。5分钟的全自主闭环意味着，同样的攻击可以并发对准数百个目标同时跑，边际成本接近于零。
防守方遇到的困境是对称的：传统检测逻辑建立在"行为异常"这个假设上，可ARTEX代理的每一步——服务主体登录、API调用、资源枚举——形式上跟正常业务行为很难区分，凭据是真的，请求格式也合规，只有节奏和上下文的组合才会露馅。这要求检测体系从单点规则转向行为序列建模，而大多数中小企业的安全栈里，这类能力并不成熟。
谁的压力最大
从利益相关方角度拆开看，这次事件带来的压力分布并不均匀。
对云服务提供商来说，压力集中在平台层面的信任链：ARTEX案例说明，一个暴露的服务主体凭据就能被用来横向访问多个下游租户——这是多租户架构自带的传播风险。微软已在博客中建议用户扫描代码仓库中的暴露密钥、用托管标识替代服务主体密钥、执行最小权限策略，并部署能识别异常API请求速率的行为检测。
对开发者和工程团队来说，GitHub仓库里的密钥管理习惯，基本就决定了攻击面有多大。ARTEX每次的入口都是GitHub上已经公开的凭据，这不是什么零日漏洞，而是存在了好些年的配置错误。不同之处在于，过去要利用这类错误，得靠人工去搜、人工去判断；现在AI代理能在几秒内完成大范围扫描并排好优先级。
安全团队这边，压力更多落在制度上。现有安全审计的周期、事件响应的流程，设计时都默认攻击者需要时间，留给防守方检测和响应的窗口以小时计。可完整入侵链路被压到5分钟以内之后，靠定期人工巡检或者批处理告警的体系，规则写得再细，也拦不住事中的攻击。
接下来的信号
ARTEX框架的原始仓库已在2026年10月被作者下架。但据报道，ScopeWeaver和商业版ARTEX PRO等多个分叉版本仍在流通，工具并非拿不到了，只是门槛稍微抬高了一点。往后可以盯两个信号：一是此后几个月里，同等自动化程度的多智能体攻击框架被滥用的案例报告频次；二是云厂商会不会推出针对服务主体高速API序列的原生异常检测——如果这类能力是“默认开启”，而不是塞进附加的高级套餐，那就是防御跟进的明确信号。
把周期拉长看，ARTEX真正留下的东西，可能不是它造成了多大破坏，而是一张可以重复使用的蓝图：多智能体框架怎么被一步步组装成端到端攻击链。在这之前，这类能力大多还待在安全研究者的实验室里。据微软博客，如今它已被国家级行为者和普通金融犯罪团伙同时武器化，说明这条路径已经被验证可以规模复制。
