微软披露ARTEX案例：AI代理5分钟从GitHub密钥打到Azure Key Vault

2026年11月5日，微软威胁情报团队在官方安全博客上公开了一组云端入侵案例。一个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等工具。

真正让防守方头疼的，其实不是它用了哪些工具，而是它怎么把这些工具串起来、自己拿主意。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真正的遗产或许不是它造成了多大破坏，而是它留下一份可重复的蓝图——多智能体框架怎样被一步步组装成端到端攻击链，它演示了一遍。在这之前，这类能力大多还待在安全研究者的实验室里。据微软博客，如今它已被国家级行为者和普通金融犯罪团伙同时武器化，这条路径算是被验证为可规模复制了。