ConnectWise凭证泄露致云备份服务暂停

一枚被盗的API密钥，源自多数客户几乎不会留意的一款备份工具，让ConnectWise三项云服务全部中断，也迫使数百个Microsoft 365租户进入紧急日志排查。ConnectWise于10月17日确认其Cloud Backup环境遭到未授权访问，随后暂停了Cloud Backup、SaaS Security和Cloud Management服务，且尚未给出恢复时间表。Huntress已确认162个租户出现未授权登录，微软表示，攻击者“很可能滥用了客户此前授予该应用的权限，包括Directory.ReadWrite.All这类高权限”。

这次没有利用零日漏洞，也没有串联内存破坏类漏洞。攻击者只是穿过了客户自己撑开的一扇门。这扇门是ConnectWise搭建的，而且开合时几乎没有声响，因为基于应用的身份验证不会弹出MFA提示，放错了位置更是毫无痕迹。这是我处理过的最不起眼的一类事件，也是最让我饭碗有保障的一类。

第0至2天：没能得手的密码喷洒

据The Record依据Huntress遥测数据还原的时间线，事件始于10月13日和14日，Huntress响应人员当时发现针对四家律师事务所的密码喷洒攻击。单看这一点，不过是寻常的一天。针对律所的密码喷洒，就像背景辐射一样普遍。

第2天，10月15日，情况开始变得有意思。Huntress监测的约50个系统显示，攻击者利用ConnectWise的Cloud Management应用为自己分配目录或管理员角色。同一天上午，Cloud Backup应用在UTC时间06:13至08:34之间，从IP地址144.172.64[.]128完成身份验证。据CSO Online报道，这是一个托管服务商的地址，而非该应用通常使用的Azure私有IP段。这些事件本来就记录在微软的登录日志中。原则上说，只要服务主体从一个从未使用过的地址发起回连，就能在事件发生的那一刻被发现。

机制本身很平淡，但关键就在这里。被盗凭证是ConnectWise自有租户中与Cloud Backup应用绑定的API密钥。它让应用无需任何用户登录，即可在客户租户中获取Microsoft Graph访问令牌，没有密码，也没有MFA挑战。这枚密钥存放在厂商环境中，意味着这并非任何单个客户的所作所为或疏忽所致，客户也无法阻止它。客户能做的是察觉它。

五分钟内拿到全局管理员权限

在一个Huntress合作伙伴租户中，攻击链完整走完。第二个ConnectWise应用（Microsoft Teams版Cloud Management，应用ID为24205314-2b89-4e07-a2a4-579e898a5640）为自己分配了全局管理员角色，随后又在该租户中给另外两个应用添加了新凭证，其中一个是专属于该合作伙伴、仅限单租户使用的Huntress应用。据Huntress称，整个过程耗时约五分钟；该公司尚未确定各阶段是否由同一名操作者执行。

这五分钟的过程值得牢记，因为它正是委派式OAuth访问的教科书式提权路径。初始访问：被盗的厂商凭证。持久化：在其他应用上添加新凭证，每一个都独立于最初的厂商密钥。权限提升：应用通过客户自己同意授予的目录权限，为自己分配全局管理员。Huntress解释了这一链条为何会层层叠加：能够分配目录角色的应用，可以向其他应用添加凭证、创建新应用、重置密码和身份验证方式，还能修改条件访问策略。该公司写道：“这些步骤中的每一步，都会给攻击者另一条不依赖原始厂商凭证的回归路径，这就是为什么轮换厂商凭证是必要的，却远远不够。”

Huntress给出的实操警告（由The Register转述）是本次事件中最具影响力的一句话：即便禁用M365应用（包括被滥用的ConnectWise应用），也无法删除已经添加的凭证，防守方必须审查所有M365应用上的凭证。在厂商一侧遏制事态，只能吊销正门的钥匙，对攻击者已经复制的钥匙却无能为力。

第3至6天：遏制、沉默与第二波攻击

ConnectWise于10月16日（周五）首次承认存在“未授权访问尝试”，次日确认已发生访问。10月17日，它禁用了七个应用身份，并吊销了所有用户受影响应用连接所用的证书。这一操作也切断了它自身通过这些连接的访问，并使此前Cloud Backup使用的所有共享凭证失效。此次服务中断涵盖Cloud Backup（前身为SkyKick产品）以及集成的SaaS Security和Cloud Management平台。据The Register报道，截至10月18日16:00 UTC，客户仍无法备份数据、访问归档或执行恢复。ConnectWise安全运营副总裁Jason Ferguson在Reddit上表示，现有归档“仍处于加密、隔离和保全状态，没有任何未授权访问的证据”。

截至10月16日19:00 UTC，Huntress统计的存在未授权登录的租户数量为162个。该公司还观察到第二波攻击，多数未能得逞，目标是“政策、国家安全、贸易和关键矿产领域”的租户。这些尝试大多失败，原因颇具启发性：被攻击的租户并未使用ConnectWise产品，因此被滥用的服务主体根本不存在。与此同时，ConnectWise在10月19日的安全公告更新中新增了两个IP地址（144.172.64[.]99和144.172.64[.]60），这两个地址是通过下游监测发现的，并称自遏制措施实施以来未再发现成功的威胁活动。该公司仍未给出恢复时间表，也未透露受影响客户的数量，并拒绝讨论归因问题。

有两件事仍属未知，诚实起见必须让它们继续留在未知栏里。最初凭证是如何被泄露的，至今未披露。备份数据本身是否遭到触碰，也未经证实。ConnectWise发言人表示，没有迹象显示归档遭到入侵，但这并不等于证明未发生。Huntress自己的提醒在这里尤为关键：使用这些凭证的攻击者，可以进入那些不会留下任何证据痕迹的地方。

无人计价的可见性缺口

ConnectWise已直言这一结构性问题：它无法看到合作伙伴和客户的环境，也无法判断任何特定租户是否遭到入侵。从架构上看，这是正当的。它是平台提供商，而其MSP客户拥有与终端客户的关系。但这也恰恰是整个风险模型的写照。厂商持有的凭证可以触及每一个已授权的租户，可只有租户才能看到它实际触及了什么。发现入侵的责任，落在了对入侵情况掌握信息最少、在许多情况下日志能力也最不成熟的一方身上。

对MSP而言，账算得更糟，正如Huntress所指出的：在一个客户处获得立足点，就可能获得对所有客户的访问权，而这正是该行业赖以运转的集中化风险。ConnectWise并非第一次遇到此类问题。去年，一次针对其远程监控软件的国家级攻击波及了客户；此前也有犯罪分子利用其产品漏洞投放勒索软件。问题的症结并不在于ConnectWise格外粗心，而在于MSP工具按设计就是一条通往成千上万下游网络的特权动脉，而行业默认的同意授权（宽泛、持久、仅限应用）把这条动脉当成了管道，而非攻击面。

日志本可以告诉你什么

这件事本可以在何时被发现？有三个节点尤为突出。第一，10月15日UTC 06:13：首次来自应用正常Azure段之外IP的身份验证。若对来自陌生地址的服务主体登录设置告警规则，就能在第一次角色分配之前触发。第二，Cloud Management for Teams为自己授予全局管理员的那一刻。这是一条被记录的目录角色分配事件，异常程度堪称审计事件之最。第三，向另外两个应用添加凭证：五分钟内的活动，每一步都记录在审计日志中；如果有人盯着该应用的日志，每一步都足以触发紧急呼叫。

• 对来自已知厂商网段之外IP的服务主体身份验证发出告警。144.172.64.x这些地址是最早的公开信号。
• 对任何应用为自己分配目录角色的行为一律告警，没有例外。备份软件根本没有理由在早上6点让自己成为全局管理员。
• 将OAuth同意授权视为长期有效的凭证：盘点、收窄权限范围，并定期复审，而不是等到事件发生之后。
• 记住，吊销厂商连接只是关上了正门；已添加到其他应用上的凭证仍然有效，直到你亲手删除它们。

我做过的事后复盘数量已多到懒得去数，结论总是一样：租户有日志，却没人设置告警；应用拥有的权限远超任务所需。ConnectWise的遏制工作看上去很专业，但遏制是厂商的职责，审计却是你自己的事。请拉取10月13日以来的登录日志，逐一列出每个企业应用上的每一项凭证，然后回答这起事件真正提出的问题：你租户中的哪些第三方应用可以做到这一点？如果它们真的这样做了，你能否在五分钟内察觉？