DNS Poisoning on Hotel Wi-Fi Is a Phishing Problem

ReliaQuest published research this week on a campaign running since at least June: attackers compromising captive-portal gateways at hotels and conference centers, then rewriting DNS on those gateways to push guests toward Microsoft 365 credential-harvesting pages. Compromised appliances turned up across multiple US cities, plus India and Saudi Arabia. Victim traffic came from finance, legal, healthcare, energy, retail, and professional services — no vertical at all, in other words. The targeting criterion was "person who travels."

The coverage has landed on the scary parts: DNS poisoning, MFA bypass, possible APT28 links. But the detail nobody's leading with inverts the standard mitigation advice, and it's sitting in plain sight in the indicator list.

The crypto held

Look at what the attackers actually registered: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, ms365-live[.]com. Four lookalikes.

Ask why they bothered. If you control a gateway's resolver you can answer any query with any address you like, including pointing login.microsoftonline.com straight at your own box.

Because pointing at your own box gets you nothing. You'd win the TCP connection and then stop dead: you can't finish the TLS handshake without a certificate chaining to a root the client trusts, and no CA will issue you one for a domain you don't control. Microsoft's login endpoint also serves HSTS with a one-year max-age and includeSubDomains, so a browser that's been there before won't even render a click-through. (It isn't on the Chromium preload list — I checked — so a fresh profile is a first-visit gamble. Trust-on-first-use carries more weight here than most people assume.)

So the attackers did the thing that works: bought domains they do control and got real certificates for them. Pulling the certificate transparency logs, m365-owa.com has a Let's Encrypt certificate issued 20 July 2026 and valid through October. Free, automated, ninety seconds.

That's the whole story. Nothing broke. The padlock was genuine, the chain validated, the session properly encrypted — to the attacker. DNS poisoning didn't defeat transport security; it relocated the victim somewhere transport security had no opinion.

Which makes "pin your certificates" the wrong lesson

The reflex takeaway — pin certs, force encrypted DNS, tunnel everything — is wrong in one place and incomplete in another.

Pinning is the least useful of the three. It defends against a rogue CA issuing for your domain, and says nothing about a user visiting a different domain that legitimately owns its certificate. Pin login.microsoftonline.com as hard as you like; the victim was never talking to it.

Encrypted DNS genuinely helps and does close the primary redirect chain — fix the resolver, authenticate the transport, and the gateway can't forge answers. But be strict about it: a client that silently falls back to plaintext port 53 when DoH fails is one a hostile gateway can downgrade at will. Kill the fallback or skip the exercise.

Full-tunnel VPN, which ReliaQuest leads with, is the strongest network-layer control and does shut the chain. It's also an infrastructure answer to an identity problem, and it degrades precisely where you need it: BYOD, contractors, phones, and the laptop where the VPN client died at 6am in an airport lounge.

The device-code chain ignores your DNS entirely

Here's why the network-layer fixes are incomplete rather than merely imperfect. One observed chain skips credential theft and abuses OAuth's device authorization grant — RFC 8628, the flow built for smart TVs and other keyboardless hardware.

The shape of it: the attacker initiates authentication, gets a user code, and convinces the victim to approve it. The victim then authenticates on the real Microsoft page, against the real certificate, and completes real MFA. Every control fires correctly and the token lands with the attacker, because the flow's core assumption — that whoever approves the code is whoever requested it — is social, not cryptographic. At the moment that matters there's no phishing site to detect and no DNS to poison.

Microsoft has reached the same conclusion. There's now a Microsoft-managed Conditional Access policy named "Block device code flow," and the docs are blunt about why: "Device code flow is rarely used by customers, but is frequently used by attackers." Managed policies arrive in report-only and auto-enable no sooner than 45 days later unless someone sets them to Off.

Two things to do now:

1. Check whether someone switched that policy Off. That's the real failure mode — not an absent policy, but a well-meaning exclusion left over from a Teams Rooms rollout. Filter sign-in logs by the device code authentication protocol first. If the only usage is conference-room hardware, scope an exception to those devices rather than disabling the policy wholesale.
2. Expect the block to bite later than you think. Entra applies protocol tracking to device-code sessions and it survives token refresh, so a session that began with device code can be blocked on a later, unrelated request. It surfaces as AADSTS530036. That's by design — don't "fix" it.

The structural fix

The control that actually kills this class of attack is phishing-resistant authentication: FIDO2 keys, passkeys, anything built on WebAuthn.

The reason is mechanical, not aspirational. WebAuthn binds a credential to an origin at the protocol level. The browser will not release an assertion scoped to login.microsoftonline.com to a page served from m365-owa.com, and the user gets no say. No dialog to click through, no certificate that helps. TOTP codes and push approvals fail here because both are things a human can be talked into handing over. An origin-bound assertion isn't.

If you're building auth rather than defending it, the adjacent lesson is about defaults. Device code flow shows up in a lot of CLIs because it's easy to implement and survives an SSH session. It's also a phishing primitive you're shipping to users. Where a browser is available, authorization code with PKCE and a loopback redirect — the pattern RFC 8252 recommends for native apps — buys the same UX without decoupling approval from request. Reach for device code only when the device really has no keyboard.

And the gateway itself

The initial access wasn't clever: exposed SSH, SNMP, and web admin panels, plus weak or reused credentials. These are SOHO-class appliances in hotel telecom closets, owned by nobody in particular and patched by nobody at all — one-to-many amplifiers. One box, one weak password, every guest that week.

Captive portals were always the soft spot. The mechanism is a network deliberately intercepting traffic and redirecting you somewhere you didn't ask to go — behavior indistinguishable from an attack, normalized because guests need to click "I agree." The IETF tried to fix that with the Captive Portal API in RFC 8908 and 8910, giving the OS a structured way to discover a portal instead of inferring one from hijacked HTTP. Adoption stayed slow. This campaign is the bill arriving.

None of the tradecraft is new. AiTM kits have harvested M365 sessions for years, and poisoning SOHO routers predates that; ReliaQuest itself claims only low-to-medium confidence on the APT28 overlap, so treat attribution as texture rather than fact. What's new is the delivery economics. Defend this at the identity layer, where the attack actually lands, and let the network controls be the second line they should always have been.