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等工具。
但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的真正遗产可能不在于它造成了多大破坏，而在于它给出了一个可重复的蓝图——展示了多智能体框架如何被系统性地组装为端到端攻击链。在此之前，这类能力更多停留在安全研究者的实验室里；而现在，据微软博客，它已被国家级行为者和普通金融犯罪团伙同时武器化，意味着这条路径已被验证为可规模复制的。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接