Hotel Wi‑Fi Hijack Pushes Fake Updates & Phishing

How the attack worked

This campaign targeted people connecting to hotel Wi-Fi networks that use captive portals, the login pages you see before internet access is granted. Attackers manipulated DNS and HTTP traffic on these networks, effectively placing themselves in an adversary-in-the-middle position between the victim and the internet. From there, they redirected users through actor-controlled phishing infrastructure instead of the legitimate hotel login flow.

One path pushed malware disguised as a browser or operating system update. This wasn't a random pop-up: it was triggered by automated connectivity checks that browsers issue when joining a new network, giving the fake update prompt an air of legitimacy. Another path redirected some landing pages into Microsoft device code authentication flows, a real sign-in mechanism that, if abused this way, can be used to capture access to a victim's account.

Why it succeeded

The attack exploited a moment of low suspicion: joining hotel Wi-Fi. Travelers expect a login page and often expect some friction before getting online, so an update prompt or a sign-in request doesn't immediately stand out. Because the manipulation happened at the network level, the redirect could appear on a page that otherwise looked like a normal captive portal, with no obvious sign that traffic had been rerouted through attacker infrastructure.

The use of a real Microsoft authentication mechanism, device code sign-in, added another layer of legitimacy. Most people have never seen a device code prompt and have no baseline for what a suspicious one looks like.

What to watch for

• A software update prompt that appears immediately after connecting to Wi-Fi, especially one not delivered through your OS settings, app store, or company update tool
• A Wi-Fi login page that asks you to download or run a file before granting internet access
• A Microsoft sign-in or device code prompt appearing during what should be a simple Wi-Fi connection process
• Any login request you did not initiate yourself on another device

Building resistance

Traveling employees, executives, sales staff, and anyone using Microsoft 365 single sign-on should treat network-level prompts with skepticism by default. Update software only through official mechanisms, never through a link or download offered by a Wi-Fi login page. Device code sign-in requests should be treated as a red flag unless you personally started that sign-in process on another device; if one appears unexpectedly, stop and report it. Because redirects on public networks are not proof of legitimacy, the safest habit while traveling is to verify any unexpected prompt independently rather than acting on it in the moment.

How did attackers use hotel Wi-Fi to phish users?

They manipulated DNS and HTTP traffic on networks served by captive portals, redirecting users through attacker-controlled infrastructure to phishing pages while the victim believed they were simply connecting to hotel internet.

What made the fake update prompts convincing?

The malware was delivered in response to normal automated connectivity checks issued by browsers, so victims saw an update prompt that appeared right after joining the network rather than through an official update channel.

Why is a Microsoft device-code sign-in prompt dangerous here?

Some captive-portal landing pages redirected victims into a device code authentication flow, a known method attackers use to steal sign-in access, especially risky if the prompt appears unexpectedly during a Wi-Fi login.

Who is most at risk from this kind of attack?

Executives, sales staff, consultants, finance and IT personnel, and any Microsoft 365 users who travel and connect to hotel or public Wi-Fi are the primary targets.