文章总结： 攻击者入侵酒店公共Wi-Fi网关篡改DNS，借仿冒微软页面窃取差旅人员凭证。员工须在全隧道VPN生效后登录业务，异常时切蜂窝网并报安全团队。企业应部署抗钓鱼认证与条件访问，将差旅网络视为不可信环境，从设备与身份层防御，避免依赖员工肉眼识别假页面。 综合评分： 94 文章分类： 威胁情报,网络安全,安全意识,办公安全

酒店 Wi-Fi 连上就弹登录页：这次被盯上的可能是你的企业账号

原创

tcode tcode

字节脉搏实验室

2026年7月28日 10:17 北京

在小说阅读器读本章

去阅读

    ReliaQuest 7 月 23 日披露，一场至少从 2026 年 6 月持续的活动正在入侵酒店、会议中心等场所的公共 Wi-Fi 网关，并修改 DNS 配置，把用户流量重定向到仿冒 Microsoft 365 的基础设施。研究人员在美国多个城市以及印度、沙特阿拉伯观察到受影响网关，连接这些设备的组织来自金融、专业服务、法律、医疗、能源和零售等行业。

    SecurityWeek 7 月 27 日对事件进行了报道。它最值得普通用户注意的地方，是攻击不要求先攻陷员工终端，也不依赖一封钓鱼邮件。网关位于所有访客流量的必经位置，一台设备失守，就可能影响当天连接该网络的多名差旅人员。

    看起来像正常登录，为什么仍不可信

    公共 Wi-Fi 常见的“强制门户”会在联网前要求用户打开页面、接受条款或输入房号。用户已经习惯网络自动弹窗，也习惯在断网和重连时重新登录业务账户。攻击者利用的正是这段信任惯性。

    研究显示，攻击者控制网关后修改 DNS，让本应访问正常服务的请求先被导向其基础设施，再展示仿冒的 Microsoft 登录页面。这类对手中间人攻击不仅可能获取密码，还可能试图捕获登录会话和 OAuth 令牌。仅凭页面外观、浏览器曾经记住账号，甚至“已经开了普通 MFA”，都不能证明当前登录路径可信。

    ReliaQuest 认为相关手法与过去被归因于 APT28 的 FrostArmada 活动存在相似之处，但明确没有把本次活动直接归因于 APT28：当前基础设施与以往不同，缺少共享代码或操作失误等直接技术联系。把“手法相似”写成“俄罗斯组织已确认实施”会越过现有证据。

    出差员工应该记住的不是域名清单，而是动作顺序

    第一，企业设备应启用始终在线、全隧道 VPN，并确保 DNS 查询也走企业可信解析器。ReliaQuest 把这一措施列为关闭主要暴露面的关键控制。只代理部分业务流量、DNS 仍交给酒店网关的分流配置，不能提供同等保护。

    第二，在 VPN 尚未建立、强制门户仍要求联网时，不登录企业邮箱、云盘和管理后台。完成门户认证后先确认 VPN 已连接，再从书签、企业门户或客户端打开业务服务。如果 VPN 无法建立，优先使用企业移动热点或手机蜂窝网络完成敏感操作。

    第三，出现异常重复登录、域名拼写变化、浏览器证书警告、设备突然要求重新绑定 MFA 时，停止输入。不要用同一网络搜索“正确登录地址”，因为解析路径可能仍被控制；切换蜂窝网络后再联系企业服务台。

    第四，如果已经在可疑页面输入过密码或完成过验证，不要只修改密码。应立即通知安全团队，由可信设备撤销活动会话、检查新增 MFA 方法和 OAuth 授权，并核对邮箱转发、登录地点与云应用活动。

    企业不能把责任全部交给员工识别页面

    视觉识别对高仿登录页的效果有限。企业应在设备和身份层建立默认控制。

    终端团队需要确认全隧道 VPN 是否真正覆盖 DNS、IPv6 和浏览器流量，并测试酒店强制门户场景下的连接顺序。设备离开可信网络时，应自动进入受限模式，而不是依赖员工记住手册。

    身份团队应优先部署抗钓鱼认证，例如受设备绑定的通行密钥或安全密钥，并结合设备合规、登录风险和地理异常进行条件访问。传统一次性验证码仍可能在对手中间人场景中被实时转发，不能单独承担全部防线。

    SOC 可以关注差旅人员在公共网络使用后出现的异常 Microsoft 365 会话、新增 OAuth 同意、陌生设备注册和短时间跨地区登录。调查时把网络场所、VPN状态和身份日志放在同一时间线，而不是只问用户“有没有点邮件”。

    酒店与会场运营方也有一张明确清单

    公共 Wi-Fi 运营者应隔离管理面，不让 SSH、SNMP 和 Web 管理控制台直接暴露互联网；为每台网关使用唯一管理员凭据和多因素认证；限制管理来源；监控 DNS 配置、解析器地址和固件变化。

    ReliaQuest 对初始入侵方式只有低至中等置信度，推测攻击者可能结合暴露管理接口与弱或复用凭据，但由于设备可见性限制，没有完成确认。因此，运营方应把这些措施视为合理加固，而不能把某一种推测写成已证实的入侵路径。

    发生异常时，不能只恢复 DNS 设置就结束。还要更换管理凭据、核查固件与启动项、确认配置来源，并通知受影响时间段内可能连接的企业客户。公共网络设备控制的是大量第三方身份，其事件响应责任不应止于“Wi-Fi 已恢复”。

    信息边界

    已确认：研究方观察到公共 Wi-Fi 网关被控制并用于 DNS 重定向，目标是差旅人员的 Microsoft 365 账号；活动至少从 2026 年 6 月持续，涉及酒店和会议场所，始终在线的全隧道 VPN可显著降低风险。

    本文判断：差旅网络应默认视为不可信传输环境，企业账号安全必须由设备、VPN 和身份策略共同保证，不能只靠员工识别假页面。

    结语

    过去的差旅安全提示常写“不要连接陌生 Wi-Fi”。现实里，员工必须联网，酒店网络也可能名称正确、信号正常。真正可执行的原则不是完全不用，而是让公共网关没有机会决定企业流量该去哪里。

    先通过门户，确认全隧道 VPN，再登录业务；异常时切换蜂窝网络并撤销会话。这个顺序简单，但比记住一串恶意域名更持久，也更能应对下一家被入侵的酒店。

参考来源

• ReliaQuest：DNS Poisoning Tactics Expand to Hospitality Wi-Fi（2026-07-23；页面元数据更新于 2026-07-23 20:36:57 UTC）

• SecurityWeek：Hacked Public Wi-Fi Gateways Used to Harvest Corporate Credentials（2026-07-27 06:50 ET；RSS 为 10:50:19 UTC，北京时间 18:50:19）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：字节脉搏实验室 tcode tcode《酒店 Wi-Fi 连上就弹登录页：这次被盯上的可能是你的企业账号》