微软把 ConnectWise 供应链入侵归因 Storm-0940：ARTEX 智能体以每分钟 2,900 次尝试扫过 2,250 多个租户
微软 10 月 21 日归因 ConnectWise 入侵：Storm-0940 用 ARTEX 每分钟尝试 2,900 次登录，扫过 2,250 多个租户。
微软在 2026 年 10 月 21 日发布的一份威胁情报报告里，把 ConnectWise Cloud Backup 的供应链入侵归到 Storm-0940 名下，并称这个组织从 2026 年 9 月起就在用开源多智能体渗透框架 ARTEX 自动发起攻击。报告里有一个可核对的速率：在 ConnectWise 事件里，攻击者用窃得的应用凭据，以每分钟 2,900 次登录尝试触达 2,250 多个 Microsoft 365 租户。微软没有公布有多少租户真正被攻陷。
要点
- Storm-0940 被微软描述为「与中国政府关联」的组织（China-state aligned），2021 年起活动，此前主要靠密码喷洒和利用互联网暴露面应用的漏洞拿到初始访问，再往已有的 OAuth 应用里加凭据维持驻留。
- ARTEX 是 Go 写后端、Next.js 写前端的开源多智能体渗透框架，界面与生成内容默认英文，可切韩文、中文、西班牙文、日文；微软说它能从侦察一路自动做到数据外泄，几乎不需要人介入。
- 10 月 10 日至 14 日那轮密码喷洒对 8 家机构的 327 个账户全部落空：15.1 万次以上失败登录、10 月 11 日峰值每分钟 2,900 次失败、单日超过 11.1 万次、48 个账户各收到 1,000 次以上失败、锁定响应占近 98%，微软原文写「没有观察到任何成功认证、令牌签发、Graph 调用或目录变更」。
时间线
微软的叙述把两条时间线接在一起：一条是 ARTEX 这个工具本身的传播史，一条是 ConnectWise 的下游事故。
| 日期（UTC） | 事件 | 出处 |
|---|---|---|
| 2026-07-26 | trhhubsd/ARTEX 出现最早一次提交「chore: ARTEX 初始化」 | GitHub |
| 2026-10-04 | Wayback 存档的 Autumn-27/ARTEX 仍返回 200 | Internet Archive |
| 2026-10-07 | 同一地址的存档仍是 200 | Internet Archive |
| 2026-10-08 | 该地址的存档转为 404；trhhubsd/ARTEX 于 20:35 建仓 | Internet Archive |
| 10-10 至 14 | 144.172.64[.]99 对 8 家机构的 327 个账户做跨租户密码喷洒 | 微软 |
| 10-11 | 失败登录峰值每分钟 2,900 次 | 微软 |
| 10-15 | 公开报告出现 ConnectWise 被入侵，IOC 落在 144.172.64.x | 微软 |
| 10-16 | ConnectWise 发出首份公告 | 微软、ConnectWise |
| 10-17 05:01 | ConnectWise 公告 Cloud Backup 服务中断 | BleepingComputer |
| 10-17 07:00 | 停用 7 个应用身份并吊销相关凭据 | ConnectWise 指南 |
| 10-18 | ConnectWise 发布 15 页技术排查与处置指南 | ConnectWise |
| 10-21 18:23 | 微软发文；00:54、04:01 UTC 两次更新 | 微软 |
| 10-21 | ConnectWise 称开始分批恢复服务，预计需要数日 | CyberScoop |
ARTEX 的开源状态本身有一段插曲。微软在报告里称它为「开源渗透测试框架」，而原始仓库 Autumn-27/ARTEX 现在返回 404：Wayback 的抓取记录显示 10 月 4 日与 7 日还是 200，10 月 8 日起变成 404。现在能打开的是 trhhubsd/ARTEX，README 第 454 行自述「继续维护 Autumn-27/ARTEX」。这个仓库的 created_at 是 2026-10-08，最早一次提交却在 7 月 26 日，说明它是重新上传的镜像。截至 2026-10-22，它有 1,582 星、776 个 fork，许可证 AGPL-3.0。
智能体起了什么作用
微软把 ARTEX 在 ConnectWise 事件里的用途拆成三件：加速扫描与侦察、密码喷洒、以及在下游受害者身上滥用 OAuth 应用。这三件里，被微软单独拿出来量化的是对 8 家机构 327 个账户的那轮喷洒，结果是一次都没成功；微软同时说，另有一些 ARTEX 驱动的入侵确实拿到了云上特权访问。
进到客户租户里靠的是 ConnectWise 云应用被窃的凭据。这类应用身份在租户里早就拿到了客户当初授予的权限，认证走应用自己，不经过交互式用户登录，MFA 拦不住它。BleepingComputer 引述 Todyl 研究人员的说法：攻击者直接用备份应用的 secret 完成认证，继承的正是客户授给这个应用的那套权限。
微软写，攻击者控制多个 ConnectWise 云应用的身份之后，代表它行动的智能体继续用同一段 IP，冒充这些应用认证进客户环境，利用的是租户早已建立的信任。在部分环境里，智能体越过认证，做到 Graph 与目录层：侦察、修改应用凭据建立持久化、改动身份、组和特权角色。微软称在多个客户环境里看到了后续活动的证据，同时提醒「应用存在或被成功认证，不等于客户数据被访问或外泄」。
规模上，微软报告配图给的数字是 4 个应用凭据在不到 4 分钟里完成 200 多次登录；在若干次 ARTEX 驱动的入侵中，从选定目标到拿到云上特权访问不到 3 小时。报告里出现两个 2,900，含义不同：一个是 10 月 11 日的失败登录峰值，一个是对 2,250 个租户的尝试速率，都是每分钟。
租户数字对不上
2,250 这个数字最容易被读错。它指的是「被尝试登录的租户数」。关于成功比例，同一份报告前面「What’s happening」小节的最后一段末尾写着「大部分定向没有成功」（While the majority of the targeting wasn’t successful）；报告始终没有给出被攻陷租户数。CyberScoop 在 10 月 21 日的报道里直接写：微软没有说有多少客户被攻陷。
Huntress 给媒体的是另一套口径，统计窗口也不同。CyberScoop 10 月 20 日引 Huntress 首席安全运营分析师 Jonathan Semon：恶意基础设施的登录活动出现在近 1,000 个 Entra 租户里，其中 300 多次看似成功；Huntress 确认了 162 个租户的未授权登录。BleepingComputer 10 月 17 日的报道里，Huntress 说的是「至少 162 个被攻陷租户」，并在其监控的近 50 个租户里看到 Cloud Management 应用的服务主体给自己加目录角色，多数是 Exchange Administrator。ConnectWise 自己只公布了 7 个应用身份的停用时间，没给租户数。
四组数字——2,250、近 1,000、300 多、162——分别对应「尝试」「有登录活动」「看似成功」「已确认」，不能互换。更要紧的是，它们都是下限或单侧口径：微软没给被攻陷数，Huntress 也说自己看到的只是一个子集。
自查清单
如果你管着 Microsoft 365 租户，微软的 KQL 查询和 ConnectWise 的指南给的清单并不一样，这一点值得留意。下表按 2026-10-22 04:01 UTC 版微软报告整理：那一版把 KQL 里列应用 ID 的数组都改成了 3 个，「Inventory all four application IDs」这句提示语则留在页面上没有同步改，读的时候以数组为准。
| 应用 | 客户端 ID | 出现在 |
|---|---|---|
| ConnectWise Cloud Backup | 506e08f9-6e9a-4da4-942b-a099a03644ae | 两份清单 |
| Cloud Management - MS Teams | 24205314-2b89-4e07-a2a4-579e898a5640 | 两份清单 |
| Cloud Management - MS Graph | 0de14c77-b9b0-4137-9360-34878a929827 | 两份清单 |
| Cloud Management（主应用） | 2399d300-6fca-4e6a-a686-399fefe75b83 | 仅 ConnectWise |
| Cloud Management - Exchange Online | b78f6a77-d4e5-46fb-87e5-d1648bd02519 | 仅 ConnectWise |
| Cloud Management - Partner Center | 412dcf96-176d-4b3a-a1b0-4981ad66971e | 仅 ConnectWise |
| Cloud Management - SharePoint Online | b2b55f5b-7758-4719-8d8f-88ae172e6bdb | 仅 ConnectWise |
两份清单交集 3 个，并集 7 个：微软当前的三个 ID 全在 ConnectWise 的七个里，微软侧没有独有项。只跑微软那 3 个 ID 的查询，会漏掉 ConnectWise 列出的主 Cloud Management、Exchange Online、Partner Center 和 SharePoint Online 这四条。按 ID 匹配还有个别的原因：显示名对不上，微软查询里的注释把同样两个 ID 写作「ConnectWise - MS Teams」和「ConnectWise - MS Graph」，ConnectWise 那边叫「Cloud Management - MS Teams」与「Cloud Management - MS Graph」。
上一版（页面标注的最后更新时间为 2026-10-22 00:54 UTC）里还有第四个 ID：SkyKick Partner Portal（c921256f-04a7-44e8-9b2a-69c33929ba19）。Wayback 在 2026-10-21 18:42、22:44 和 10-22 02:03 的三份抓取里，这个 ID 各出现 4 次；10-22 04:46 的抓取里变成 0 次，同一时刻页面的最后更新时间也跳到 04:01 UTC。微软没有说明为什么撤下它，页面上也没留下说明。同一页的图 1 里仍写着「using 4 application credentials」，与三个 ID 的数组并列出现，微软没有解释这两处为何不一致。如果你在 10 月 21 日晚到 22 日凌晨照着那份报告排查过，这第四条是当时清单的一部分。
微软的其他要求：按应用 ID 搜而不是按显示名搜；先停用不要删除，保留配置和证据；审查范围从 10 月 15 日起，记录齐全的往前推到 10 月 1 日；把服务主体登录和 Graph 活动、目录变更放在一起看。ConnectWise 的指南补了两点：供应商侧的处置不等于租户侧配置已改，每个租户都要自己核；已签发的令牌在过期或被吊销前仍然可用。Entra 的登录与审计记录在免费版保留 7 天，P1/P2 保留 30 天，升级许可不会找回已经过期的历史。
编辑判断
这次归因把两件事分开了：「AI 加速」和「AI 造成」。密码喷洒那一轮留下 15.1 万次失败日志，一次都没成功；打开局面的是被盗的应用凭据。ARTEX 改变的是拿到凭据之后的速度——把跨租户认证、Graph 侦察、加凭据、改角色压缩到几分钟里，让防守方来不及在告警和处置之间做出协调反应。
有一处仍然空白：ConnectWise 的凭据是怎么被拿走的。微软没有说，ConnectWise 对 CyberScoop 的提问也未作答。所以「ARTEX 攻破了 ConnectWise」目前的证据只到「ARTEX 被用于下游」，这两件事不能混。
这个工具不是第一次出现。微软自己在报告里写，2026 年 10 月的公开报道已指出 ARTEX 被用于针对韩国金融机构的个人数据泄露事件。Recorded Future 的 Insikt Group 把韩国这批攻击背后的团伙追踪为 TAG-217，称它早在 2026 年 8 月就开始测试基础设施、拼装工具；据该报告引述的公开报道，泄露涉及至少 7 家金融机构、6.8 万人的个人数据。微软与 Recorded Future 各自给这两批活动起了代号，也没有说它们是否同一批人，能确定的只是同一个框架在一个月里被两拨人用了。
对读者的判断很直接：这件事的教训落在身份治理上，不在模型防御上。共享给第三方的多租户应用、长期不过期的应用凭据、装在几百个租户里的备份工具，这三样叠在一起，就是这次被放大的东西。如果你只做一件事，按应用 ID 把租户搜一遍，确认那些早就不用的集成确实已经停用。
我们此前写过 Cairn 智能体面板被恶意使用，也写过 LiteLLM 发布链被植入窃密器。三起事件的共同点是凭据、面板或发布链先失守，智能体再把后果铺开；CSO Online 那篇复盘说的也是这一点。
接下来值得盯的：ConnectWise 的分批恢复能否兑现、是否有租户确认数据被读取、以及微软会不会公布被攻陷租户数。