A Russian military intelligence-linked group has moved its DNS poisoning playbook from home routers into hotel and conference-center Wi-Fi gateways, quietly hijacking Microsoft 365 accounts of traveling corporate employees without a single phishing email.
ReliaQuest’s Threat Research team says the campaign has been active since at least June 2026, with compromised gateways found across US cities as well as in India and Saudi Arabia.
Unlike classic credential theft, this campaign requires zero interaction with the target’s device. Attackers gain administrative control of a hotel’s captive portal appliance, likely through exposed SSH, SNMP, or web admin consoles paired with weak or reused credentials, then poison DNS responses for every connected guest.
DNS Poisoning Hits Hotel Wi‑Fi
Because the gateway is the DHCP-assigned resolver for the entire network, one compromised box can redirect authentication traffic from dozens of organizations simultaneously, spanning financial services, legal, healthcare, energy, and retail sectors.
Four attacker-registered domains m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com were tied to Microsoft-impersonation lures hosted at 31.57.243[.]154 and 104.194.159[.]150, with shared registration patterns suggesting a single operator.
ReliaQuest draws a tradecraft parallel to APT28 (Fancy Bear/Forest Blizzard), the Russian GRU-linked group behind “FrostArmada,” an April 2026 operation that poisoned DNS on SOHO routers to steal Microsoft logins and OAuth tokens.
The overlaps are notable: gateway-level DNS poisoning of Microsoft authentication domains, router-based initial access, and adversary-in-the-middle account takeover all mirror FrostArmada’s approach.

But the divergences matter just as much. This campaign targets hospitality captive portals rather than home routers, uses entirely new infrastructure unlinked to prior APT28 domains, and indiscriminately redirects all DNS traffic rather than selectively targeting keywords a pattern ReliaQuest flags as possibly indicating a less disciplined operator than APT28 itself.
The technique defeats common protections because unencrypted DNS queries leave the device in plaintext, letting the compromised gateway forge responses regardless of which resolver (even 8.8.8.8) is configured. Opportunistic DNS encryption modes, the default in most tools, still permit plaintext fallback exactly the gap the gateway exploits.
Two secondary techniques broaden the blast radius:
- WPAD abuse: In roughly a third of cases, attackers attempted Web Proxy Auto-Discovery hijacking on Windows and Mac devices, potentially rerouting all application traffic through a malicious proxy, not just authentication traffic.
- Device-code flow abuse: On ms365-live[.]com, ReliaQuest observed attackers pairing DNS redirection with Microsoft’s device-code authentication flow, letting them obtain MFA-satisfied OAuth tokens without ever capturing a password.
A related domain, ms365-device[.]com, was found hosting an operator-facing admin panel for managing lure pages and visitor filtering, suggesting the campaign remains active and may expand.
| Control | Effectiveness | Why |
|---|---|---|
| Always-on, full-tunnel VPN | High | Routes all DNS through corporate resolvers before reaching the hotel gateway |
| Strict encrypted DNS (DoH/DoT, no fallback) | High | Prevents gateway from forging responses |
| Opportunistic DNS encryption | Low | Plaintext fallback still exploitable |
| Disabling WPAD via Group Policy | Medium | Eliminates a secondary proxy-hijack vector |
| Blocking device-code flow via Conditional Access | Medium-High | Removes an MFA-bypass authentication path |
ReliaQuest recommends organizations enforce full-tunnel VPN with no split-tunneling exceptions, disable WPAD where unneeded, block Entra ID’s device-code flow, and train traveling staff to scrutinize URLs and certificates before entering credentials on any public network.
As hospitality venues increasingly serve as unwitting chokepoints for enterprise credential theft, the incident underscores that “trusted” public Wi-Fi can no longer be treated as a neutral network layer for corporate devices.