Shocking: Hotel Wi-Fi Phishing Scam Hijacks Microsoft Logins!

Imagine settling into your hotel room, connecting to the guest Wi‑Fi. And pulling up Microsoft 365 to triage a production incident. You enter your credentials, approve the push notification on your phone-then nothing. A few hours later, your team notices anomalous access to the corporate tenant: mailbox rules forwarding sensitive mail, Teams messages sent to external contacts, and cloud resources spun up in regions you've never seen. This isn't just a credential harvest-it's an adversary‑in‑the‑middle (AiTM) operation that subverts the OAuth 2. 0 authorization code flow by proxying tokens in real time. A new hotel Wi‑Fi phishing kit is now using this exact technique to strip MFA tokens from Business travelers. And it's forcing identity engineers to rethink what "verified" actually means.

Reports emerging from security firms and mainstream outlets like Fox News describe a campaign that compromises hotel network gateways to inject malicious redirects before a captive portal even appears. Travelers see what looks like a standard property‑branded sign‑in page, but the form is a reverse proxy that relays every keystroke, session cookie. And MFA claim back to the attacker. Because the phishing infrastructure sits between the user and the legitimate microsoft login, it can capture the resulting session token once authentication completes-even if the MFA prompt was satisfied. To the identity provider, the login looks like it came from the correct IP and browser fingerprint; the only evidence is a subtle TLS mismatch and an unfamiliar URL that most users never inspect.

I've spent the better part of a decade building and auditing identity pipelines across cloud‑native platforms and this attack pattern represents a fundamental failure in how we treat network‑layer trust during authentication. The rest of this article will dissect the technical mechanics, the architectural choices that make hotels such fertile ground. And the concrete countermeasures-from OpenTelemetry instrumentation to FIDO2 enforcement-that platform teams can deploy right now.

The Anatomy of the Attack: How Hotel Wi‑Fi Becomes a Gateway

In a typical hotel deployment, the guest network runs on a flat VLAN with minimal segmentation. A gateway appliance-often a consumer‑grade router rebranded with the property's logo-handles DHCP leases, DNS relay, and the captive portal that intercepts the first HTTP request. Attackers have been observed exploiting weak administrative interfaces or using default credentials to alter the captive portal's redirect target. Instead of pointing to the hotel's legitimate landing page, the gateway silently pushes victims to an attacker‑controlled domain that mimics the Microsoft login endpoint.

The sophistication here isn't in the initial compromise but in the persistence. Once the gateway's configuration is modified, every device that connects and attempts to browse the web is redirected. The phishing page often prefetches the real login page's CSS and background images to appear authentic. And it may even display the correct hotel branding to avoid suspicion. Because the redirect happens before a secure connection is established, the browser's address bar shows the attacker's URL only briefly before the fake page renders, making it hard even for trained users to notice.

This technique leverages the fact that hotel Wi‑Fi is implicitly trusted by millions of business travelers. Unlike a public coffee shop network, guests assume a hotel's infrastructure is at least as secure as a corporate office. And compliance teams rarely enforce strict VPN policies for "temporary" stays. The attack surface is enormous: a single compromised gateway at a major chain can expose thousands of sessions per week.

Reverse Proxy Phishing Kits: The Architectural Shift

Traditional phishing uses a static clone of the target's login page and harvests credentials via a POST handler. That approach is defeated by any form of MFA. Because the attacker never sees the second factor and can't complete the sign‑in. Modern AiTM kits replace that static model with a real‑time reverse proxy, and written in languages like Nodejs or Go and orchestrated via tools like Evilginx, Modlishka. Or custom Nginx configurations, these proxies relay every HTTP request between the victim's browser and the genuine Microsoft login servers.

From a network perspective, the reverse proxy maintains two separate TLS sessions: one with the victim (using a certificate for a look‑alike domain such as login‑microsoft‑online com) and one with the legitimate identity provider. The proxy strips or rewrites HSTS headers, substitutes certificate chains on the fly. And injects JavaScript to disable browser security indicators. In many cases, the phishing kit even prompts the user for MFA and faithfully passes the response to the real server, acquiring an authenticated session cookie or access token that it can then replay independently.

I've reverse‑engineered several of these kits in sandbox environments. And the code quality is surprisingly production‑grade. They use configurable lures, support plugging in different identity providers (Azure AD, Okta, G Suite). And log entire session transcripts-including every token and cookie-to a remote dashboard. The developers clearly understand the OAuth 2. 0 authorization code grant and have specifically designed the proxy to capture the code and exchange it for tokens before the legitimate client does. This isn't amateur malware; it's a product with active maintenance and a support channel.

Bypassing Multi‑Factor Authentication: Token Replay, Not Credential Theft

One common misconception is that MFA is a silver bullet against phishing. In an AiTM attack, MFA isn't broken cryptographically; it's simply proxied. The user sees a legitimate push notification, enters a one‑time code, or even uses a biometric gesture. And the proxy forwards that response to the identity provider. The provider issues a signed token, which the proxy captures and stores. At that point, the attacker can use that token to impersonate the user-often within the token's limited lifetime-without ever needing the password or second factor again.

This token replay is particularly dangerous with Microsoft 365 because its default token lifetime for trusted locations can be up to 90 days. And many organizations extend it for "remembered" devices. An attacker who obtains a valid session token can generate an access token for the Microsoft Graph API, allowing them to read email, browse SharePoint sites, or create new Azure resources. The attack can also snowball by using the compromised identity to add a malicious OAuth app to the tenant, establishing persistence that survives password resets.

RFC 6749, the OAuth 2. 0 Authorization Framework, was never designed to prevent real‑time man‑in‑the‑middle attacks. While PKCE (RFC 7636) mitigates authorization code interception, it assumes the client is executing on a trusted endpoint and that the browser communicates directly with the authorization server-not through a transparent proxy. The hotel Wi‑Fi scenario subverts that assumption, turning a public client like a web browser into a compromised relay. This is why the industry is pushing toward token‑bound presentation, as we'll explore later.

Why Hospitality Networks Are the Perfect Launchpad for This Phishing Campaign

Hotel networks exhibit a trifecta of weaknesses that make them ideal for AiTM phishing: low segmentation, legacy captive portal technology. And a high volume of transient users with corporate credentials. Most properties run an open SSID with no 802. 1X authentication, meaning any device can associate and start sending frames. The captive portal usually relies on DNS spoofing or HTTP interception, both of which can be manipulated by an attacker who gains access to the gateway's configuration interface-often through a default admin panel exposed on the WAN side.

Moreover, hotel IT infrastructure is typically managed by third‑party vendors who prioritize uptime over security patching. Firmware on gateway devices may be years out of date, containing known remote code execution vulnerabilities. In one incident that a colleague of mine investigated, the attacker simply scanned Shodan for a specific model of MikroTik router with the default API port open, then used a 2019 CVE to rewrite the captive portal's redirect rule. That single change funneled every guest's HTTP request to a phishing domain for over a week before anyone noticed the anomalous traffic.

There's also a behavioral element: business travelers are under pressure to be productive as soon as they drop their bags. They're accustomed to seeing branded landing pages that ask for a room number or loyalty code, so a slightly different page doesn't immediately raise suspicion. When the fake page's URL is cloaked behind the gateway's redirect, even a careful user has no easy way to verify authenticity without using out‑of‑band connectivity. Which most won't do.

Analyzing the Phishing Infrastructure: Domain Generation and Certificate Abuse

The domains used in these campaigns rarely live longer than a few hours, making traditional blocklists ineffective. Attackers register domains through privacy‑shielded registrars that accept cryptocurrency payments, often using combinations of keywords like "login," "office," "verify," and "365" along with a fast‑flux DNS technique that rotates IP addresses. A single kit may deploy a dozen domains simultaneously, each tied to the specific captive portal of a targeted hotel chain, to increase the chance that at least one evades Safe Browsing lists.

Certificate issuance is another area where the attackers exploit gaps. They use free automated certificate authorities like Let's Encrypt to provision valid TLS certificates for their phishing domains. The ACME protocol (RFC 8555) requires domain control validation. But for newly registered domains that the attacker controls, this is trivial. The resulting browser padlock-combined with the proxy's ability to strip HSTS-means the victim sees a "secure" connection, even though the server on the other end is hostile. Border Gateway Protocol (BGP) hijacking has also been observed in a few sophisticated cases to redirect traffic to the phishing host without any DNS changes.

Monitoring Certificate Transparency (CT) logs is one of the few scalable defenses against this domain churn. By scanning CT feeds in near‑real time for certificates issued to suspiciously named domains-those containing trademarks like "microsoft" or "office365"-organizations can identify pre‑launch phishing infrastructure and feed those indicators into their internal DNS resolvers or endpoint detection tools. Several open‑source projects, such as certspotter, make this accessible for smaller teams.

Real‑World Observability: Detecting AiTM Attacks with OpenTelemetry and SIEM

When I talk to platform teams about AiTM detection, I emphasize that you can't rely on user reports. By the time an employee notices something odd, the token has already been replayed and the attacker may have established persistence. Instead, you need to instrument the authentication pipeline itself and treat any deviation from expected patterns as a potential compromise. OpenTelemetry, combined with a log aggregation backend like Elastic or Azure Sentinel, gives you the raw telemetry to build these detections.

Specific signals to instrument include the TLS handshake's server‑certificate issuer, the ASN and geographic location of the resolved authorization server IP. And the absence of known headers such as X‑MS‑RequestId that are normally present in Microsoft's responses. In a legitimate flow, the browser communicates directly with login, and microsoftonlinecom, whose certificate chain is well‑known and whose IP falls within Azure's published ranges. In an AiTM flow, the browser talks to a different host, and the server certificate may be issued by Let's Encrypt with a high‑entropy domain. This mismatch is detectable by endpoint Agents or browser extensions.

At the SIEM level, you can correlate Azure AD sign‑in logs with conditional access policy evaluations. Look for sign‑ins where the device isn't registered (yet the user normally uses a company‑managed device), the IP address is anomalous for the user's location history. Or the authentication protocol is switched mid‑session-all indicators that a proxy is in play. Microsoft's Identity Protection now includes an "anomalous token" risk detection specifically for AiTM. And integrating that feed into your SOAR playbook can automate incident response, such as revoking the session token via Microsoft Graph API.

For further reading on anomaly detection in identity pipelines, see our [guide to real‑time observability with