Hotel Wi-Fi DNS Attacks Steal Microsoft 365 Accounts, Bypass MFA

Threat actors compromise hotel and conference center Wi-Fi captive portals to manipulate DNS and steal Microsoft 365 credentials, session tokens, and OAuth permissions — often bypassing MFA without the victim ever clicking a suspicious link. Active since at least June 2026.

Threat actors compromise captive portal Wi-Fi gateways at hotels and conference centers across multiple U.S. cities, India, and Saudi Arabia to intercept and manipulate guest DNS queries. The campaign has been active since at least June 2026. The objective is not malware on the device, but control of the network itself: from there, redirection to fake Microsoft 365 pages enables theft of credentials, session tokens, and OAuth permissions, often bypassing multi-factor authentication without the victim ever clicking a suspicious link.

Key Takeaways

Captive portal gateways were compromised via exposed management interfaces protected by weak or reused credentials, in a campaign documented by ReliaQuest Threat Research.
The DNS poisoning is "blunt," not selective: all DNS queries are hijacked to malicious infrastructure, not just Microsoft ones.
Four domains host the phishing pages: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com, on at least IPs 31.57.243[.]154 and 104.194.159[.]150.
Abuse of the device-code authentication flow enables MFA bypass: the victim enters a code on a genuine Microsoft page but authorizes a session initiated by the attacker.

How the Attack Works: The Captive Portal as Trust Arbiter

Attackers gain initial access to Wi-Fi gateways through exposed administration interfaces — SSH, SNMP, or web panels — protected by weak or reused credentials. ReliaQuest assigns this reconstruction a low-to-medium confidence level, given limited visibility into individual compromised devices. Once on the gateway, they control the local DHCP server and DNS resolver.

Unlike selective DNS poisoning, this campaign operates in "blunt" mode: every DNS query resolves through malicious infrastructure. Microsoft domains are redirected to attacker-controlled servers. The victim opens a browser, types outlook.office365.com, and is redirected to m365-owa[.]com or one of the other identified domains. The page is visually identical to the Microsoft portal.

In roughly one-third of investigated cases, attackers also attempted abuse of the Web Proxy Auto-Discovery (WPAD) protocol: via DHCP option 252 and spoofed 'wpad' DNS records, they force the browser to load a malicious PAC file that routes traffic through a hostile proxy. ReliaQuest could not confirm the actual success of these WPAD abuse attempts.

The MFA Bypass: The Device-Code Flow Trick

The most insidious mechanism is not credential phishing, but abuse of Microsoft's device-code authentication flow. The attacker independently initiates the OAuth flow on a controlled device. Microsoft generates an alphanumeric code and a verification URL. The attacker presents the victim — through the manipulated captive portal or other channels — with a page requesting entry of that code.

The victim accesses the authentic login.microsoftonline.com, enters the code, and confirms the authentication request. What they do not see is that they are authorizing a session initiated by the attacker. The OAuth token, with MFA claims included, is delivered to the malicious infrastructure. The threat actor gains persistent access to the account without ever possessing the password or a second-factor device. Per the ReliaQuest quote reported by BleepingComputer: "What the user can't see is that approving the prompt authorizes a session initiated by the attacker."

This mechanism turns MFA from an obstacle into an accelerator: the issued token is already enriched with strong authentication claims, making sessions harder to detect for traditional monitoring systems.

Why Common DNS Defenses Fail

The illusion of security starts with standard configurations. Many users manually configure public resolvers like Google's 8.8.8.8, believing they are protective. Converging sources document the opposite: DNS traffic to these addresses is in cleartext, transits the compromised gateway, and can be intercepted and altered before leaving the local network.

Even adoption of DNS over HTTPS (DoH) or DNS over TLS (DoT) in the default configuration of common tools offers insufficient protection. The "opportunistic" mode — the default in most implementations — allows fallback to plaintext when encrypted resolution fails. The compromised gateway can force this failure: it blocks or degrades the DoH/DoT connection, the client falls back to cleartext DNS, and the poisoning resumes.

"Two configurations do stop it. A full-tunnel VPN routes all DNS through the corporate tunnel before the gateway can touch the request. Encrypted DNS in strict mode... ensures the gateway can't forge a response" — ReliaQuest, in SecurityAffairs

Only two configurations break the chain: a full-tunnel VPN that routes all traffic — DNS included — through the corporate tunnel before it reaches the hotel gateway; or encrypted DNS in strict mode, explicitly configured to never allow fallback to plaintext.

Who Is in the Crosshairs: Traveling Employees, Not Specific Sectors

Sectors hit by activity observed on compromised gateways span financial services, professional services, legal, healthcare, energy, and retail. Source convergence is clear: this is not sector-specific targeting, but a campaign that pursues traveling employees wherever they connect. Per ReliaQuest, quoted by BleepingComputer: "We observed traffic to these compromised gateways from organizations in a range of industries... confirming this isn't sector-specific targeting, but a campaign that highly likely goes after traveling employees wherever they connect."

The hospitality sector thus emerges as a first-class attack surface. Captive portal gateways — traditionally considered a secondary technology amenity — become the pivot of a compromise chain that can propagate to the entire Microsoft 365 tenant of the affected organization. The responsibility for protection does not rest solely on the end user, but on the security posture of the hotel infrastructure.

Overlaps and Distinctions: Comparison with FrostArmada

The ReliaQuest report notes technical overlaps with tactics documented for FrostArmada, a campaign associated with APT28, particularly in the use of compromised routers as an interception platform. However, two elements distinguish this activity: the specific targeting of captive portal appliances in the hospitality sector, not documented in prior FrostArmada reports; and the employment of WPAD abuse as a complementary technique.

No infrastructure overlaps or code reuse directly linking this campaign to APT28 have emerged to date. Attribution remains unconfirmed: the TTP overlap indicates operational affinity, not actor identity.

What to Do Now

Enforce an always-on full-tunnel VPN on corporate devices before connecting to any guest Wi-Fi network: all DNS traffic must traverse the corporate tunnel before reaching the local gateway.
Configure DNS over HTTPS or DNS over TLS in strict mode, with plaintext fallback explicitly disabled: the client must refuse any non-encrypted resolution.
Review Microsoft 365 authentication policies to restrict or disable the device-code authentication flow where not strictly necessary, or apply Conditional Access policies based on device compliance.
Evaluate periodic audits of captive portal gateway configurations across the hotel and event-partner portfolio, with verification of exposed management interfaces and access credentials.

The Perimeter Has Shifted: From the Workstation to the DNS Packet

This campaign makes explicit a paradox of contemporary security: the device can be patched, the user can be trained, MFA can be active — and the account still falls. The perimeter is no longer the workstation or the phone, but the DNS packet leaving the network interface. Whoever controls that packet before it is encrypted controls the truth of navigation. The hotel is no longer a neutral venue: it is a transit node that can arbitrate trust between user and service.

The lesson for enterprises is structural. Distributing hardened laptops and MFA licenses is not enough: a connectivity policy is needed that treats every non-corporate network as hostile by default, until proven otherwise by cryptographic evidence. For the hospitality sector, the stakes are the trust of the business customer itself: a compromised captive portal steals not just passwords, but the reputation of the infrastructure.

FAQ

Why doesn't 8.8.8.8 DNS protect in this scenario?

Traffic to 8.8.8.8 is in cleartext and transits the compromised gateway, which can intercept and alter responses before they reach Google's resolver.

Is the device-code flow a Microsoft vulnerability?

No, it is a legitimate OAuth flow designed for devices without browsers. The abuse exploits the lack of context verification when the user enters the code, not a flaw in the protocol itself.

Why isn't opportunistic DoH/DoT enough?

Opportunistic mode allows fallback to plaintext DNS when the encrypted connection fails. The compromised gateway can artificially force that failure, inducing the client to reveal queries in cleartext.

Sources

Information verified against cited sources and current as of publication.

Fonti

Sources and references