It's late July and half the workforce is working from wherever they can: hotels, trade shows, airports. Just this week, ReliaQuest published that since at least June 2026 there has been an active campaign compromising Wi-Fi appliances at hotels and conference centers, changing their DNS and redirecting guests to fake Microsoft 365 sign-in pages. Your laptop doesn't have a single byte of malware on it. It's the network that's lying.
What exactly is going on
The attackers aren't going after your laptop: they go after the hotel's captive portal — the appliance that shows you the welcome page and grants you network access. According to ReliaQuest, the most likely way in is management interfaces exposed to the Internet (SSH, SNMP, web administration consoles) combined with weak or reused administrator credentials. Once inside, they change the gateway's DNS configuration: you type the legitimate address and the network answers with the attacker's IP.
The campaign uses at least four domains that sound like Microsoft without being Microsoft: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com and ms365-live[.]com. Compromised portals have been seen at hotels and conference venues across several US cities, India and Saudi Arabia, and traffic to that infrastructure came from organizations in finance, legal, healthcare, energy, retail and professional services. In other words: they're not targeting a sector. They're targeting whoever travels.
They can take your account without stealing your password
The refined part of the campaign isn't the classic fake page. In a limited number of cases — ReliaQuest's own wording — they observed abuse of Microsoft's device code flow: the attacker starts an authentication themselves, and you get a screen asking you to enter a code or approve a request. What you can't see is that by approving you are authorizing the session the attacker initiated: Microsoft issues their client a perfectly legitimate OAuth token with — in ReliaQuest's words — "MFA-satisfied access to Microsoft 365". Your MFA app raises no alarm because nothing in the process is fake. The one being fooled isn't the system: it's you, approving someone else's session.
Microsoft considers this flow risky enough that it maintains a managed Conditional Access policy — "Block device code flow" — which it creates in tenants in report-only mode and switches on itself no sooner than 45 days later if nobody touches it. Microsoft's own documentation sums it up bluntly: customers rarely use it; attackers use it frequently. If you run a tenant, today is a good day to check what state that policy is in.
The padlock won't save you (and not because TLS is broken)
Let's be precise, because it's easy to over-scare here: this campaign does not break HTTPS. Nobody is forging the certificate for microsoft.com. You simply never get there: the poisoned DNS and the portal itself redirect you to a similar-looking domain with its own valid certificate and its own padlock in the address bar. Everything the browser can verify, it verifies. What it can't verify is that you meant to go somewhere else.
And there's something we find more interesting than the technique itself: years of captive portals have trained all of us to accept weirdness when connecting to hotel Wi-Fi. Redirects, notices, "sign in to continue", pages getting in the way. This campaign doesn't exploit a CVE on your laptop; it exploits that habit. The one place where a page intercepting your browsing feels normal is exactly the place where this attack works best.
On attribution: ReliaQuest sees similarities with the SOHO-router FrostArmada campaigns, linked to APT28 and disrupted in April 2026, but rates it low-to-medium confidence and points no fingers. Neither will we. For defending yourself, the attacker's passport is beside the point.
The perimeter goes on holiday with you
That hotel Wi-Fi is hostile territory is not news; we took that for granted fifteen years ago. The news is the industrialization: compromising the hotel's appliance turns every guest passing through it into a target, with no individual phishing, no malware, without touching a single laptop. One compromised appliance, and every guest who connects is a potential victim. That's scale, and scale is what turns an old trick into a new problem.
And the lesson is the one that gives Zero Trust its name: if your company's security depends on which network your employee is sitting on, you don't have security; you have geography. The right model treats every network — the hotel's, your home's, the airport's and, yes, the office's too — as if it were the hotel's: hostile until every access proves otherwise.
What we would do
- 1.Full-tunnel corporate VPN, always on, with DNS inside the tunnel. It's the control ReliaQuest singles out as closing the primary exposure in one move: if all the laptop's traffic leaves encrypted towards your network, the hotel's DNS is irrelevant. With one honest caveat: the VPN gateway itself is a juicy target — we covered that with the SonicWall SMA zero-days — so keep it patched, watched, and with no implicit trust behind it.
- 2.Block device code flow with Conditional Access — or, at minimum, check the state of Microsoft's managed policy. If you have Teams Rooms or other devices that genuinely need it, make surgical exceptions, not an open door for everyone.
- 3.Phishing-resistant MFA (passkeys/FIDO2) for the classic part of the attack: against a passkey bound to the real domain, the lookalike page has nothing to ask you for — there's no password to type into the wrong place. We covered this around the retirement of SMS as MFA in Entra. Important caveat: passkeys do not protect you from the device code trick; that one is cut off by point 2.
- 4.Mobile data for travel. A data eSIM or tethering off the phone avoids the hotel network for most travel work. It's cheap and boring, like almost everything that works.
- 5.Look at the sign-in logs. Device code authentications you don't expect, and access that lines up with your people's travel dates, are exactly the signal to hunt for in your Entra logs this week.
What we would NOT do
- ✗Ban hotel Wi-Fi by memo, with no alternative. People connect anyway; you just stop hearing about it. If travel is part of the job, secure connectivity on the road is part of the infrastructure.
- ✗Blame the user. The lying DNS belonged to the hotel and the page had its padlock. When the flaw is in the design — trusting the network — training helps, but it doesn't fix it.
- ✗Wait for the hotel to fix it. Their captive portal is not your appliance: you can't patch it, audit it, or know whether it's already compromised. Assume it is, and design so that it doesn't matter.
In short
The uncomfortable question for Monday is this: if tomorrow someone on your team approves an access code from the Wi-Fi of a trade-show hotel, does your tenant block it, does your team detect it, or do you find out once they've already read the executive inbox? All three answers exist. Only one of them is up to the attacker.
Sources (verified): campaign, technique, domains, sectors and mitigation — ReliaQuest Threat Spotlight (Jul 23, 2026); coverage and device code flow abuse — BleepingComputer (Jul 24, 2026); "Block device code flow" managed policy — Microsoft Learn.
Does your security hold up outside the office?
At everyWAN we design and operate Zero Trust access so your company's security travels with every employee, wherever they connect from. If you don't know what would happen today to one of your laptops in a hotel, we'll look at it with you.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN