The Invisible Perimeter: How Compromised Hotel Wi-Fi Gateways Are Hijacking Enterprise Credentials

In the modern era of the "work-from-anywhere" professional, the hotel lobby, conference center lounge, and airport cafe have become the de facto satellite offices of the global workforce. For the traveling executive, the promise of high-speed, "convenient" public Wi-Fi is rarely questioned—it is an expectation. However, a sophisticated new threat vector is weaponizing that very expectation.

According to the latest threat intelligence from the ReliaQuest Research team, malicious actors have been systematically compromising the "captive" Wi-Fi gateways—the devices that manage guest network access—at hotels and public venues. By gaining administrative control over these gateways, attackers can silently hijack Microsoft 365 authentication traffic. This method bypasses the need to infect the user’s device, deploy malware, or trick the user with sophisticated phishing emails. It is a fundamental subversion of the network itself.

Main Facts: The Anatomy of a Silent Hijack

The core danger of this campaign lies in the "fundamental trust" users place in their local network environment. When a device connects to a hotel’s Wi-Fi, it expects the network to act as a neutral pipe. Attackers, however, have turned this pipe into a funnel for credential theft.

By compromising the gateway, threat actors execute DNS (Domain Name System) poisoning. When a user attempts to log into their Microsoft 365 account, their browser sends a request to resolve the address login.microsoftonline[.]com. A compromised gateway intercepts this request and, instead of returning the legitimate IP address provided by Microsoft, returns an IP address controlled by the attacker.

Because the request is redirected before it ever leaves the local network, the user’s device remains unaware that it is being fed fraudulent information. The user is presented with a pixel-perfect replica of the Microsoft login portal. Once they enter their credentials, the attacker captures them in real-time. This attack requires no malicious attachments, no suspicious links, and no endpoint compromise, making it nearly invisible to traditional, device-centric security software.

Chronology: The Evolution of a Persistent Threat

While the tactical use of DNS poisoning is not a new concept—it has historically been observed on small, poorly secured home routers—the recent campaign signals a troubling evolution toward "higher-level" infrastructure.

• June 2024: ReliaQuest threat researchers first identified a pattern of suspicious activity involving the redirection of enterprise authentication traffic originating from hospitality venues.
• Summer 2024: The campaign intensified, with researchers tracing the activity across multiple geographic regions, including the United States, India, and Saudi Arabia.
• Late 2024: Intelligence analysis confirmed that the threat was not limited to a single chain or provider, but rather a widespread exploitation of vulnerable gateway hardware.
• Ongoing: The campaign remains active, with threat actors continuously registering new domains (such as m365-owa[.]com and ms365-live[.]com) to avoid domain-reputation-based filtering.

The attackers gain their initial foothold primarily through the exploitation of weak or reused administrative credentials. Many of these gateway appliances come pre-configured with default passwords or have exposed management interfaces—such as Secure Shell (SSH), Simple Network Management Protocol (SNMP), or insecure web consoles—that are accessible directly from the public-facing internet.

Supporting Data: A Sector-Agnostic Campaign

The breadth of this campaign suggests that attackers are casting a wide net, targeting high-value individuals regardless of their industry. ReliaQuest’s telemetry shows that impacted users span a diverse range of sectors, including:

• Financial Services: High-value targets for sensitive transaction data.
• Legal Services: Risks involving privileged communications and proprietary documentation.
• Healthcare: Exposure of patient data and regulatory compliance vulnerabilities.
• Retail and Energy: Potential entry points for further lateral movement within corporate infrastructure.

The researchers emphasize that the "reputational dimension" of these attacks is significant. For hotel chains and conference centers, the compromise of a guest’s network traffic represents a profound failure of their duty of care. Even if the venue is not the primary target, the fact that their infrastructure was used as a staging ground for identity theft creates a massive trust deficit.

The Myth of "Safe" DNS and DNSSEC

A common response to the threat of DNS poisoning is to manually configure devices to use "safe" or "reputable" DNS resolvers, such as Google (8.8.8.8), Cloudflare (1.1.1.1), or OpenDNS. However, ReliaQuest’s analysis warns that this is a "false sense of security."

The reason is simple: changing the destination of the DNS query does not change the "road" the data must travel to get there. Because standard DNS queries are unencrypted, the packets must pass through the compromised gateway to reach the internet. The gateway, acting as a gatekeeper, can simply inspect, block, or redirect the query before it ever reaches the chosen external resolver.

Furthermore, while Domain Name System Security Extensions (DNSSEC) offer a layer of digital signature validation, they are not a silver bullet. DNSSEC ensures the integrity of the DNS response, preventing forgery, but it does not provide confidentiality. A malicious gateway can still intercept the request, drop it, or force the device to "fallback" to an insecure state. Moreover, many stub resolvers—the components on user devices that handle DNS—do not perform the necessary validation to enforce DNSSEC, leaving the user exposed regardless of the security measures implemented on the server side.

Implications for Corporate Defense

The shift toward gateway-level attacks forces a paradigm shift in how enterprises approach perimeter security. The traditional "castle and moat" strategy, which assumed that the local network was a trusted zone, is effectively obsolete.

The Requirement for Full-Tunnel VPNs

The most robust defense, according to ReliaQuest, is the mandatory use of full-tunnel Virtual Private Networks (VPNs). By forcing all device traffic—including DNS queries—through an encrypted tunnel to a trusted corporate server, the local network (the hotel gateway) is rendered blind. It can see that encrypted traffic is moving, but it cannot inspect, modify, or redirect it.

However, this comes with trade-offs. Full-tunnel VPNs introduce latency, increase bandwidth costs, and can complicate the user experience. For organizations with highly distributed workforces or those reliant on bandwidth-heavy cloud applications, a blanket "always-on" VPN policy may be impractical.

Conditional Access and Identity Hardening

Beyond network controls, enterprises must harden their identity management systems. ReliaQuest recommends:

1. Enforcing Conditional Access: Organizations should use tools like Microsoft Entra ID to enforce strict conditional access policies. This includes blocking "device-code" authentication flows, which are often abused by attackers to bypass traditional login screens.
2. Hardening WPAD and PAC: Web Proxy Auto-Discovery (WPAD) and Proxy Auto-Config (PAC) files can be manipulated to redirect traffic at the system level. Enterprises should disable these features where they are not explicitly required to prevent local network interference.
3. Encrypted Transport: Where possible, organizations should enforce protocols that provide end-to-end encryption for all DNS traffic, such as DNS-over-HTTPS (DoH). While this can be blocked by a malicious gateway, it adds a layer of friction that increases the difficulty for the attacker.

The Detection Gap

Perhaps the most chilling takeaway from the ReliaQuest research is the limitation of detection. Endpoint-level telemetry—such as Microsoft Defender—may record "DnsConnectionInspected" events that flag connections to known malicious domains. However, by the time these logs are generated and processed, the credential harvest has already occurred.

In this scenario, detection is a post-mortem process. It tells the security team that a breach happened, but it does not prevent the account compromise. This is why the industry must pivot toward preventative architecture rather than detection-based response.

As the boundary of the enterprise continues to dissolve, the "captive" portal remains one of the most vulnerable and overlooked gaps in the security stack. For organizations, the message is clear: if you cannot trust the network you are connecting to, you must bring your own secure network with you. The era of the "convenient" public connection must be replaced by the era of the "verified" connection, or the identity of the enterprise will remain at risk.