CONSUMER ALERT - NETWORK-LEVEL PHISHING

Is hotel Wi-Fi safe? Attackers are poisoning the gateway to fake your Microsoft 365 login

There is no phishing email in this one. You connect to the hotel network, open your browser, ask for your work mail the way you always do, and a Microsoft sign-in page appears. ReliaQuest published the campaign on July 23, 2026. It has been running since at least June, and what was compromised was the Wi-Fi, not you.

SB

SafeBrowz Threat Research Security ResearchJuly 26, 202610 min read

What ReliaQuest found sitting on hotel networks

Every hotel and conference venue has a box between the guest Wi-Fi and the internet. It shows you the "accept the terms, enter your room number" page, and it also answers the most basic question your laptop asks all day: what is the address for this website. That second job is the one that got hijacked.

In its Threat Spotlight published July 23, 2026, ReliaQuest describes attackers gaining administrative access to those captive-portal appliances and configuring DNS response forgery on them. Their summary of why that is so efficient: "A single compromised gateway lets the threat actor silently redirect users' traffic without touching their devices." Nothing is installed, nothing is clicked, and every guest who joins inherits the poisoned answers. How the attackers got in is the least certain part, and ReliaQuest says so, assessing with low-to-medium confidence that access came through exposed management interfaces with weak credentials.

The rest is well evidenced. Activity has been "ongoing since at least June 2026," and compromised gateways were found across multiple US cities and internationally in India and Saudi Arabia, mostly at hotel and hospitality organizations. The guests were picked by where they happened to connect rather than by industry: ReliaQuest saw traffic from financial services, professional services, legal, health care, energy and retail, and reads it as a campaign that goes after traveling employees wherever they log on.

In roughly one third of cases the attackers also went after Web Proxy Auto-Discovery, the Windows feature that lets a network hand a machine its proxy settings automatically. When that works, the laptop fetches a hostile proxy configuration file and routes far more than browser traffic through the attacker. ReliaQuest notes that neither the WPAD step nor the device-code step was documented in earlier FrostArmada-linked reporting. BleepingComputer and CyberInsider both covered it on July 24.

On attribution, be careful, because the researchers were. The tradecraft overlaps with the FrostArmada router campaigns attributed to APT28, but ReliaQuest declined to make the link, noting that its assessment "rests on TTP overlap rather than direct technical linkage ..."

The four fake Microsoft domains, and the three real ones

These are the domains ReliaQuest named. They are live infrastructure in a reported campaign, so we show them defanged. Click any one to run it yourself in the checker further down this page.

• m365-owa[.]com
• owa-ms365[.]com
• ms365-device[.]com
• ms365-live[.]com

Read them the way an office worker reads them and they are fluent. M365 is what everyone calls Microsoft 365. OWA is Outlook Web Access, the browser version of Outlook most companies still call by its old initials. "Device" is the sign-in method the campaign abuses. Every word is one you would expect, and none of the domains belong to Microsoft.

Microsoft's actual surfaces are short and boring, which is the point. Sign-in happens at login.microsoftonline.com, webmail lives at outlook.office.com, and the company itself is microsoft.com. Microsoft never has to spell out "m365" or "owa" in a domain, because it owns the plain ones. Anyone abbreviating the product into the address could not get the real name.

Why "just check the URL" quietly stops working here

Almost every piece of phishing advice ever written, including plenty of ours, ends at the same instruction: look at the address bar. That advice carries a hidden assumption, and this campaign breaks it. The assumption is that you chose the destination. On a poisoned network you did not. You supplied a name, and the network supplied the answer.

The mechanics matter more than the slogan. The gateway forges the DNS reply, so the first hop of your request goes to infrastructure the attacker controls, and the browser ends up on a page the attacker can actually serve. That is why those four lookalike domains exist at all: nobody can present a valid TLS certificate for Microsoft's real sign-in hostname, so the session has to land somewhere they do hold one. The address bar does change. It just changes to something that reads correctly to a Microsoft user, at a moment when you have no reason to be suspicious, because you did not click anything. ReliaQuest puts it this way: "from the user's perspective, the experience may not appear overtly suspicious: they are redirected to what appears to be a Microsoft 365-related sign-in ..."

This is classic pharming, which we take apart in our explainer on why typing the correct address can still land you on a fake site, except the scale changed: pharming usually meant one hacked home router, and a conference-center gateway does it to every badge in the building. It is also not the rogue access point trick from the evil twin Wi-Fi guide, where you connect to a network the attacker created. Here the network is the real one, and the hotel is a victim too. When WPAD succeeds, the interception moves below the browser entirely, into the operating system's proxy settings, where squinting at a URL shows you nothing.

So what survives? Judging the page rather than the route. A scanner that resolves and fetches the destination from its own infrastructure, instead of through the network you are sitting on, sees either the page Microsoft would have given you or an address wearing Microsoft's clothes.

The device-code version, where the address really is Microsoft's

Microsoft's device-code flow exists for a genuine reason. Some things that need to sign you in have no usable browser: a command-line tool, a smart TV, an IoT device. So the device shows a short code, and Microsoft's documented flow sends you to microsoft.com/devicelogin on a phone or laptop to type it in. The code is typically valid for about 15 minutes. Approve it, and the far-away device is signed in.

Now put an attacker at the other end. ReliaQuest observed exactly that on ms365-live[.]com: "approving the prompt authorizes a session initiated by the attacker. Once approved, Microsoft issues valid OAuth tokens to the attacker-controlled client ..." Their conclusion is the sentence to remember: "the attacker can obtain MFA-satisfied access to Microsoft 365 without collecting credentials on a fake page ..."

Follow what that means for your defenses. The sign-in page can be genuinely Microsoft's. The MFA prompt is genuinely yours, and you genuinely approve it. The token is genuinely valid. Nothing in that chain is counterfeit except the identity of the thing being signed in, and that is the one detail no page shows you.

We covered this technique when the FBI flagged it, in the Microsoft device code phishing explainer, and it belongs to the token-theft family described in how adversary-in-the-middle kits bypass 2FA. What is new here is the delivery: no lure needed, because the network walked you to the prompt. A code or approval you did not start is a request to sign somebody else in, and it does not matter how real the page around it looks, because the page around it is real.

What actually protects you on a hotel network

Ranked by how much of the problem each one removes, not by how easy it is.

• Send your traffic somewhere else entirely. ReliaQuest's primary recommendation is an always-on VPN in full-tunnel configuration, so all DNS requests route through trusted resolvers rather than the venue's. The consumer version costs nothing: use your phone's hotspot for anything involving a sign-in.
• Turn on encrypted DNS, and check which level you are on. The detail most guides skip is that the defaults are polite to the network. Firefox's DNS over HTTPS levels are explicit: Default Protection disables secure DNS when a network tells Firefox not to use it, while Max Protection always uses the encrypted resolver and warns you instead of silently dropping back. Chrome's secure DNS runs in automatic mode and will look the site up unencrypted if it has trouble, but picking a named provider stops that fallback.
• Turn off automatic proxy discovery on Windows if you do not need it. That is the "Automatically detect settings" checkbox, and it is what WPAD abuse depends on. ReliaQuest recommends disabling it via Group Policy where it is not required.
• Never complete an authentication you did not begin, and reduce how often you need to. Open your mail before you leave and treat the hotel browser session as somewhere you read things rather than somewhere you prove who you are.

Six things that should stop you mid sign-in

• You are being asked to sign in at all. You were already signed in this morning. A session that needs re-authentication the moment you join a new network is the loudest signal in this campaign.
• The domain abbreviates the product. m365, ms365, owa, o365. Microsoft owns the plain names and has no reason to use shorthand.
• A code appears that you did not ask for. Device-code prompts belong to devices without browsers. If you are already looking at a browser, a code has no legitimate job to do.
• The page arrived without you clicking anything. You typed an address or opened a bookmark, and something else answered.
• A certificate warning you are tempted to click through. On a network doing this, it is not the hotel's flaky Wi-Fi. Close the tab.
• Your phone disagrees with your laptop. Load the same page over mobile data. If two devices show different things on one address, the network is editing your answers.

If you already signed in from hotel Wi-Fi

Move in this order, and do all of it from a different network. The hotel one is the last place to run a recovery.

Change the password and sign out everywhere, right away. Open the Microsoft account page yourself rather than following any link. Both steps matter, because Microsoft's revocation table shows a password change revokes only password-based refresh tokens, while revoking your refresh tokens, which is what sign out everywhere does, revokes every class.

Then tell your employer's IT or security team, with the date and venue. Even after revocation there is a tail: access tokens last for 1 hour by default, so an attacker keeps working access until the current one expires. An administrator can also revoke sessions tenant-side and disable any device the attacker registered, which a personal password reset does not touch.

Check your mailbox rules and forwarding. Microsoft 365 takeovers are usually followed by a quiet inbox rule that files or forwards anything mentioning invoices, payments or the word "security". Remove anything you did not create. Colleagues getting odd meeting invites from you is the usual first sign, the pattern behind calendar-based phishing from inside compromised tenants.

Assume anything you signed into on that network is exposed, then work through what to do in the first hour after a scam. In the United States, report it to the FBI at ic3.gov, and tell the venue. Their gateway is the compromised asset and they may not know.

What our scanner sees that the address bar does not

SafeBrowz runs a 3-layer detection architecture: Local + APIs + AI. What matters here is where each layer does its work.

• Layer 1 - Local detection: 60+ URL patterns, a 550+ brand database and our community blocklist screen the address before the page paints.
• Layer 2 - API checks: the domain is cross-referenced against Google Safe Browsing, PhishTank, URLhaus, ScamAdviser feeds and a 30+ scam TLD watchlist, plus our own blocklist. That lookup runs from our infrastructure, so the hotel's poisoned resolver has no influence over it. The brand check runs on the same pass: a domain that spells Microsoft out, something like microsoft-365-verify-login[.]com (an illustrative example, not one of the reported domains), is flagged on the name alone. This campaign shows why one signal is never enough, because m365, ms365 and owa are shorthand rather than the brand string, so all four reported domains are caught by the blocklist instead.
• Layer 3 - AI deep scan (Premium): AI content analysis via our proxy reads the fetched page the way an investigator would: Microsoft wordmark, an Outlook Web Access sign-in layout, a device-code field, on a domain Microsoft does not own. That earns a danger verdict in seconds, including on pages too new for any blocklist.

The honest limit, stated plainly. We resolve and fetch a URL independently of whatever network you are on, so a poisoned answer at the gateway does not change what we see. But a browser extension cannot repair a poisoned resolver, cannot undo WPAD routing your other applications through someone else's proxy, and cannot flag the device-code trap when the page in front of you genuinely is Microsoft's. Those gaps close with different tools: a trusted DNS or VPN, and a personal rule about never completing an authentication you did not start.

Detection signatures are derived from threat-intelligence research and our internal brand database, not from user browsing data. SafeBrowz does not store per-user browsing history.

Frequently asked questions

Is hotel Wi-Fi safe to use in 2026?

For browsing, mostly. For signing in, treat it as untrusted. ReliaQuest reported on July 23, 2026 that attackers had taken administrative control of captive-portal gateways at hotels and conference venues across multiple US cities, India and Saudi Arabia, and were forging DNS answers to send guests to fake Microsoft 365 sign-in pages. The rule is not to avoid hotel Wi-Fi but to avoid authenticating over it: use a full-tunnel VPN or your phone's hotspot whenever you enter a password.

How can a fake Microsoft login appear if I typed the address myself?

Because typing the address decides the question, not the answer. Your device asks the network which server that name belongs to, and on these compromised gateways the answer was forged, so the request went to attacker infrastructure and the browser landed on a lookalike domain. You never clicked a link, which is why it does not feel suspicious.

Does multi-factor authentication protect me from this attack?

Not in the device-code version. ReliaQuest observed attackers abusing Microsoft's device-code flow on ms365-live[.]com, where approving the prompt authorizes a session the attacker started and Microsoft issues valid OAuth tokens to the attacker's client. In ReliaQuest's assessment the attacker gets MFA-satisfied access without collecting credentials on a fake page. The defense here is refusing any code or approval you did not personally initiate.

Which domains were used in the hotel Wi-Fi campaign?

ReliaQuest named four attacker-registered lookalikes: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com and ms365-live[.]com. All four use Microsoft product shorthand Microsoft has no reason to use, because it owns the plain names. Its genuine sign-in surface is login.microsoftonline.com, its webmail is outlook.office.com, and the company site is microsoft.com.

I signed in to Microsoft 365 on hotel Wi-Fi. What should I do now?

Get off that network, then change the password and use sign out everywhere from the Microsoft account page you opened yourself. Both steps matter: Microsoft's revocation table shows a password change revokes only password-based refresh tokens, while revoking your refresh tokens revokes every class. Then tell your employer's IT or security team with the date and venue, because access tokens already issued last for 1 hour by default, and an administrator can revoke sessions tenant-side and disable a device the attacker registered. Also remove any mailbox rule, forwarding address or connected app you did not create.

Last updated 2026-07-26