ConnectWise：应用一把钥匙，租户一排大门

备份应用需要对租户有很大的访问权限：每个邮箱、每个 OneDrive、每个 Team 都要读。在 Microsoft 365 里，这份权限挂在厂商的多租户应用上。所以厂商的应用密钥，就是所有点过“接受”的客户的万能钥匙。

这次，攻击者拿到了 ConnectWise Cloud Backup 应用的一个 API 密钥（也就是原来的 SkyKick 产品）。厂商侧凭据被用于给已授权的客户租户申请 Microsoft Graph 令牌。ConnectWise 除 Cloud Backup 外还禁用了六个 Cloud Management 身份，这不代表全部七个都遭到滥用。Huntress 报告了 Teams、Exchange Online 和 SharePoint Online 应用遭滥用；Teams 应用给自己授予了全局管理员，并向其他应用添加凭据。

Huntress 在大约 1000 个 Entra 租户里看到了攻击活动，其中 300 多个登录成功，并在两个租户里确认了入侵后活动。THN 较早报道的 173 个租户尚未作为总数得到核实，不能与 Huntress 的登录计数混用。有没有数据被盗目前还不清楚。Graph 的目录读取操作不会留下审计记录，所以这里的“没有证据”不等于“什么都没发生”。

10月22日更新： 微软将事件归因于与中国有关联的 Storm-0940，并披露该攻击者借助 ARTEX 尝试访问超过 2,250 个租户。这是访问尝试涉及的数量，不是更新后的确认受害者总数。微软在部分环境中观察到后续凭据和角色变更，但明确表示仅凭认证成功不能证明数据被盗。应保留证据、禁用受影响连接，并在重新授权前检查其他应用凭据是否被植入持久化后门。评级保持 L4。

10月24日更新： 厂商 10月23日 14:00 UTC 通知明确，恢复测试和安全验证仍在进行。10月21日开始分阶段恢复工作，不代表客户功能已经可用。ConnectWise 预计周末结束前完成验证，下周初先开放现有备份还原，随后恢复完整服务注册。这些是附带条件的计划，并非已确认的恢复日期。收到对应服务的厂商指引前，应保持受影响应用连接禁用，并继续逐个调查租户；厂商恢复服务不能清除租户中的持久化访问。

11月1日更新（UTC）： 厂商10月28–30日通知取代了此前附带条件的恢复预测。已重新授权的 M365 租户可进行备份及还原，客户门户和备份监控面板也已恢复。Backup Health 报告、导出任务和计费功能仍在恢复；通知将在支撑服务就绪后恢复。应重置门户密码、配置 MFA，并按 Trust Center 指引通过新的 ConnectWise Cloud Backup for M365 应用逐租户授权。未经厂商明确要求，不要重新启用已禁用的旧应用。须确认新快照成功完成：注册不能消除历史备份缺口，也不能替代租户持久化访问调查。厂商仍表示，保留的备份归档及其他 ConnectWise 产品没有遭入侵的迹象；这是其调查进展，并非独立安全保证。

Huntress 补充分析： 其10月27日更新链接的后续报告将已观察到的自动化与 AI 归因分开。Huntress 仅凭自身遥测，对 LLM 参与的置信度为低至中等；结合微软归因后为中至高，不能独立核实 Storm-0940 或 ARTEX。缺少 Graph 请求日志使读取活动无法重建。应检测权限授予与凭据植入，保留详细日志并跨租户排查，不能把请求速度或 IP 命中当作使用 AI 或入侵的证明。后续报告未修改确认受害者总数，也未证实数据窃取。

11 月 4 日恢复补充（18:55 UTC）： Backup Health 报告、导出任务及 Marketplace API 已于 11 月 3 日恢复；计费、平台面板的部分内容和通知仍未全部恢复。备份、还原可用仍以逐租户重新授权为前提，必须看到新快照成功完成。此次 FAQ 明确更正此前笼统的门户密码重置指引：使用 Microsoft 365 认证登录的客户无需重置密码，而须管理员同意新应用权限。SaaS Security／Cloud Automation 的 M365、Azure 集成及活动迁移项目需分别重新授权。保留日志并继续逐租户调查；厂商没有访问客户租户审计日志，不能替客户确定是否遭入侵，初始应用凭据取得机制仍在调查。旧 c921256f-04a7-44e8-9b2a-69c33929ba19 应用仅可按上述条件删除，不代表可以重新启用旧应用。