The Silent Threat Hiding in Your Hotel's Wi-Fi
Business travelers logging into hotel or conference center Wi-Fi to check their Microsoft 365 email are increasingly being targeted by a sophisticated credential-theft campaign — one that requires no malware on their device, no phishing email in their inbox, and no suspicious link to click. According to researchers at ReliaQuest, threat actors have been compromising so-called "captive portal" Wi-Fi gateways at hotels, conference centers, and shared venues since at least June, redirecting users to fake Microsoft login pages without ever touching a single endpoint device.
The attack exploits a foundational trust built into how networks function: the Domain Name System (DNS). By gaining administrative access to the Wi-Fi gateway — the device that manages how guests connect to the internet — attackers can intercept, poison, and redirect DNS queries for every single user on that network. When a business traveler tries to visit login.microsoftonline.com, they are invisibly redirected to an attacker-controlled lookalike domain. Their credentials are harvested, and they may never know it happened.
"The most dangerous element is that it operates at the network gateway, which sits beneath most of the trust assumptions users and devices make," ReliaQuest told CSO Online. "It's not necessarily an enterprise breach level event on its own, but it's a very real risk to individual accounts."
How Attackers Compromise Hotel Wi-Fi Gateways
The attack chain begins with gaining administrative control of the captive portal appliance — the networking hardware that hotels and venues use to offer guest internet access. According to ReliaQuest's threat research blog, attackers most likely exploit weak or reused admin passwords combined with exposed management interfaces such as Secure Shell (SSH), Simple Network Management Protocol (SNMP), or web-based admin consoles.
This is a known and persistent problem across the hospitality industry. Networking equipment in hotels is often deployed, configured once, and then left largely unmanaged. Default credentials are frequently never changed, and firmware updates are rarely applied. Research published by security firm Trustwave has previously documented how hotel network equipment routinely suffers from poor security hygiene, making it a soft target for well-resourced threat actors.
Once an attacker has admin access to the gateway, they don't need anything else. The gateway is configured by design to handle DNS — the system that translates human-readable domain names into IP addresses. By injecting false DNS records (a technique known as DNS poisoning), an attacker can silently answer DNS queries with their own malicious IP addresses instead of the legitimate ones. When a guest's device asks "where is login.microsoftonline.com?", the compromised gateway responds with the IP of an attacker-controlled phishing server.
In the campaign tracked by ReliaQuest, four attacker-registered domains were identified as Microsoft impersonation lures: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com. Compromised gateways were identified across multiple US cities, as well as in India and Saudi Arabia. Victims came from companies spanning professional services, financial services, legal, retail, healthcare, and energy — confirming the campaign is sector-agnostic and opportunistic.
"We've seen enough SharePoint exfiltration cases to know that a single compromised account can cascade into meaningful data loss."
— ReliaQuest Threat Research TeamWhy Switching to Google or Cloudflare DNS Won't Save You on Hotel Wi-Fi
Many IT professionals and security-conscious users instinctively configure their devices to use trusted DNS resolvers like Google's 8.8.8.8 or Cloudflare's 1.1.1.1, believing this makes them immune to DNS manipulation. On a hotel Wi-Fi network under the control of a malicious gateway operator, this assumption is dangerously wrong.
Here's why: by default, DNS queries travel as unencrypted UDP traffic. Even if your device is pointed at Cloudflare's resolver, those DNS packets still have to physically traverse the hotel's local network — through the compromised gateway — before they can reach Cloudflare's servers. The attacker's gateway sits directly in that path. It can inspect those DNS packets, drop them entirely, or substitute its own poisoned responses, all before the query ever reaches its intended destination.
As ReliaQuest succinctly put it: "Specifying a trusted DNS server changes the intended destination, not who controls the road to get there."
What about DNSSEC (Domain Name System Security Extensions)? DNSSEC uses digital signatures and public-key cryptography to authenticate DNS responses, helping detect forged records for signed domains. However, ReliaQuest notes DNSSEC only "partially" addresses the problem. It provides authentication and integrity checking but does not encrypt DNS traffic. Crucially, an on-path gateway can still see queries, block them, or force fallback behavior that bypasses DNSSEC validation entirely. Furthermore, this protection only applies when domains are actually signed with DNSSEC — and only when the client or resolver performs the cryptographic validation, which many do not.
What IT and Security Teams Should Do Right Now
The good news is that this attack vector is well-understood and there are concrete technical countermeasures that security teams can implement. The bad news is that most of them require proactive policy enforcement rather than reactive detection — by the time endpoint telemetry fires an alert, the credential theft has already occurred.
Full-tunnel VPN is the strongest control. ReliaQuest's primary recommendation is that enterprises enforce full-tunnel VPN for all corporate devices when connecting to external networks. Unlike split-tunnel VPN (which only routes corporate traffic through the encrypted tunnel), full-tunnel VPN routes all traffic — including DNS queries — through an encrypted connection to a trusted VPN server before it touches any local network infrastructure. This effectively removes the hotel gateway from the trust equation entirely.
However, full-tunnel VPN comes with real operational trade-offs. It adds latency, increases bandwidth consumption, and forces all traffic through corporate infrastructure — a significant consideration for distributed workforces or bandwidth-intensive tasks. Organizations must weigh this against their risk tolerance for travel-related credential exposure.
Encrypted DNS as a complement or alternative. For organizations where always-on full-tunnel VPN is not feasible, deploying DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) in strict mode is a strong alternative. Unlike traditional unencrypted DNS, DoH and DoT wrap DNS queries in encrypted connections, making them much harder for an on-path attacker to intercept or modify. As Cloudflare's developer documentation explains, DoH in particular makes DNS traffic visually indistinguishable from regular HTTPS web traffic, complicating interception.
Block device-code authentication flow in Entra ID. ReliaQuest also advises enforcing Conditional Access policies in Microsoft Entra ID (formerly Azure AD) to block device-code authentication flows. This OAuth flow has historically been abused in credential phishing campaigns because it bypasses many standard authentication checks. Blocking it at the policy level removes a vector that attackers frequently exploit in conjunction with stolen session tokens, as Microsoft's Conditional Access documentation outlines in detail.
The Technical Hardening Checklist: DNS, WPAD, PAC, and More
Beyond VPN and encrypted DNS, ReliaQuest outlines several additional hardening steps that IT and security teams should implement as part of a comprehensive travel security policy. Each of these addresses a specific mechanism that attackers can exploit on compromised networks.
| Control | Risk Addressed | Implementation |
|---|---|---|
| Full-tunnel VPN enforcement | DNS hijacking, traffic interception | Block internet access until VPN tunnel is active |
| DoH/DoT in strict mode | Unencrypted DNS interception | Deploy via Group Policy or MDM profile |
| Disable WPAD via Group Policy | Proxy auto-discovery abuse | Disable in Windows Group Policy (often enabled by default) |
| Restrict PAC file retrieval | Malicious proxy configuration | Limit to approved internal hosts only |
| Block device-code auth flow | OAuth token theft via phishing | Conditional Access policy in Microsoft Entra ID |
| Employee credential verification training | Credential entry on spoofed pages | Train users to verify URL and certificate before entering passwords |
Two controls on this list deserve particular attention because they are often overlooked. Web Proxy Auto-Discovery (WPAD) is a protocol that allows devices to automatically find and configure a proxy server on a network. It is frequently enabled by default in Windows environments, and a malicious gateway operator can exploit it to redirect all web traffic through an attacker-controlled proxy — completely independently of DNS poisoning. Disabling WPAD via Group Policy closes this vector. Similarly, Proxy Auto-Configuration (PAC) files should only be retrievable from approved internal hosts, preventing an attacker from serving a malicious PAC file to redirect traffic.
On the detection side, Microsoft Defender for
Originally reported by CSO Online. Summarised and curated by European Purpose.
