攻击者是以应用的身份登录的
您的用户都通过了 MFA，而攻击者是以应用的身份登录的。这正是 ConnectWise Cloud Backup 事件背后的身份边界：攻击者利用一个应用凭据，凭借客户租户中早已授予的权限请求访问。专为考验人员登录而设计的控制措施，从来都不是这条路径上的关卡。
我在 2026 年 10 月 20 日查阅的 ConnectWise 安全公告确认了应用身份遭到未授权访问，并介绍了控制措施，但最初的凭据泄露途径仍在调查之中。本文是基于公开资料的架构分析，并非在真实租户中复现。真正值得长期关注的问题是：当集成服务运营方的凭据落入攻击者手中时，这个集成还保留着哪些访问权限。[1][2]
授权同意会创建一个拥有常驻权限的身份
应用程序权限不同于委托权限。在客户端凭据流程中，软件以其自身身份进行认证，无需任何已登录的用户。多租户应用在每个使用它的租户中都有一个服务主体；授权同意和分配的权限决定了该身份在那里能做什么。重置用户密码既不会吊销应用的凭据，也不会改写这些授权。[3][4]
因此，我审查一个集成时，会从权限集入手，而不是看厂商给产品贴的标签。备份和恢复确实是需要广泛数据访问的正当理由，但读取能力、写入能力和修改身份的权限，其后果截然不同。请记录您租户中具体的授权和目录角色。不要想当然地认为每个客户授予的权限都一样，也不要以为“备份”二字就意味着应用只能读取。
Conceptual app-only path
Vendor application credential
-> token request for customer tenant
-> customer service principal + granted permissions
-> access token for a resource
-> resource operation
No user password or MFA prompt is part of this flow.您的策略覆盖这类应用吗？
根据 Microsoft 关于工作负载标识条件访问的文档，第三方 SaaS 和多租户应用不在这些服务主体策略的适用范围内。购买相应的许可证也无法消除这一范围限制。相关的工作负载连续访问评估文档同样只支持在本租户中注册的单租户服务主体。一个功能的名称，并不能证明某个具体身份已被覆盖。[5][6]
实际审查是一项对照工作：针对每一个集成，写明由哪项控制评估它的令牌请求、哪个资源接受该令牌，以及它可以行使哪些权限。如果某项策略不适用，就记录这一空缺以及可用的补偿性限制。用户 MFA 对用户访问依然很有价值；但假装它也能管住仅限应用的凭据，就会让另一个身份完全处于审查之外。
禁用应用只完成了控制工作的一部分
阻止签发新令牌与使现有访问失效是两种不同的操作。Microsoft 文档中访问令牌的默认有效期为 60–90 分钟，但这并不是事件处置的通用倒计时。令牌设置、资源的处理方式以及所支持的吊销机制都会产生影响。ConnectWise 明确表示，此前签发的令牌在过期或以其他方式失效之前可能仍然可用。请在响应计划中体现这一区别，而不要以为“禁用”就等于“立即注销”。[1][7]
还有第三种状态：通过另一个身份建立的访问。Huntress 报告称，在受影响的租户中，有未经授权的凭据被添加到了其他应用上。禁用原来的 ConnectWise 应用并不会删除这些凭据。因此，我的结案模型包含三行独立的内容：已阻止新的签发、已查清此前签发的访问、已移除未经授权的衍生访问。干等九十分钟并不能证明第三行。[2]
Containment question Evidence to request
New tokens still issued? Application state + sign-in outcomes
Existing token still accepted? Resource behavior + expiry/invalidation
New independent access established? Credential, grant and role-change review
Elapsed time alone is not a closure record.成功登录证明的是访问，而不是所有可能的操作
服务主体的一次成功登录所能证明的，远比“读取了所有邮箱”要窄。Todyl 公布的调查描述了登录活动，但在其审查的租户中没有发现所查找的持久化变更。Huntress 则描述了在其他租户中发生的入侵后变更。这些是不同的观察结果，不能据此把观察到的最坏情况套用到每一个客户身上。权限确立的是能力；操作层面的证据确立的是已观察到的使用。[2][8]
反过来的捷径同样不安全。用户登录视图为空，并不涵盖服务主体登录——Microsoft 是单独记录这类登录的。审计记录缺失，也不能证明每一次可能的数据读取都会被记录下来。请让结论保持在边界之内：有哪些遥测数据可用，它们覆盖了哪些身份和资源，以及它们实际能显示哪些操作。在能为下一步调查保留线索时，“未知”本身就是一个有用的结论。[2][9]
从原始应用出发，追踪到其他身份上的变更
先按应用 ID 搜索，再把服务主体登录与事件时间窗内的审计事件关联起来。下面的 Cloud Backup ID 只是最初的锚点，而不是受影响应用的完整清单；更大范围的应用系列请以厂商最新公布的列表为准。保留发起者、目标、结果和关联 ID。既要追踪由列表中应用发起的变更，也要追踪针对该应用所做的变更。[1]
在把陌生的凭据、授权同意和角色分配定性为恶意之前，先与已批准的负责人记录进行核对。仅凭凭据的有效期并不能确定它是何时添加的。记录删除了什么、为什么删除，以及它曾为哪个其他身份提供了访问。这样形成的是一条其他审查人员可以复核的证据链，而不是一张显示某个企业应用已被禁用的截图。[1]
Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick
Investigation record:
tenant + application ID + local service principal ID
event time + initiator + target + outcome + correlation ID
credential or permission change + approved owner record
containment action + remaining access + evidence limits问一问：点下“禁用”之后还剩下什么
第三方集成的验收问题应当在事件发生之前就写好：如果它的凭据明天泄露，客户这边的哪项操作可以阻止新的访问？已经签发的令牌会怎样？我们又如何找到在其他地方创建的权限或凭据？要求为这些答案指定具名的负责人。一个没有现任负责人的集成，仍然保留着所有尚未移除的访问权限。
同样的问题也决定了事件发生后一次有价值的修复验证工作。在把原始应用当作问题的全部之前，我会核查每一种控制状态背后的证据，并追踪对其他身份所做的变更。恢复备份服务与证明租户访问已受控，是两个相关但需要各自证据支撑的决定。
参考来源
需要在您自己的产品中检查这个问题吗？
漏洞修复与修复验证想学会自己发现这类漏洞吗？
安全代码审计课程（一对一）