这次出事的不是被保护的客户，是那家「负责保护」的备份厂商。
ConnectWise 的 Cloud Backup（原来的 SkyKick）平台，凭证被拿去以「应用身份」登录进客户的 Microsoft 365 租户。Huntress 那边先看到异常登录，到 2026-10-16 19:00 UTC 为止，确认有 162 个租户存在未授权登录。
我把细节抄一遍，因为这几行比任何结论都说明问题：
- 手法：Cloud Backup 这个应用，用关联 ConnectWise 自己租户的凭证，去换 Microsoft Graph 的访问令牌。认证来源 IP 是 144.172.64.128，时间 10/15 06:13–08:34 UTC。这个 IP 属于某家托管服务商，并不是该应用平时通信用的那段 Azure 私有 IP。10 月 19 日又追加了两个 IP：144.172.64.99、144.172.64.60。
- 为什么难防：应用级认证不走用户密码，也不触发 MFA。凭证存在厂商自己的环境里，客户在自己租户里根本「生成不出来」，自然也难自查。
换句话说，你为了让它能备份，给了它最大权限；结果这处权限一旦漏了，等于把门钥匙连同备用钥匙一起给了出去，而且这道门还不响警报。
事情还不止一层。Huntress 发现第二个应用 Cloud Management for Microsoft Teams，在一个合作方租户里给自己授了 Global Administrator，又给另外两个应用（其中一个是该合作方专用的 Huntress 应用）加了凭证，整个过程差不多 5 分钟。是不是同一拨人干的，目前还没确认。
ConnectWise 的动作是：10 月 17 日禁用了 7 个应用身份、吊销了相关证书，并暂停了 Cloud Backup、SaaS Security、Cloud Management。但有一句提醒得划重点：禁用只挡「新的认证」，不会自动回滚客户租户里已经被做的改动；已经签发的令牌，在过期前还可能继续能用。
数据面上，现有备份归档还是加密隔离的，官方说没有迹象被攻破；有没有发生数据窃取，Huntress 也没确认——它详查的那个租户没有邮件、文件访问记录，但也提醒：部分 Graph 目录读取本来就不留审计痕迹。
这事给运维的自查清单，其实就几行：应用登录记录、应用凭证、目录角色、consent 授权、策略变更、邮箱转发这类持久化手法。真正要问自己的是一句：为了备份、为了自动化，我到底给应用身份开了多大权限？它现在还能凭旧令牌进门吗？
我自己是这么看的——批量管理工具、备份、监控，这些「为了省事」而给出去的常驻权限，比一次性的管理员登录更值得盯。平时用七亿批量远程管理工具做巡检只是图快，但「谁持有什么权限」这张账，工具替不了你，得自己定期摊开对。
前阵子写过两个同类的入口失守，可以一起看：堡垒机自己门没锁：JumpServer 普通账号一个参数，拿走管理员 Access Key、AI 删库不是它手滑，是那个 token 一开始就给多了。三篇主题都一样：权限给出去容易，收回来难。
评论