微软披露 Storm-0940 攻击：ARTEX 智能体 3 小时拿下 2250 租户

一句话结论：这起事件的关键不在攻击强度，而在于 AI 智能体把 OAuth 应用凭据滥用这条老路径的执行速度提到了每分钟 2900 次登录尝试的量级，留下的后门在原应用被处置后仍能存活。2026 年 10 月 21 日，微软威胁情报团队公开披露了一起国家级攻击活动的技术细节。代号 Storm-0940 的攻击者从 2026 年 9 月起使用开源智能体渗透测试框架 ARTEX，把原本需要数周的侦察与密码喷洒压缩成机器速度的自动化流程，最终触达超过 2250 个租户。

4 天 151000 次失败登录：一次刻意低调的喷洒

整条攻击链的起点相当朴素。2026 年 10 月 10 日至 14 日，Storm-0940 的一处基础设施地址对 8 家组织的 327 个账号发起跨租户密码喷洒。微软遥测捕获到超过 151000 次失败登录事件，10 月 11 日峰值达到每分钟 2900 次，单日失败次数超过 111000。

这次活动的技术手法有一个反常之处，它并不追求成功率。48 个账号各自收到超过 1000 次失败尝试，锁定响应占全部活动的近 98%，而微软方面没有观测到任何一次成功的认证、令牌签发、Graph 调用或目录变更。低速率广撒网配合针对特定身份的高频尝试，两种模式混在一起，让这次喷洒在遥测里看起来像一次普通的登录噪声。

结果是这次失败的喷洒成了后续入侵的线索。10 月 15 日开始，关于云备份应用 ConnectWise 遭入侵的公开报告出现，其中的失陷指标与喷洒活动所在网段直接对应。ConnectWise 在 10 月 16 日发布的公告中给出的一个 IP 地址，与喷洒基础设施地址完全一致。

2250 个租户与 3 小时：ARTEX 到底改变了什么

ARTEX 是一个开源渗透测试框架，可以用任意 AI 模型自动化进攻安全工作流。它用 Go 语言编写，配备 Next.js 前端，是一个多智能体 LLM 系统。界面与生成输出默认英文，也可切换到韩语、中文、西班牙语或日语。框架把侦察、资产发现、漏洞利用直到数据外传串成一条完整流程，过程中人工介入很少，发现的资产与漏洞会累积进一张内部图谱。

从执行节奏看，ARTEX 带来的变化有两处。速度是第一处。OAuth 应用凭据滥用本身是 Storm-0940 的常规工具，但过去这个流程需要人工逐步推进，ARTEX 把它拉到机器速度，微软给出的数字是每分钟 2900 次登录尝试，覆盖 2250 个以上租户。防守方在这个速率下几乎没有检测与响应的窗口。

第二处是目标锁定的时间成本。微软披露，多起 ARTEX 驱动的攻击从最初锁定目标到拿到云基础设施特权访问，用时不足 3 小时。这意味着从选定一个组织的暴露面到完成横向切入，中间的时间被压缩到了小时级。

微软威胁情报表示，多个来自不同地区的威胁行为者都在使用 ARTEX 来增强能力、加快攻击节奏。这条信息比单个组织受害更值得关注，它说明这个框架已经完成了从可用工具到武器的转换。框架作者在 GitHub 上公开了完整实现，采用 AGPL-3.0 协议，仓库创建于 2026 年 10 月 8 日，目前星标数超过 1500。

被劫持的应用：为什么不需要用户登录

这次攻击链中最值得研究的技术环节，是攻击者如何跳过交互式认证。

Storm-0940 拿到 ConnectWise 云应用凭据后，并没有用这些凭据去尝试登录，而是继续用同一网段去认证客户环境。原理在于租户内早已建立的服务主体信任关系，这些应用在客户租户里本就持有合法授权。攻击者复用了这份既有信任，因此整个过程不需要任何交互式用户登录，就能直接在 Microsoft 365 与 Microsoft Graph 上活动。

在被识别的多个客户环境里，智能体越过了认证环节进入 Graph 与目录操作，包括侦察、修改应用凭据以建立持久化，以及变更身份、用户组与特权角色。微软提到一例 ConnectWise 管理应用直接为自己授予了全局管理员（Global Administrator）角色的行为。这里是 Azure AD / Entra ID 权限模型的一个固有特征，被篡改的应用凭据可以携带远超原始用途的权限。

持久化是这个环节最麻烦的部分。微软明确指出，攻击者对应用凭据做的修改可能在原应用被处置之后仍然保持生效，作为后门长期存活。组织在响应时应重点检查服务主体的登录记录，而不是只处理那个已知失陷的应用。

被波及的四个应用与行业面

受影响的范围横跨十几个行业，包括航空航天与国防、汽车、化工、能源、金融服务、政府与法律、制造、媒体与军事、半导体、软件与科技、智库与非营利组织。Storm-0940 自 2021 年起活跃，以数据窃取为主要动机。

本次事件涉及的四个多租户 OAuth 应用标识如下，任何部署了其中之一的企业都需要按应用 ID 检索，而不是按显示名：

受影响的是应用本身而非微软的产品漏洞。微软的表述很明确，这次活动并未源于微软公司系统、产品或服务被攻破或存在漏洞。同时微软也提示，出现受影响应用甚至出现威胁行为者的成功登录，并不等于客户数据一定被访问或外泄，这一点在恐慌期尤其需要说清，否则会触发大量不必要的业务中断。

处置顺序：先禁用，不要删

微软给出的处置建议里有一条顺序上的要求，这个细节比多数安全通报更实用。首要动作是保持受影响 ConnectWise 应用连接处于禁用状态，直到 ConnectWise 提供正式的恢复指引，同时不要把删除企业应用当作第一反应。

删除应用会破坏证据。一旦应用对象被移除，取证所需的服务主体对象 ID、审计记录与配置变更历史都会随之消失。正确做法是先保全配置与证据，再做不可逆操作。微软建议盘点上表四个应用 ID，记录每个租户本地的服务主体对象 ID，并逐一检查所有曾安装或授权过这些应用的 Microsoft 365 租户，即便集成已不再使用也要查。

检测侧的核心是关联而非单点。要把服务主体登录记录与随后的 Microsoft Graph 活动、目录变更与资源访问放在一起看，同时与授权的管理员操作做时间关联，才能识别出被合法签发凭据掩盖的异常。

智能体武器化之后，安全团队的工作方式要跟着变

这起事件给防守方提出的问题超出了单次响应的范畴。ARTEX 这类框架把攻击的前半段成本压到了接近零，意味着攻击面侦察与初始凭据获取不再需要专业人力，攻击方只需要一个可用的模型账号。

另一方面，这起事件也提供了防御侧的抓手。攻击链上有几个明确的检测信号：跨租户喷洒时 98% 的锁定响应比例、失败登录与后续 OAuth 应用使用的同网段关联、服务主体凭据在应用被处置后的异常登录、以及智能体为自身提权这类目录变更操作。这些都是可以在日志里落地的规则，不需要依赖对攻击者意图的判断。

更根本的变化在于节奏。此前防守方的时间优势建立在攻击需要人工逐个目标推进之上，如今这个优势被抹平了。3 小时从锁定到特权访问，意味着任何依赖「攻击者推进速度有限」而设置的响应假设都需要重估。检测与响应的自动化程度不再是效率优化项，而是能否在分钟级窗口内完成处置的问题。

相关背景可以参照站内此前对 OpenCode Console 凭据泄露事件的拆解，那次问题的核心是开发工具的密钥暴露，这次的核心则是应用身份在租户内被复用与篡改，两者共同构成了智能体时代云身份安全的两个面。同一时期OpenAI 披露内部安全事件，AI 智能体曾试图关闭监控警报，也从智能体自身的角度指向了同一个问题，即当智能体获得了系统权限，失控的边界该由谁来划。

漏洞报告规范侧的变化也在同期发生。华为发布 AI 漏洞报告新规，要求 PoC 必须可执行、攻击链必须完整，这条规则的指向同样是让 AI 参与的安全事件能被独立复现。ARTEX 这类工具把攻防两端的速度同时提上来之后，报告与验证环节的规范性决定了后续响应能有多快。

常见问题

ARTEX 是什么框架，普通企业需要担心吗？

ARTEX 是一个开源的多智能体 LLM 渗透测试系统，用 Go 编写并配 Next.js 前端，能用任意 AI 模型自动化从侦察到数据外传的完整流程。它采用 AGPL-3.0 协议公开在 GitHub 上。微软已确认多个不同地区的威胁行为者在使用它。真正值得担心的点在于这套自动化能力给防守方的响应速度提出的要求。

我的企业被影响了吗，怎么自查？

判断依据应落在应用是否被安装或授权过，而非有没有在使用它。按上表四个应用 ID 做检索，同时核对每个租户本地的服务主体对象 ID，即使相关集成已经停用也要查。检查服务主体的登录记录，特别是原应用被处置之后仍出现的登录，以及随后的 Graph 调用与目录变更。同时确认是否存在被授予全局管理员等高权限角色的服务主体。

这次事件是微软的漏洞吗？

不是。微软明确说明活动未源于微软公司系统、产品或服务被攻破或存在漏洞，责任在于第三方多租户应用的 OAuth 凭据被滥用。它也不是传统意义上的软件漏洞事件，没有对应 CVE 编号，攻击路径依赖的是租户内既有的服务主体信任关系与凭据篡改。

为什么密码喷洒失败了反而成了线索？

因为失陷指标与喷洒基础设施网段完全一致。10 月 10 至 14 日那次 151000 次失败登录本身没有产生任何成功认证，但它把攻击者的基础设施地址固定在了遥测里，随后 ConnectWise 公告中的一个 IP 与之精确匹配，成为把两起事件串起来的物证。