Hotel Wi-Fi Is Rewriting DNS to Steal Your Inbox

You check in at 11pm, join the hotel Wi-Fi, and open your laptop. You do not click a link in an email. You do not open an attachment. You type the Microsoft sign in address yourself, the way security awareness training told you to. The page loads anyway, and it is not Microsoft's.

That is the uncomfortable part of the campaign ReliaQuest published on July 24, 2026. There is no phishing email in the chain. The attack lives one layer below what users are trained to inspect, in the box behind the front desk that answers every guest's DNS query.

Key Takeaways

• ReliaQuest disclosed a campaign, running since at least June 2026 and still active on July 23, 2026, in which attackers take administrative control of hospitality Wi-Fi gateways and rewrite their DNS to redirect Microsoft login domains.
• Compromised gateways were found across multiple US cities plus India and Saudi Arabia, catching guests from financial services, legal, healthcare, energy, and retail organizations.
• Attackers abuse Microsoft's device code authentication flow, so the victim's own approval mints a real OAuth token for the attacker and multifactor authentication never fires as a defense.
• Roughly one third of observed cases also abused the Windows Web Proxy Auto Discovery feature to push malicious proxy settings onto connected machines.
• ReliaQuest says the tradecraft overlaps with the FrostArmada router campaigns tied to Russian military intelligence, but does not assess this operation to be FrostArmada itself.

How Does a DNS Hijack on Hotel Wi-Fi Work?

A DNS hijack works because your laptop accepts whatever resolver the network hands it, without verifying that the answers coming back are true. The captive portal appliance running the hotel network is the compromised component here. ReliaQuest assesses the attackers likely got administrative access through exposed management interfaces such as SSH, SNMP, or web admin panels, paired with weak or reused credentials.

After that the sequence is short. Your machine asks for login.microsoftonline.com. The gateway returns an address it controls. Your browser connects there. As BleepingComputer reported, the gateway forges the plaintext request before it reaches the intended resolver, which means the common workaround of manually setting your DNS to Google's 8.8.8.8 buys you nothing.

Why Doesn't the Padlock Save You?

The padlock certifies that the connection is encrypted to whatever name sits in the address bar, not that the name is the one you meant to reach. Attackers cannot get a valid certificate for login.microsoftonline.com, so the redirect lands users on their own lookalike domains, which do hold perfectly valid ones. The lock closes. The connection is genuinely encrypted. It is encrypted to m365-owa.com.

Free automated certificate issuance means a padlock costs an attacker nothing. The check that still works is reading the hostname, which almost nobody does at 11pm in a hotel lobby. CISA guidance on untrusted networks pushes toward VPN enforcement for exactly this reason: it removes the need for a tired human to make the right call.

Why Doesn't MFA Stop This?

MFA does not stop this because no second factor is ever bypassed, intercepted, or replayed. It is satisfied, correctly, by the victim. Microsoft's device authorization grant exists so you can sign a smart TV or a printer into a Microsoft account: the device shows a short code, you approve it in a real browser, and the token gets issued back to the device.

The abuse inverts the roles. The attacker's client starts the session and receives the code. The fake portal presents that code to you as a routine authorization prompt. You approve it against Microsoft's genuine servers, with your real password and your real MFA challenge, and Microsoft issues a valid, MFA satisfied token to the client that asked for it, which is the attacker's. Nothing was stolen. Everything was granted. It is the same primitive behind the kits in Gblock's writeup on DEBULL and the device code kit wave, only delivered through a network you trusted instead of a message you opened.

Is Hotel Wi-Fi Safe to Use?

Hotel Wi-Fi is safe for traffic you would not mind a stranger controlling, and unsafe for anything that authenticates you. The victim list has no pattern worth reading into, which is itself the finding: CyberInsider's summary lists finance, healthcare, legal, energy, retail, and professional services. Nobody was targeted. Everybody who connected was.

Conference centers make the economics obscene. A compromised home router reaches one household. A compromised conference gateway reaches every attendee of an industry event, which is to say a curated room full of people from the same sector, all of them logged into corporate mail, on the one week of the year they are away from their normal network controls. That is not a broader net. It is a better one.

This Is the Second Gateway DNS Campaign Aimed at Microsoft Logins This Year

In May 2026, Gblock covered FrostArmada, the GRU operation that changed the DNS on 18,000 home routers across 120 countries to harvest Outlook tokens from foreign ministries, before Lumen, Microsoft, and the FBI dismantled it. Two months later the same core idea resurfaces in hotel lobbies.

Most coverage is leading with the APT28 comparison, and that is the least interesting part of the story. ReliaQuest is careful here: it flags overlapping tradecraft but does not assess this to be FrostArmada, and notes the operator looks sloppier, redirecting DNS in blanket fashion rather than filtering by keyword the way a state team would to stay quiet. That is the real headline. A technique that recently required military intelligence resources and 18,000 compromised routers now works for a careless operator with four domains, three IP addresses, and a hotel appliance running default credentials. The playbook has moved downmarket, which historically means volume follows.

What This Means for Your Inbox

The token issued at the end of this chain is a mailbox token. That is the objective, not a stepping stone to one. An attacker holding valid Microsoft 365 access reads your sent items, your contracts, and your calendar, from a session that looks legitimate in every log your IT team reviews, because it is.

What follows the read is worse than the read. Mailbox rules get created to auto file replies from finance so you never see the thread. Contact lists get harvested for the next round of lures, which arrive from your address with your signature and thread history attached. Business email compromise pivots follow, aimed at vendors who have no reason to doubt an email from you. If your organization already treats a stolen session cookie as an incident, treat a device code approval the same way. Gblock's coverage of adversary in the middle attacks on Outlook sessions walks through what that presence looks like once an attacker settles in.

What Should You Do Before Your Next Trip?

If you travel, four habits cover almost all of this, and none of them depend on spotting a fake page.

• Connect the VPN before you touch anything else. An always on full tunnel VPN routes DNS through your corporate network before the hotel gateway can answer it. ReliaQuest names this the primary control, and the ordering matters.
• Never approve a code you did not personally start. If a device code or sign in approval appears and you did not initiate it seconds earlier, someone else did. Deny it and report it.
• Turn on encrypted DNS in strict mode. DNS over HTTPS or DNS over TLS with plaintext fallback disabled is the backup when no VPN is available. Strict is the load bearing word, since a fallback to plaintext hands the gateway its opening back.
• Tether to your phone for authentication. Cellular data costs a few dollars and removes the hostile resolver entirely.

For the people running the tenant, the controls are more decisive:

• Block the device code flow in Entra ID Conditional Access for every user who does not need it, using Microsoft's authentication flows policy. Most workforces never legitimately use it.
• Disable Web Proxy Auto Discovery by Group Policy where it serves no purpose, since it appeared in roughly a third of cases.
• Review sign in logs for successful authentications from unfamiliar ASNs followed quickly by mailbox rule changes, and audit proxy authentication logs for unknown hosts.
• Blocklist the published indicators: m365-owa.com, owa-ms365.com, ms365-device.com, ms365-live.com, and the IPs 31.57.243.154, 104.194.159.150, and 38.146.28.75.
• Roll phishing resistant credentials, FIDO2 keys or passkeys, to travelers first. They are the population sitting on hostile networks.

The lesson underneath all of it is that the network you join is an authentication dependency, whether or not anyone has written it down that way. Hotels are not going to start patching their captive portals. Assume the resolver is lying and build the trip around that.

Sources: ReliaQuest, BleepingComputer, CyberInsider, Microsoft Learn, and CISA.