ReliaQuest has identified a widespread campaign in which attackers compromise Wi-Fi gateways at hotels, conference centers, and other captive-portal venues, then poison DNS responses to redirect travelers toward fake Microsoft 365 sign-in pages. The activity has been ongoing since at least June 2026 and was observed in multiple U.S. cities, India, and Saudi Arabia.
The practical warning is narrower than “public Wi-Fi is unsafe.” A traveler can join the venue’s real network and still be exposed because the gateway itself has been altered. ReliaQuest says an always-on, full-tunnel VPN closes the main path; a browser padlock or manually configured public DNS server alone does not prove the route is safe.
How the hotel Wi-Fi redirect works
ReliaQuest assesses with low-to-medium confidence that attackers gained administrative access through exposed management interfaces, weak or reused credentials, or unpatched gateway software. Once inside, they changed the resolver and routing behavior for every guest using that gateway.
- The gateway is compromised. The attacker gains control of a captive-portal appliance that manages guest DNS and routing.
- DNS answers are forged. Requests for legitimate services can be answered with attacker-controlled infrastructure.
- A lookalike login appears. ReliaQuest observed Microsoft-themed domains and pages rather than a compromise of Microsoft’s own cloud.
- Credentials or authorization are captured. Some cases used a fake sign-in form; a limited number paired the redirect with Microsoft device-code authentication.
- The account becomes the target. A valid attacker-initiated device-code approval can issue a token even when the user completes normal MFA.
Domains and artifacts to check
| Indicator | Why it matters |
|---|---|
m365-owa[.]com |
Attacker-controlled Microsoft impersonation domain reported by ReliaQuest. |
owa-ms365[.]com |
Lookalike Outlook/Microsoft 365 domain used in the same campaign. |
ms365-device[.]com |
Domain consistent with the campaign’s device-code lure. |
ms365-live[.]com |
Additional Microsoft-themed domain on related infrastructure. |
38.146.28[.]75 |
Observed forged DNS response and proxy infrastructure. |
Unexpected wpad.dat or PAC file |
About one-third of observed cases also attempted Web Proxy Auto-Discovery abuse; success was not confirmed. |
An indicator match is a reason to investigate, not proof that every device on the network lost an account. Correlate it with the venue, connection time, VPN state, browser history, Microsoft Entra sign-ins, device-code events, proxy activity, and newly created sessions.
Why 8.8.8.8 and MFA may not be enough
A plain DNS request aimed at 8.8.8.8 still crosses the compromised gateway. The gateway can forge a response before the request reaches Google. ReliaQuest says strict encrypted DNS with plaintext fallback disabled can prevent that forgery, while opportunistic encryption may fall back to the exposed path.
MFA remains important, but it does not rescue an authorization that the user is tricked into approving. In the reported device-code path, the user can authenticate on a legitimate Microsoft page while unknowingly authorizing the attacker’s waiting session. Our device-code phishing guide explains why the displayed code and the initiating device must be verified before approval.
What to do after a suspicious hotel Wi-Fi login
- Leave the suspect network. Disable Wi-Fi and move to a trusted cellular hotspot, home connection, or corporate network.
- Tell your security team the venue and time. The gateway may expose many guests, and VPN, DNS, proxy, and identity logs need to be correlated.
- Revoke sessions and suspicious tokens. Reset the password from a trusted device, terminate active sessions, and review device-code authentication and OAuth grants. A password change alone may leave a token usable.
- Inspect the mailbox and cloud account. Check forwarding rules, inbox rules, delegates, recovery methods, OneDrive and SharePoint access, unusual downloads, and new registered devices.
- Review Windows proxy state. Look for an unexpected PAC file, proxy server, DNS setting, network profile, or certificate. ReliaQuest observed WPAD attempts but did not confirm that they succeeded.
- Use a full-tunnel VPN on future public networks. It must establish automatically and carry DNS as well as browser and application traffic. Split tunneling can leave local DNS exposed.
For the broader travel checklist, see how to use public Wi-Fi safely. The key distinction in this campaign is that confirming the venue’s real network name does not confirm the gateway’s DNS behavior.
FAQ
Does HTTPS stop hotel Wi-Fi DNS poisoning?
HTTPS prevents a gateway from silently impersonating a legitimate Microsoft hostname without a valid certificate. The observed campaign instead used lookalike domains, captive-portal expectations, proxy behavior, and device-code authorization. Do not bypass certificate warnings or assume a Microsoft-themed URL belongs to Microsoft.
Does a VPN protect against this campaign?
An always-on, full-tunnel VPN that routes DNS through trusted corporate resolvers addresses the main exposure. A user-started VPN that connects only after sign-in, leaks DNS, or uses split tunneling may leave part of the path exposed.
Should I scan the laptop for malware?
The primary campaign is a network and identity attack, not evidence that malware was installed on every connected device. Scan and investigate locally if a file, extension, certificate, proxy tool, or configuration profile was installed, or if suspicious activity continues away from the venue.
References
- ReliaQuest Threat Research. “DNS Poisoning Tactics Expand to Hospitality Wi-Fi.” ReliaQuest Threat Spotlight, published July 23, 2026, accessed July 24, 2026. ReliaQuest primary research report.
