微软追踪了两起入侵：攻击者先在Teams上假冒IT支持人员，随后滥用Active Directory Certificate Services。AD CS是在部分Windows组织中签发身份验证证书的基础设施。实际教训是，恢复最初的工作站后，可能仍有其他访问方式需要调查。
案例研究发表于2026年10月30日，早于CNET于11月4日的原始报道。这些是披露和报道日期，并非入侵开始日期。微软将最初的进入方式归因于社会工程，而不是Teams漏洞。
证书访问可能在最初入口关闭后仍然存在
两起案例中，用户都被说服授予远程访问权限，主要使用Quick Assist。攻击者随后接触到证书基础设施。其中一起利用了权限过宽的证书模板，这条路径称为ESC1；另一起使用称为ESC8的身份验证中继路径。
微软表示，在第一起案例中，一个被排除在自动遏制措施之外的特权身份仍可使用，随后被用于数据窃取。在第二起案例中，客户收到告警后隔离了工作站，此后未观察到进一步推进。这是两种不同的结果，不能据此认定某个防御产品总能阻断整条攻击链。
报告提醒，重置密码不会撤销已签发的证书。响应人员还需单独检查已有的Kerberos身份验证票据。因此，恢复时应追问哪些身份和凭证仍可使用，而不仅仅是最初的远程会话是否已经结束。
加固证书注册服务是另一项工作
微软的AD CS中继攻击缓解指南建议，为相关注册服务启用Extended Protection for Authentication和HTTPS，并在可行时限制NTLM。这些措施针对证书服务，更新协作客户端并不能完成这项配置工作。
管理员应依据指南检查自身的注册端点和身份验证依赖。设置必须适合已部署的服务，并在大范围变更前验证。案例研究提供了检查暴露面的理由，并不能证明所有使用Teams的组织都有相同的证书配置。
批准控制之前先核实支持人员
微软的Teams安全指南要求用户核实陌生发送者，并为管理员提供外部通信控制。熟悉的显示名称不足以证明对方是内部技术人员。
遇到意外请求时，应在授予远程控制前，通过既定的内部支持渠道核实。如果已经批准访问，应及时报告，让响应团队关联对话、终端活动与身份记录。这样组织才有机会调查完整路径，而不是把聊天当作一条孤立的可疑消息。