外出差旅的企業員工請注意：在登錄那些看似便捷的公共Wi-Fi之前，務必三思而行。
ReliaQuest威脅研究團隊近期披露，至少從今年6月起，威脅行為者開始攻擊酒店、會議中心及類似公共場所的"強制門戶"Wi-Fi網關和其他門戶設備，以此劫持用戶的微軟365賬戶。
一旦攻擊者控制了網關，便能在用戶毫不知情的情況下，將其流量靜默重定向至自己的基礎設施，並竊取微軟365憑據，整個過程無需接觸用戶設備、入侵終端，也無需發送釣魚鏈接或惡意附件。
ReliaQuest在接受媒體採訪時表示："最危險之處在於，攻擊發生在網路網關層面，而這一層次恰恰處於用戶和設備所有信任假設的底層。從單次事件來看，它未必構成企業級入侵，但對個人賬戶而言，卻是切實存在的風險。"
攻擊手法：DNS投毒攻入更高價值目標
ReliaQuest研究人員在部落格文章中指出，DNS（域名系統）投毒攻擊此前曾出現在小型辦公路由器上，即通過注入虛假數據，將正常網頁流量重定向至欺詐域名。如今，攻擊者正將這一技術升級，將目標瞄準更高價值的設備。
研究人員分析，攻擊者可能通過弱口令或復用的管理員憑據，結合SSH、SNMP及其他Web控制台等暴露的接口，獲取網關訪問權限。
只要擁有網關的管理員權限，惡意行為者便已得手——因為這類設備天然信任DNS，而DNS的職責正是將login.microsoftonline.com等域名解析為IP位址並進行路由。因此，攻擊者只需攻陷單個網關，便能攔截登錄該網路的每一位訪客的流量：在響應DNS請求時，返回自己控制的IP位址，而非合法地址，且全程無需觸碰任何終端設備。
研究人員寫道："強制門戶設備位於該網路每位訪客的網路邊界處。由於攻擊發生在網關側，完全在終端可見性之外，檢測本身就極為困難。"
在ReliaQuest追蹤的此次攻擊活動中，攻擊者註冊了四個域名用於仿冒微軟：m365-owa[.]com、owa-ms365[.]com、ms365-device[.]com以及ms365-live[.]com。
此次被發現的受攻擊Wi-Fi網關分布於美國多個城市，以及印度和沙烏地阿拉伯，受影響用戶來自專業服務、金融服務、法律、零售、醫療健康及能源等多個行業，表明該攻擊手法並不針對特定行業。
ReliaQuest還指出："我們已見過足夠多的SharePoint數據泄露案例，深知單個賬戶被攻陷往往會引發連鎖反應，造成不可忽視的數據損失。"對於網路運營商而言，這更涉及"聲譽層面"的問題——無論底層攻擊手法多麼複雜，用戶賬戶被盜都是"嚴重的信任危機和品牌危機"。
為何常見防護手段效果有限
將DNS解析伺服器鎖定為谷歌（8.8.8.8）、Cloudflare（1.1.1.1）或雲端OpenDNS等"安全"DNS提供商，並不足以應對此類攻擊，因為這並不能改變查詢請求實際經過的路徑。
ReliaQuest解釋稱，設備默認以未加密的明文協議發送DNS查詢，這些數據包仍須穿越酒店網路才能到達谷歌、Cloudflare或OpenDNS。由於網關直接處於該路徑上，它可以在查詢到達所選解析器之前，對其進行檢測、攔截或重定向。
"指定受信任的DNS伺服器，改變的只是預期目的地，而非控制通往目的地道路的人。"ReliaQuest如此說道。
此外，使用數字簽名和公鑰加密的DNSSEC（域名系統安全擴展），也只能"部分"解決問題。DNSSEC為已簽名域名提供身份驗證和完整性保障，使驗證解析器能夠檢測並拒絕偽造或篡改的響應。
"但DNSSEC不提供機密性或可用性保障，"該公司表示，"它既不加密DNS流量，也無法阻止攻擊者攔截、阻斷或重定向請求。"
因此，儘管DNSSEC能抵禦針對已簽名區域的特定響應偽造攻擊，路徑上的惡意網關仍可查看查詢內容、丟棄請求或強制觸發降級行為。更關鍵的是，這一保護層僅在域名已完成簽名且客戶端或解析器執行驗證時才有效——而"許多存根解析器並不執行驗證"。
企業應對建議
針對上述威脅，企業應要求所有公司設備在建立網路連接時強制使用全隧道VPN，並通過控制機制確保隧道激活前禁止訪問網際網路。
ReliaQuest解釋稱，全隧道VPN會在流量到達任何其他目的地之前，將設備的所有流量（包括DNS）通過加密連接路由至受信任的VPN伺服器，從而徹底防止酒店網關等本地網路窺探或篡改DNS及網際網路流量。"實際上，這相當於將不受信任的網路從信任鏈中徹底排除。"
不過，研究人員也指出，全隧道模式並非VPN的默認配置，因為它存在"實際代價"：由於每個數據包都必須經由企業基礎設施中轉，會帶來額外成本、延遲和頻寬消耗。因此，對於分布式辦公或頻寬需求較高的團隊而言，強制所有流量通過企業骨幹網並不總是可行的。
企業還應在Entra ID中強制執行條件訪問策略，以阻止設備代碼身份驗證流程——對大多數用戶和大多數環境而言，這一流程幾乎沒有合法的使用場景。
此外，ReliaQuest還建議：
將代理自動配置（PAC）文件的獲取限制為經過批准的內部主機；
通過組策略禁用自動Web代理自動發現（WPAD）——該功能在Windows中通常默認開啟；
以嚴格模式部署DoH或DoT等加密DNS，作為全隧道VPN的"補充方案或替代方案"，對於無法實現始終在線VPN的組織而言尤為重要；
對員工開展安全培訓，引導其在輸入憑據前核驗頁面URL和證書，在公共Wi-Fi網路上使用時尤其如此。
ReliaQuest特別強調，在此類攻擊中，事前預防遠比事後檢測更為重要：在微軟Defender for Endpoint等工具中，雖然可以通過"DnsConnectionInspected"事件來發現指向攻擊者控制域名的查詢，但"等到這些事件觸發時，重定向通常已經發生。換言之，終端遙測數據更多是在還原已發生的事情，而非阻止攻擊發生。"
這正是加密傳輸、條件訪問以及WPAD與PAC加固等防護手段，比單純依賴檢測更為關鍵的根本原因。
Q&A
Q1：黑客是如何通過酒店Wi-Fi劫持微軟365賬戶的？
A：攻擊者首先通過弱口令或復用憑據入侵酒店Wi-Fi網關，獲得管理員權限後，對DNS進行投毒，將微軟365登錄域名解析為攻擊者控制的惡意IP位址。當用戶連接該Wi-Fi並嘗試登錄微軟365時，流量被靜默重定向至仿冒頁面，賬戶憑據隨即遭到竊取，整個過程無需觸碰用戶設備。
Q2：切換到谷歌或Cloudflare的DNS伺服器能防止這種攻擊嗎？
A：不能。指定谷歌（8.8.8.8）或Cloudflare（1.1.1.1）等受信任DNS伺服器並不足以防禦此類攻擊。因為DNS查詢數據包默認以未加密形式傳輸，在到達谷歌或Cloudflare之前，仍須經過酒店網關。由於網關直接處於傳輸路徑上，可以在查詢到達目標解析器之前將其攔截或重定向，因此僅靠更換DNS伺服器無法解決根本問題。
Q3：企業和員工應如何防範酒店Wi-Fi帶來的微軟365賬戶被盜風險？
A：最有效的防護措施是強制所有公司設備使用全隧道VPN，確保包括DNS在內的所有流量在離開設備後立即進入加密通道，使酒店網關無法查看或篡改任何內容。此外，還應在Entra ID中啟用條件訪問策略、禁用WPAD、限制PAC文件獲取來源，並以嚴格模式部署加密DNS（DoH/DoT）。同時，應培訓員工在公共Wi-Fi上登錄前仔細核驗URL和證書。
