Hotel Wi-Fi DNS poisoning is stealing Microsoft 365 logins

Your salesperson connects to the Wi-Fi at a conference hotel. No phishing email, no attachment, nothing installed on the laptop. They sign into Outlook, and by the time they land at home the mailbox is being read by someone else. Hotel Wi-Fi DNS poisoning is an active campaign against Microsoft 365 accounts right now, and the worst version of it never asks for a password at all.

What actually happened

ReliaQuest published a threat spotlight documenting a campaign running since at least June 2026 against captive-portal Wi-Fi gateways at hotels and conference centers. The entry point is unglamorous: exposed management interfaces on the gateway combined with weak or reused admin credentials. Once attackers own the gateway, it is the DHCP-assigned DNS resolver for every guest, so it can forge answers. Requests for Microsoft domains resolve to attacker-run hosts — m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, ms365-live[.]com.

The fake login page is the boring half. Two other channels do the real damage. WPAD abuse quietly routes Windows application traffic through an attacker proxy. And on ms365-live[.]com, ReliaQuest documented abuse of Microsoft's device-code authentication flow: the attacker starts a sign-in, the victim approves the prompt, and the attacker's session is authorized. No password is stolen. No token is intercepted. MFA is satisfied, because a real human really did approve a real prompt.

ReliaQuest found compromised gateways in multiple US cities plus India and Saudi Arabia, with traffic from financial services, professional services, legal, health care, energy, and retail. They match the tradecraft to earlier APT28 router campaigns at low-to-medium confidence, and stop short of direct attribution — which is the honest way to say it.

Why hotel Wi-Fi DNS poisoning matters for your business

The uncomfortable part is that every control most small businesses actually bought gets bypassed here. Email filtering doesn't fire, because there's no email. Endpoint protection doesn't fire, because nothing runs. MFA doesn't fire, because the user approved it. The attack lives entirely in the network path between your employee and Microsoft, on infrastructure you don't own and can't audit.

So the fixes are configuration, not products. Turn off the device-code authentication flow in Entra ID Conditional Access unless something you run genuinely needs it — most companies never use it, and leaving it on is a free MFA bypass sitting in the tenant. Push an always-on, full-tunnel VPN so DNS resolution never happens on a stranger's gateway. Disable WPAD by Group Policy. And teach one rule that survives contact with a tired traveler: if a login prompt appears that you did not personally start, deny it.

Sources: ReliaQuest, BleepingComputer.