黑客入侵酒店Wi-Fi网关，劫持微软365账户

外出差旅的企业员工请注意：在登录那些看似便捷的公共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和证书。