Windows Kerberos驗證恐被DNS別名誘導，微軟補強HTTP服務防中繼攻擊

資安業者Cymulate研究團隊揭露，Windows在進行Kerberos服務驗證時，建構服務主體名稱（Service Principal Name，SPN）的流程會跟隨DNS回應的CNAME別名，並以別名主機名稱向票證授權服務TGS索取服務票證。研究人員指出，要是攻擊者能在網路路徑上攔截或竄改受害者的DNS查詢，就可能誘導用戶端替攻擊者指定的SPN索取票證，再把票證中繼到未強制簽章或未強制通道（Channel）綁定權杖CBT的服務，達到冒用使用者身分存取資源的效果。

該風險的前提在於攻擊者能介入或改寫受害者的DNS流量，例如透過ARP欺騙、DHCPv4或DHCPv6投毒等手法取得中間人位置， 以影響DNS回應內容。研究人員指出，他們在多個已更新的Windows版本上都觀察到一致行為，並以SMB檔案分享與HTTP類服務為例說明，只有在服務端未強制簽章或未強制通道綁定權杖CBT時，中繼攻擊（Relay Attack）才較可能成立。

研究人員指出，該手法的風險在於降低了Kerberos中繼攻擊的既有限制。過去攻擊者往往難以左右用戶端會為哪一個服務主體名稱SPN索取服務票證，但一旦能利用DNS的CNAME別名影響SPN的主機名稱部分，用戶端就可能在不知情的情況下，將取得的服務票證送往攻擊者控制的端點。至於中繼是否能進一步得逞，仍取決於目標服務端是否已把簽章或通道綁定權杖CBT等防中繼機制設為強制要求。

研究人員已於2025年10月通報並經微軟確認。微軟在2026年1月的安全性更新中，替Windows的HTTP.sys補上通道綁定權杖CBT支援，並把修補套用到仍受支援的Windows Server版本。該漏洞以CVE-2026-20929編號追蹤，微軟在2026年1月安全性更新中針對HTTP.sys加入通道綁定權杖CBT支援，藉此提升HTTP類服務端面對Kerberos中繼的抵抗力。

不過，研究人員也指出，Windows用戶端跟隨DNS CNAME別名建構SPN的底層行為仍未改變。企業即使推進停用NTLM或以Kerberos取代，也不代表中繼攻擊風險會自動消失。企業仍須檢視各服務端的設定與更新狀態，同時盤點環境中仍允許未簽章或未綁定驗證的服務端點並加以修正。