SURIQ
The mitigation everyone attached to this story is a VPN. It closes about half of the attack. Since at least June 2026, a credential-theft operation has been quietly taking over the Wi-Fi gateways inside hotels and conference centers, then rewriting their DNS so a guest who types login.microsoftonline.com lands on a page the attacker controls. ReliaQuest Threat Research, which reported the campaign, saw traffic to the attacker infrastructure from companies in finance, professional services, legal, healthcare, energy, and retail across several US cities and in India and Saudi Arabia. The prize is not the hotel network. It is the Microsoft 365 token a traveling employee carries back to the office.
ReliaQuest reported the tradecraft mirrors the FrostArmada operation attributed to the Russian state group APT28, also called Fancy Bear or Forest Blizzard. It stopped short of directly attributing this campaign, pointing to different domains, different servers, and the focus on hospitality Wi-Fi as reasons to hold back. Treat the actor as unsettled and the technique as the thing to defend against.
One compromised gateway, every guest exposed
The entry point, according to ReliaQuest, is the captive-portal appliance that runs the guest network. Attackers reached its admin functions through exposed management interfaces, things like SSH, SNMP, and web admin consoles, combined with weak or reused credentials. Once they had control of the box, they changed the DNS resolver it hands out to everyone who joins. A device joining a network trusts whatever resolver it is given, so the browser address bar still shows the real domain while the answer behind it points at attacker infrastructure.
Here is the part the coverage underplayed: nothing is installed on the laptop. Your endpoint detection sees an ordinary HTTPS session to what looks like Microsoft. The malicious step happened one hop upstream, on hardware you do not own and cannot inspect. That is why endpoint tooling is effectively blind to this, and why the defense has to move off the endpoint and onto the identity plane. The observed phishing domains included m365-owa[.]com and ms365-live[.]com, registered to look close enough to pass a quick glance.
The four techniques, and the one a VPN does not stop
| Technique | What the attacker gets | Full-tunnel VPN alone stops it? | The control that closes it |
|---|---|---|---|
| DNS poisoning to a fake Microsoft 365 page | The typed password | Yes | Full-tunnel VPN or encrypted DNS in strict mode |
| Adversary-in-the-middle proxy | A live post-MFA session cookie | Yes | Full-tunnel VPN plus phishing-resistant MFA (FIDO2) |
| Device-code flow approval | A valid MFA-cleared OAuth token | No | Disable device-code flow in Entra ID; Conditional Access |
| WPAD or PAC file abuse | All Windows app traffic proxied | Yes | Disable WPAD where it is not used |
The DNS-to-fake-page path harvests a typed password. An adversary-in-the-middle proxy goes further, relaying the real Microsoft login in the background so it can capture the session cookie that is minted after multi-factor authentication succeeds. In roughly one third of the cases ReliaQuest observed, the attackers also tried to abuse the Web Proxy Auto-Discovery feature, known as WPAD, to route Windows application traffic through a proxy of their own. A full-tunnel VPN, on always and routing every request through corporate infrastructure, does close all three of those, because they all depend on controlling the network path between the laptop and Microsoft.
The device-code flow is the exception, and it is the one the VPN advice misses. Microsoft's device-code sign-in exists for input-constrained devices such as a smart TV or a command-line tool: the device shows a short code, and you approve it in a browser where you are already signed in. In this campaign the attacker starts a device-code login and gets the traveler to approve it. A legitimate OAuth token is then issued to the attacker's client, with MFA already satisfied by the user's own tap. That approval happens inside the user's authenticated browser, on any network, at any time. The hotel Wi-Fi is just where the attacker chose to meet the target; a VPN protecting the DNS path does nothing to stop a person approving a prompt.
The token is the prize, not the password
We have written this sentence in different words several times this year, and it keeps being the point. When Microsoft's Azure CLI was hit by a password spray that sailed past MFA, the enabler was a retired login flow, not a cracked password. When ACR Stealer took live sessions, a password reset did not help the victims. When Inc ransomware operators reportedly stole MFA seeds from SonicWall SMA appliances, resetting passwords did not evict the intruder either.
The common thread is that multi-factor authentication protects the front door, and it is worthless once the attacker holds a post-authentication artifact: a session cookie, an OAuth token, an MFA seed. All three techniques in this campaign that beat MFA hand the attacker exactly that kind of artifact. So the standard incident-response reflex, forcing a password reset for the affected users, does not close this out. A token that is already valid keeps working until you revoke it. You have to kill the sessions and refresh tokens, not the passwords.
Watch device-code grants, not the hotel's DNS
You cannot audit the DNS integrity of a network you do not run, and you will not get logs from a hotel's captive portal. What you can watch is your own identity plane, which is where the attack has to surface eventually. Every one of these techniques ends the same way: a token or a sign-in appears in your Microsoft 365 tenant. That is the footprint you own.
Device-code sign-ins are the highest-signal one to alert on. Most organizations barely use the flow, because it is meant for TVs and CLIs, so a device-code grant tied to a normal user account is rare and worth a look. In Entra ID, watch the sign-in logs for the device-code authentication method and for logins arriving from unfamiliar proxy or hosting-provider addresses. This inverts the problem in your favor: instead of trying to spot an attack running on someone else's hardware, you detect its one unavoidable footprint, the grant that lands in your tenant.
Turn off device-code flow before the trip, not after
The order of these matters, because the first one removes the technique the VPN cannot.
- Block the device-code flow with Conditional Access in Entra ID if your users do not legitimately sign in from TVs or CLIs. This is the control that closes the gap the VPN leaves open.
- Deploy always-on, full-tunnel VPN so DNS and web traffic leave through corporate infrastructure before the gateway can touch them, and set encrypted DNS, over HTTPS or TLS, to strict mode so a forged answer is rejected instead of silently accepted.
- Move high-value accounts to phishing-resistant MFA such as FIDO2 security keys or passkeys, which do not produce a replayable cookie for an adversary-in-the-middle proxy to steal.
- Disable
WPADon managed Windows endpoints where it is not needed, which removes the proxy-abuse path entirely. - If you suspect exposure, revoke sessions and refresh tokens for the affected users. A password reset alone leaves a stolen token working.
The travel-security tip is real, but it is the smallest part of the story. The larger one is that identity attacks now aim for the artifact issued after you authenticate, not the secret you type. Defend the token, and the hotel Wi-Fi stops mattering.