备份应用密钥泄露波及数百租户

备份服务需要读取邮件、文件和 Teams 数据，企业通常会在接入时一次性授予权限。问题是，如果供应商持有的应用密钥泄露，这份长期授权也可能被攻击者接手。原文追踪的 ConnectWise Cloud Backup 事件中，Huntress 截至 2026 年 10 月 17 日统计到超过 300 个租户出现成功登录。

这起事件值得程序员关注的地方，是攻击者用应用自己的身份登录，整条路径没有用户参与，MFA 也就没有验证对象。处置因此不能停在禁用供应商应用，还要查它是否给其他应用留下了新凭据。

一次接入授权，为什么会变成长期入口

ConnectWise Cloud Backup 曾以 SkyKick 的名称销售，由托管服务提供商接入客户的 Microsoft 365 租户，把邮件、文件和 Teams 数据备份到租户之外。

为了完成备份，应用会在客户租户里建立服务主体（service principal），获得 Microsoft Graph、Exchange 等权限。有些部署还需要写权限，以便恢复数据。服务主体可以理解为应用在这个租户中的身份：管理员授予权限后，应用便能凭自己的凭据工作。

这份授权与员工登录会话不同。它不会下班失效，也不要求每次备份都有人确认。供应商保管的应用密钥一旦泄露，攻击者就可能带着客户早已批准的权限进入。

原文提到，一个早已停用产品多年的租户，仍然保留着 SkyKick 服务主体。采购关系结束了，技术授权却还活着。备份之外，工单、监控、人事系统等采用类似接入方式的产品，也需要检查这种授权残留。

超过 300 个租户成功登录，哪些数字不能混着看

原文给出的数字来自不同时间和观察范围，不能当成统一口径。

Microsoft 确认 10 月 15 日存在未授权认证尝试。Huntress 截至 10 月 16 日 19:00 UTC，确认 162 个租户出现未授权登录；10 月 17 日更新为接近 1,000 个 Entra 租户出现攻击地址的登录活动，其中超过 300 个成功。The Hacker News 同日报道的是 173 个租户，原文没有解释这一差异。

出现登录尝试、成功登录和确认数据泄露，是三个不同结论。

攻击者使用了合法 Cloud Backup 应用，ID 为 506e08f9-6e9a-4da4-942b-a099a03644ae。调查关联到地址 144.172.64.128，并发现 10 月 13 日、14 日使用 curl/7.88.1、python-urllib 和 python-requests 的脚本化尝试。

更严重的是后续权限变化。Huntress 在其监控的近 50 个租户中，发现 Cloud Management 服务主体给自己分配目录角色，大多是 Exchange Administrator。

其中一个租户内，Cloud Management - MS Teams 应用 24205314-2b89-4e07-a2a4-579e898a5640 给自己授予 Global Administrator，随后向另外两个应用添加凭据，其中包括一个单租户 Huntress 应用。相关 Python 脚本进行了 9 次修改，6 次成功，新密钥的有效期设到了 2028 年。

不同响应团队看到的结果也有差别。Todyl 分析了 9 个租户，只发现登录活动，没有发现通过备份应用创建账号、修改密码或建立持久访问的证据；Microsoft 和 Huntress 则观察到了后门、Microsoft Graph API 侦察及添加凭据的行为。前者的观察范围不能用来否定后者，也不能把后者的结果套到所有成功登录的租户上。

MFA 为什么没拦住，禁用应用为什么还不够

MFA 验证的是用户。本次攻击提交的是客户端密钥（client secret），没有用户登录，自然也没有验证码或手机确认。

因此，针对交互式登录的条件访问规则，不能直接覆盖这条路径。原文提到的 Directory.ReadWrite.All，是 Microsoft 威胁情报认为可能遭到滥用的权限之一。它涉及目录范围的写入，审查时需要解释：为什么一个备份应用需要这样的授权？但原文没有给出完整权限链，不能据此断言仅凭这一项权限就能完成所有提权操作。

Huntress 最初建议立即禁用前述两个应用，并考虑临时禁用其他 Cloud Management 应用。这里强调「禁用并保留」：删除会移除同意授权，恢复服务时需要重新授权；禁用则暂停访问，已经存储的备份仍保留。

真正容易漏掉的是下一步。

禁用入口应用，不会自动撤销它已经给其他应用添加的凭据。

因此，调查需要扩展到租户内每个应用的凭据，核对新增密钥、OAuth 授权和目录角色变化。恢复访问则要等待供应商确认相关凭据已经重置。

这也会影响业务恢复。ConnectWise 在 10 月 17 日 5:15 PM ET 通报已禁用相关应用；据原文引用的 10 月 18 日 01:00 UTC 更新，计划备份停止，受影响归档的访问和恢复功能仍不可用。供应商称既有归档保持加密、隔离，没有发现其遭入侵的迹象。这是供应商当时的声明，不能扩写成整个事件没有数据风险。

调查结论后来有所收窄。Huntress 在 10 月 19 日更新中，将最后一次成功登录定位到 10 月 15 日 08:44 UTC，并基于活动已停止的证据，把处置范围限定在确认发生未授权登录的租户。初期应急建议和后续范围判断，需要按时间分别理解。

我的判断

原文最有用的提醒，是把应用身份纳入安全边界。团队容易清查离职账号，却忘记清查停购服务留下的授权。对长期无人值守运行的应用，管理员当初点过的同意，可能比某个员工的登录状态持续得更久。

不过，「定期轮换密钥」不是完整答案。如果供应商仍处于失陷状态，新密钥也可能再次暴露；客户能否自行轮换供应商多租户应用的凭据，原文也没说清。客户可直接落实的是清理无用授权、审查权限和监测变化，供应商则需要说明凭据托管及重置机制。

原文倾向采用托管保险库中的客户端证书，替代共享密钥。这个方向有道理，但没有提供对照测试或风险下降数据，应视为架构建议。证书同样需要保护私钥、限制读取权限和管理有效期。

日志也有局限。上述 Python、curl 标识单独看区分度很低；角色分配还出现了供应商正常应用也使用的 kiota-dotnet。原文指出，Microsoft 的应用独立操作审计可能没有源地址，通过 Microsoft Graph 读取目录也可能不留审计记录。因此，搜索结果为空，只能说明没查到对应记录，不能证明没有访问。

能拿来做什么

• 给团队使用的 Microsoft 365 第三方应用做一次盘点，记录用途、负责人、授权时间和实际权限，优先核实停用产品留下的服务主体，再清理确认无用的授权。
• 排查这起事件时，把 144.172.64.128 与应用身份、时间窗口、User Agent 结合查询，并继续检查凭据变更、OAuth 授权和角色分配，避免只查员工登录日志。
• 如果你负责 Node 服务或日常自动化脚本，把应用凭据当作独立资产管理，明确谁能读取、何时轮换、泄露后撤销哪些授权；接入供应商服务时，也要求对方回答这些问题。
• 给备份服务写清停用后的恢复安排：供应商访问被切断时，谁确认凭据重置、谁批准重新启用，以及归档暂时无法访问期间如何处理恢复需求。