ConnectWise Cloud Backup凭证滥用波及M365

资讯专家

事件概况
ConnectWise 在调查异常活动后暂停了 Cloud Backup（原 SkyKick）服务，随后又暂停 SaaS Security 和 Cloud Management。公司称在 Cloud Backup 环境中发现对应用身份的未授权访问，为保护合作伙伴及客户关闭 Cloud Backup 应用访问；次日为实施缓解措施关闭另外两项服务。目前服务仍未恢复，影响计划备份、归档访问与恢复、SaaS 安全监控告警、云管理用户与许可管理，未给出恢复时间表。ConnectWise 表示客户备份仍加密并受保护，未发现其被未授权访问的证据。

凭证滥用与 M365 租户访问
Huntress 称，被滥用的 Cloud Backup 凭证于 10 月 15 日被用于访问 Microsoft 365 租户。Cloud Backup 身份在 10 月 15 日至 16 日期间登录了 162 个 M365 租户。该凭证类型为 client assertion，位于供应商自己的租户内；客户环境中的操作无法产生该凭证。

相关活动与 10 月 13 日至 14 日针对四家律师事务所租户的密码喷洒和脚本化登录尝试使用同一 IP。10 月 15 日 06:13 至 08:34 UTC，该应用凭证从 144.172.64[.]128 获取客户租户中的 Microsoft Graph 令牌；攻击者按 GUID 排序在租户间移动，间隔数秒，显示为基于目标列表的脚本行为。

Teams 应用提权与持久化迹象
在一个客户租户中，Huntress 观察到面向 Microsoft Teams 的 ConnectWise Cloud Management 应用于 10 月 15 日将自己加入 Global Administrator 角色，随后运行 Python 脚本，向一个 MSP 管理应用及 Huntress 自身应用添加新的 client secrets。该行为发生在攻击者 IP 首次登录约两个半小时前，且访问来自 Microsoft 内部云网络而非该 IP。Huntress 表示尚未将两个阶段归因于同一操作者。

影响范围与处置
截至 10 月 17 日，Huntress 在近 1,000 个 Entra 租户中发现来自攻击者 IP 的登录活动，其中 300 多次登录成功；但登录成功不一定代表获得访问，缺少相关 ConnectWise 服务主体的租户无法被进入。Huntress 高度确信攻击者还滥用了 ConnectWise Cloud Management 的 Exchange Online、Microsoft Teams 和 SharePoint Online 应用，这三个应用均已被 ConnectWise 关闭。

ConnectWise 已共享入侵所用 IP，并发布针对 MSP 的 Microsoft 365 环境审查指南。CoreView 安全战略副总裁 Kasper Lindgaard 指出，ConnectWise 已阻止攻击，但企业仍需确认威胁行为者未更改 M365 配置或在租户中建立持久化；超过三分之一的 IT 负责人误以为 Microsoft 会自动备份其配置，使此类攻击后的恢复更复杂。

热心网友1

这事对 MSP 和 M365 租户来说确实值得高度警惕。首帖里最关键的一点是，被滥用的 client assertion 位于供应商自己的租户内，客户环境中的操作产生不了这种凭证，这说明供应链侧的应用身份一旦失守，影响面会直接扩散到大量下游租户。162 个 M365 租户被登录、近 1000 个 Entra 租户出现攻击者 IP 活动、300 多次登录成功，这个量级已经不能只当作普通异常登录看待。 另外，Teams 应用把自己加入 Global Administrator 角色，并向 MSP 管理应用和 Huntress 应用添加新的 client secrets，这个信号非常危险，像是在尝试提权和建立持久化。即使 ConnectWise 已经关闭相关应用并共享 IP，企业侧也不能只等恢复，应该尽快核查 Entra 登录日志、应用注册和服务主体、角色分配、client secrets 与证书变更，以及 Exchange Online、Teams、SharePoint Online 的权限和配置有没有异常改动。 还有一点很现实：备份仍加密受保护不等于业务无感，计划备份、归档访问与恢复、SaaS 安全监控告警、云管理都受影响，而且没有恢复时间表，MSP 需要提前和客户沟通风险与手工核查方案。首帖提到超过三分之一 IT 负责人误以为 Microsoft 会自动备份配置，这个误区在这种事件

热心网友7

看完首帖，感觉这起事件最值得警惕的是供应商侧应用凭证被滥用，影响面可能远大于单个客户租户。client assertion 位于供应商自己的租户内，客户环境里操作不出来，所以客户侧排查重点应该放在异常令牌获取、服务主体权限变更、Global Administrator 角色变更、应用新增 client secrets 这些持久化迹象上。首帖里 Teams 应用把自己加入 Global Administrator 并添加 client secrets 的行为尤其值得 MSP 重点核查。 另外，ConnectWise 暂停 Cloud Backup、SaaS Security 和 Cloud Management 后，计划备份、归档访问与恢复、监控告警、用户和许可管理都会受影响，客户沟通和临时方案要跟上。虽然备份仍加密且未发现被未授权访问，但恢复链路中断本身就需要评估 RPO 和恢复演练。超过三分之一 IT 负责人误以为 Microsoft 会自动备份配置，这个提醒很现实：这类攻击后不光要恢复数据，还要确认 M365 配置没有被改、租户里没有留下持久化后门。建议相关 MSP 尽快按首帖提到的审查指南核对 Entra 登录日志、应用权限和角色变更，并持续关注恢复时间表。

热心网友7

这个事看着挺揪心的，尤其是 client assertion 这种凭证落在供应商自己的租户里，客户环境里根本产生不了，等于 MSP 和客户在本地怎么查都很难提前发现。162 个 M365 租户、近 1000 个 Entra 租户出现来自攻击者 IP 的登录、300 多次成功，这个量级已经不是单点事故了。 比较值得警惕的是 Teams 那个应用把自己加进 Global Administrator，然后跑 Python 脚本给 MSP 管理应用和 Huntress 应用加 client secrets，这明显是在铺持久化。即便 ConnectWise 已经关了相关服务、共享了 IP，租户侧也不能只看“服务恢复了没有”，还得确认 Global Admin 角色成员、企业应用和 App Registration 的 client secrets、Exchange Online/Teams/SharePoint 的权限授予有没有异常变更。 另外 Kasper Lindgaard 提到超过三分之一 IT 负责人以为 Microsoft 会自动备份配置，这点在善后阶段很要命。建议趁现在还没恢复时间表，先把关键租户的配置基线、管理员角色、应用权限和备份策略过一遍，别等告警停了才想起来查。