安全公司Cymulate研究团队披露，Windows在执行Kerberos服务认证时，构建服务主体名称（Service Principal Name，SPN）的流程会跟随DNS响应中的CNAME别名，并以别名主机名向票证授予服务（TGS）申请服务票证。研究人员指出，若攻击者能在网络路径上拦截或篡改受害者的DNS查询，就可能诱导客户端为攻击者指定的SPN申请票证，再将票证中继至未强制签名或未强制通道绑定令牌（CBT）的服务，从而冒用用户身份访问资源。

该风险的前提是攻击者能够介入或篡改受害者的DNS流量，例如通过ARP欺骗、DHCPv4或DHCPv6投毒等手段获取中间人位置，以影响DNS响应内容。研究人员表示，他们在多个已更新的Windows版本上均观察到相同行为，并以SMB文件共享和HTTP类服务为例说明，只有在服务端未强制签名或未强制通道绑定令牌（CBT）时，中继攻击才更可能成功。

该手法的风险在于降低了Kerberos中继攻击的既有限制。过去攻击者往往难以控制客户端为哪个SPN申请服务票证，但一旦能利用DNS的CNAME别名影响SPN的主机名部分，客户端就可能在不知情的情况下，将获取的服务票证发送至攻击者控制的端点。而中继攻击是否能进一步得逞，仍取决于目标服务端是否已强制启用签名或通道绑定令牌（CBT）等防中继机制。

研究人员已于2025年10月向微软通报，微软已确认该问题。在2026年1月的安全更新中，微软为Windows的HTTP.sys组件增加了通道绑定令牌（CBT）支持，并将补丁应用于仍受支持的Windows Server版本。该漏洞编号为CVE-2026-20929，微软通过此次更新提升了HTTP类服务端抵御Kerberos中继攻击的能力。

然而，研究人员也指出，Windows客户端跟随DNS CNAME别名构建SPN的底层行为尚未改变。企业即使推进禁用NTLM、全面转向Kerberos认证，也不能自动消除中继攻击风险。企业仍需检查各服务端的配置与更新状态，同时排查环境中仍允许未签名或未绑定验证的服务端点，并及时修复。