Hackers Hijack Hotel Wi-Fi Gateways to Steal Microsoft 365 Accounts Without Phishing

Threat actors are compromising hotel and conference-centre Wi-Fi gateways to steal Microsoft 365 accounts from travelling employees, according to ReliaQuest, without sending a single phishing email or infecting a single endpoint.

No phishing, no malware, just a compromised gateway

The campaign targets captive-portal appliances, the systems that control guest access at hotels, conference centres, airports, and coworking spaces. Once attackers gain administrative access to one of these gateways, likely through exposed management services or weak, reused credentials, they can alter DNS settings for every device that connects.

DNS poisoning at the gateway level lets attackers answer a request for a legitimate Microsoft sign-in domain with an attacker-controlled IP address, silently steering the victim toward a spoofed Microsoft 365 login page. Because the manipulation happens at the network level rather than through a malicious link or attachment, standard email security and endpoint protection have nothing to catch. A single compromised gateway can expose every guest device that accepts its DHCP-provided network settings, which in practice means every device that simply joins the hotel or venue Wi-Fi.

Confirmed regional reach, including Saudi Arabia

The activity has reportedly been running since at least June 2026, and ReliaQuest has confirmed affected shared Wi-Fi environments across multiple US cities, India, and Saudi Arabia. Devices from financial services, legal, healthcare, energy, retail, and professional services organisations have all connected through compromised gateways, indicating the campaign targets travellers broadly rather than any single industry or company.

The infrastructure behind it

ReliaQuest-linked reporting identified several spoofed domains used in the operation, including m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com, tied to a small set of IP addresses handling both hosting and DNS poisoning responses. Attackers also attempted Web Proxy Auto-Discovery Protocol abuse against some Windows and macOS systems, a technique that can automatically redirect a device's application traffic through attacker-controlled proxy infrastructure once it joins a hostile network.

A tradecraft overlap worth noting, without overclaiming it

The operation shares several characteristics with prior router-focused activity previously attributed to APT28, also tracked as Fancy Bear or Forest Blizzard, including compromised network devices, malicious DNS reconfiguration, adversary-in-the-middle positioning, and Microsoft 365 credential and token theft as the end goal. ReliaQuest has been careful to note the currently reported activity lacks the direct technical evidence needed to formally attribute this specific campaign to APT28, and that caution is worth preserving rather than collapsing into a firmer attribution than the evidence currently supports.

Why this matters specifically for GCC business travel

Saudi Arabia's confirmed presence on the list of affected locations makes this immediately relevant to any organisation with employees travelling for conferences, client meetings, or regional business events across the Kingdom and the wider Gulf. Business travellers connecting to hotel or conference Wi-Fi to check email or access cloud services are, in this scenario, exposed the moment they join the network, regardless of how cautious they are about clicking links or opening attachments. That makes this a genuinely different risk category from the credential phishing and social engineering threats most corporate security awareness training is built around, since the entry point here requires no user action beyond joining a network most travellers would consider routine.

What organisations should do

Employees travelling for business should avoid signing into Microsoft 365 or other sensitive accounts over shared hotel or conference Wi-Fi where possible, using a trusted mobile hotspot or VPN with its own DNS resolution instead. IT and security teams should consider enforcing DNS-over-HTTPS or DNS-over-TLS on managed corporate devices, which prevents a compromised local network from tampering with DNS responses in the first place.

Conditional access policies that flag or block sign-ins from unfamiliar network ranges, and phishing-resistant authentication methods such as hardware security keys rather than SMS or app-based codes, both reduce the practical impact even if a device does connect through a compromised gateway. Security teams should also treat the published indicators of compromise, the spoofed domains and associated IP addresses, as worth blocking proactively at the DNS and firewall level, particularly for organisations with staff travelling to any of the confirmed affected regions, a baseline practice consistent with the continuous, always-on monitoring approach GCC enterprises are increasingly adopting rather than relying solely on periodic security reviews to catch this kind of network-level compromise.