Key Takeaways
- Attackers compromise hotel and conference Wi‑Fi gateways to alter DNS settings, silently redirecting users to fake Microsoft 365 login pages that harvest credentials.
- The fraudulent pages can also capture device‑code approvals, generating legitimate OAuth tokens that bypass traditional multifactor authentication.
- Switching to a public DNS resolver does not stop the attack because a compromised gateway can forge DNS responses before the query reaches an external server; encrypted DNS or a VPN is required for real protection.
- Travelers should use an always‑on full‑tunnel VPN or a phone hotspot, scrutinize URLs, avoid unexpected device‑code prompts, keep software updated, and run reputable security tools.
- Organizations should disable unnecessary Microsoft Entra ID device‑code flows, review login logs for anomalies, and turn off WPAD where it is not needed.
Overview of the Hotel Wi‑Fi Phishing Campaign
Since at least June, cybercriminals have been tampering with Wi‑Fi equipment in hotels and conference centers across several U.S. cities. By gaining administrative access to the gateways, they modify the device’s DNS settings so that requests for legitimate Microsoft 365 login pages are redirected to convincing look‑alike sites. The network name remains unchanged, other websites load normally, and users stay unaware until they enter their username and password on the spoofed page. The campaign has hit organizations in finance, professional services, legal, health care, energy, and retail, indicating the attackers target traveling employees rather than a single industry.
How DNS Manipulation Works on Compromised Gateways
A Wi‑Fi gateway resolves domain names to IP addresses for every connected device. When attackers control the gateway, they can replace the DNS entry for Microsoft‑related domains with the IP address of a server hosting a fake login page. Consequently, a user’s request for login.microsoftonline.com is answered with the fraudulent server’s address, while the underlying TCP/IP connection appears normal. This subterfuge occurs at the name‑resolution stage, so there are no obvious signs of network tampering until credentials are submitted.
How Attackers Gain Access to Wi‑Fi Gateways
ReliaQuest researchers noted several plausible entry points. Some gateways expose administrative dashboards directly to the Internet, allowing attackers to brute‑force weak passwords or exploit unpatched web interfaces. Others run outdated firmware containing known vulnerabilities; if a hotel delays patching, attackers can leverage those flaws to obtain root access. Once inside, the malicious actor can reconfigure DNS settings without touching each guest’s laptop or phone, meaning a single compromised gateway can affect dozens or hundreds of concurrent users during a stay or conference.
Fake Microsoft 365 Pages and Credential Harvesting
The fraudulent domains used—such as m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com—contain familiar Microsoft terms to lower suspicion. When a traveler lands on one of these pages, the layout closely mimics the genuine Microsoft sign‑in interface, prompting entry of a corporate email address and password. Captured credentials grant attackers access to mailboxes, OneDrive, SharePoint, and any other services linked to the Microsoft 365 account. With this foothold, threat actors can impersonate employees, launch internal phishing campaigns, divert payments, or explore further lateral movement within the victim’s organization.
Device‑Code Authentication Bypass and MFAT Evasion
In a subset of incidents, attackers abused the device‑code flow used for multifactor authentication. The fake login page displayed an authorization request that looked like a legitimate part of the sign‑in process. Behind the scenes, the attacker had already initiated an authentication session with Microsoft’s servers. When the user approved the prompt, Microsoft issued a valid OAuth token to the attacker’s client, granting account access without needing a password or one‑time code. Because the user performed the approval step, the MFA system perceived the transaction as legitimate, allowing the attacker to bypass traditional second‑factor defenses. Any unexpected device‑code request should be treated with suspicion and verified through a trusted IT channel before approval.
Attempts to Abuse WPAD for Proxy Manipulation
Approximately one‑third of the observed incidents included attempts to exploit the Web Proxy Auto‑Discovery Protocol (WPAD). Windows devices can use WPAD to automatically locate a proxy configuration file when none is manually set. Attackers responded to WPAD queries with a malicious proxy auto‑configuration (PAC) file designed to route traffic through a server under their control. If successful, this would enable the hackers to inspect, modify, or inject content into non‑HTTPS traffic, opening additional avenues for data exfiltration or malware delivery. ReliaQuest could not confirm whether these WPAD manipulations succeeded, but their presence shows the adversaries are looking beyond credential theft to broader network manipulation.
Why Public DNS Switches Are Insufficient and the Role of Encrypted DNS
Changing a device’s DNS resolver to a public service like Google’s 8.8.8.8 does not stop this attack because a compromised gateway can forge DNS responses before the query reaches the external resolver. The device believes it is communicating with the chosen public DNS server, while the gateway silently substitutes the answer with an IP address pointing to the fraudulent site. Encrypted DNS protocols such as DNS‑over‑HTTPS (DoH) or DNS‑over‑TLS (DoT) provide stronger protection by preventing the local gateway from reading or altering the queries, but they must be configured in strict mode to avoid fallback to unencrypted DNS. Consequently, relying solely on a public DNS change is inadequate; travelers need additional layers such as a VPN or encrypted DNS to mitigate the risk.
Practical Safety Steps for Travelers
Treat any public wireless network as untrusted. First, deploy an always‑on full‑tunnel VPN that encrypts all traffic and routes it through a trusted server; activate it before opening email, accessing financial accounts, or signing into any service. Second, consider using your phone’s cellular hotspot for short, sensitive tasks, monitoring data usage to avoid overage charges. Third, scrutinize the full URL before entering credentials—look for subtle misspellings or unfamiliar domains, and prefer bookmarked links or the official Microsoft app over pop‑up prompts. Fourth, never approve an unexpected device‑code authentication request; verify its legitimacy with your IT department via a known channel. Fifth, keep operating systems, browsers, and security software up to date, installing patches and restarting as required. Sixth, run reputable antivirus or endpoint protection with web‑shielding enabled to block known phishing sites and malware.
Recommendations for Organizations and Closing Thoughts
Companies should harden identity and network configurations. Disabling Microsoft Entra ID device‑code authentication when not needed removes a potent abuse vector. Regularly reviewing sign‑in logs for atypical locations, unfamiliar devices, or questionable application approvals can reveal compromised accounts early. Network teams should disable WPAD on corporate Windows devices unless a legitimate proxy is required, and monitor for unexpected PAC file activity. Additionally, encouraging employees to use corporate‑provided VPNs and educating them about the signs of Wi‑Fi‑based phishing cultivates a security‑aware culture. Ultimately, while hotel Wi‑Fi remains a convenient amenity, recognizing that its underlying infrastructure can be weaponized underscores the necessity of layered defenses—encryption, vigilant verification, and proactive organizational policies—to keep business travelers safe from increasingly sophisticated credential‑theft campaigns.