河北
2026年1月，网络研究人员发现微软基础设施中与 example.com 相关的异常行为。
这个域名是严格按照既定互联网标准用于测试的，全球 域名注册 系统对此提供保护。
本不应解析到任何真实组织的流量却转发到了住友电气运营的服务器，这是一家以工业电缆而非电子邮件服务著称的日本品牌。
自动发现异常
这个异常出现在与微软 Outlook 自动发现功能相关的常规测试中，这引发了人们对这种路由存在方式的疑问。
最初发给微软的请求没有得到任何解释，即使在不当路由停止后也是如此。
这个问题源于微软在配置新电子邮件账户时使用的自动检测和自动发现机制，类似于网站构建器平台使用的自动设置工具。
当研究人员使用example.com提交测试凭据时，该服务返回的JSON响应中包含了与sei.co.jp域名相关的邮件服务器主机名。
这些响应指向了微软网络之外的IMAP和SMTP端点，尽管凭据显然只是占位符。
根据RFC2606，example.com不应生成可路由的服务信息，这让这种行为很难与预期的标准相符。
到周一早上，可见的路由行为已经停止了，不过微软仍然没有立即提供技术解释。
微软后来确认，它已更新服务，停止为example.com提供建议的服务器信息，并表示调查仍在继续。
该端点不再返回有问题的JSON数据，不过底层的路由逻辑仍然不明。
尚不清楚住友商事的子域是如何嵌入到微软的网络配置中，尤其是在与全球网络托管基础设施规模相当的系统中。
关于住友商事使用微软 365 Copilot 的先前公开声明并未解释为什么会出现一个独立的企业域在自动发现响应中。
报告显示，这种情况可能已经持续了数年，这引发了关键服务中长期配置漂移的可能性。
微软尚未澄清它是如何在内部添加或审核自动发现记录的。
截至撰写本文时，没有证据表明路由行为并没有恶意意图，也没有迹象表明在正常操作中真实用户的凭据被泄露。
这起事件让人们想起了微软之前的一些管理失误，包括一个被遗忘的测试账号，这个账号让国家支持的攻击者能够访问内部系统。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
