Microsoft Corporation

ProxyLogon 表明，发布紧急 Exchange 服务器补丁只是修复的开始。一旦面向互联网的本地电子邮件服务器遭到大规模利用，公共机构、学校、小型企业、托管服务提供商、企业和用户都需要证据证明在头条补丁窗口过去后，服务器已被发现、更新、调查、清理、监控并免受攻击者持久化攻击。

2021 年 4 月 1 日，Azure DNS 在一段关键时间内不再是可靠的命名基础设施。Microsoft 将 DNS 可用性受影响的窗口定为 UTC 21:21 至 22:00，并称大多数受影响服务到约 22:30 才恢复。运营方随后把事故归因于一次面向若干未披露 Azure 托管域名的全球异常 DNS 查询激增，以及一个降低 DNS 边缘缓存效率的代码缺陷；服务过载后，客户端重试又带来看似合法的额外负载。公开材料足以审视缓存、过载保护、重试、隔离、状态通道与恢复证据，却不足以确定流量来源、生成系统、意图、目标域名、个人责任、完整损失或全部改进措施的当前有效性。真正的问责对象，是压力下实际运行的命名系统，而不是一份抽象的韧性承诺。

一次马德里扩容作业中的命令，在不同厂商平台上具有不同的实际作用范围。它越过了作业文本所暗示的边界，迫使微软全球 WAN 重算可达性，也说明“允许执行”并不等于“已经证明运行范围可控”。

ChainDrop 的关键不在于某一个软件包被植入恶意代码，而在于被盗的发布权限能够制造下一批“看似正常”的版本。微软此次技术披露把风险从包管理器延伸到云凭证、构建系统和代码仓库；企业真正要核算的是，哪些访问权和产物已经失去可验证的可信来源。

微软在 2001 年 1 月遭遇的 DNS 可达性故障揭示了一条至今仍适用的基础设施规律：正确的域名记录、持续运行的网站和多台权威服务器，并不等于具备独立故障域的命名服务。真正决定连续性的，是外部网络能否穿过实际运行的边缘配置抵达这些服务器。

Azure DNS 并不需要所有客户端请求都怀有恶意，2021 年 4 月 1 日的故障才会扩大。Microsoft 表示，一次来自全球的异常查询激增暴露了一个代码缺陷，降低了 DNS 边缘缓存的效率。随着服务过载，普通 DNS 客户端对未获答复的请求进行重试。这些重试被视为合法流量，因此流量尖峰缓解系统最初没有丢弃它们。其结果是在共享网络基础设施内部形成了反馈回路：缓存效率下降增加了工作量，受损的应答催生更多重试，而围绕可疑流量设计的防御措施，却未能遏制在总体规模上已造成运行危害的合法流量。问责的考验在于，运营商能否证明这一回路从哪里开始，哪个控制环节未能打破它，恢复是如何衡量的，以及修复是否针对缓存状态、查询模式和重试行为的相同组合进行了测试。[1]-[5]

2023 年 1 月 25 日，Microsoft 广域网络路由器上的一次计划 IP 地址变更演变成全球服务事件。Microsoft 的说明称，一条命令在不同网络设备上行为存在差异，向其他 WAN 路由器传播了消息，并迫使邻接关系和转发表重新计算，导致数据包失去正确路径。独立观察者看到了 Microsoft 网络周围的 BGP 路由撤销、重新宣告、路由波动和丢包。这次事件使得一个区别无法回避：变更请求描述的是意图，但由路由器安装和传播的状态决定基础设施是否仍然可达。