{"id":16515,"date":"2026-07-28T02:31:37","date_gmt":"2026-07-28T02:31:37","guid":{"rendered":"https:\/\/newestek.com\/?p=16515"},"modified":"2026-07-28T02:31:37","modified_gmt":"2026-07-28T02:31:37","slug":"hackers-are-compromising-hotel-wi-fi-gateways-to-hijack-microsoft-365-accounts","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=16515","title":{"rendered":"Hackers are compromising hotel Wi-Fi gateways to hijack Microsoft 365 accounts"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

Traveling enterprise employees beware: Think twice before you log onto that oh-so-convenient public Wi-Fi.<\/p>\n

Since at least June, threat actors have been compromising \u201ccaptive\u201d Wi-Fi gateways and other portal appliances at hotels, conference centers, and similar shared venues to hijack users\u2019 Microsoft 365 accounts, according to the ReliaQuest Threat Research team.<\/p>\n

Once a threat actor controls a gateway, they can silently redirect a user\u2019s traffic to their own infrastructure and steal their Microsoft 365 credentials without ever touching the user\u2019s device, compromising endpoints, or sending phishing links or malicious attachments.<\/p>\n

\u201cThe most dangerous element is that it operates at the network gateway, which sits beneath most of the trust assumptions users and devices make,\u201d ReliaQuest told CSO Online. \u201cIt\u2019s not necessarily an enterprise breach level event on its own, but it\u2019s a very real risk to individual accounts.\u201d<\/p>\n

Exploiting a \u2018fundamental trust\u2019<\/h2>\n

Domain Name System (DNS) poisoning, in which false data is injected to redirect regular web traffic to fraudulent domains, has previously been observed on small office routers, but attackers are now expanding the technique to higher-level targets, the ReliaQuest researchers explained in a blog post<\/a>.<\/p>\n

Attackers likely gain access to the gateways through weak or reused admin credentials in combination with exposed interfaces like Secure Shell (SSH), Simple Network Management Protocol (SNMP), and other web consoles, they pointed out.<\/p>\n

Admin access to the gateway is all that malicious actors need, because devices are designed to inherently trust DNS, which translates domain names like login.microsoftonline[.]com into IP addresses to route them. Therefore, a single gateway compromise gives the attacker the ability to redirect traffic for every guest logging into the network, providing IP addresses it controls in response to DNS requests, rather than the legitimate ones, without touching a single endpoint.<\/p>\n

\u201cCaptive portal appliances sit at the network perimeter<\/a> for every guest on that network,\u201d the researchers wrote. \u201cDetection is inherently difficult because the attack happens gateway-side, outside the endpoint\u2019s visibility.\u201d<\/p>\n

In the campaign tracked by ReliaQuest, four attacker-registered domains, m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com, were used for Microsoft-impersonation lures.<\/p>\n

The compromised Wi-Fi gateways were discovered across multiple US cities as well as in India and Saudi Arabia, and impacted users were from companies in professional and financial services, legal, retail, health care, and energy, indicating that the method isn\u2019t sector-specific.<\/p>\n

\u201cWe\u2019ve seen enough SharePoint exfiltration cases to know that a single popped account can cascade into meaningful data loss,\u201d ReliaQuest noted. Meanwhile, for the network operators, there\u2019s a \u201creputational dimension\u201d; user compromise is a \u201cserious trust and brand problem, regardless of how sophisticated\u2019 the underlying attack is.\u201d<\/p>\n

Safe services, DNSSEC not enough<\/h2>\n

Locking network configurations to a \u2018safe\u2019 DNS provider such as Google (8.8.8.8), Cloudflare (1.1.1.1), or the cloud-based OpenDNS isn\u2019t a sufficient tactic, because it doesn\u2019t change the path that queries actually travel over, ReliaQuest contended.<\/p>\n

By default, devices send DNS queries as unencrypted protocol traffic, and those packets still have to traverse the hotel\u2019s network to reach Google, Cloudflare, or OpenDNS, the company explained. Since the gateway sits directly in that path, it can inspect, block, or redirect the query before it ever reaches the chosen resolver.<\/p>\n

\u201cSpecifying a trusted DNS server changes the intended destination, not who controls the road to get there,\u201d ReliaQuest noted.<\/p>\n

Further, Domain Name System Security Extensions (DNSSECs), which use digital signatures and public-key cryptography, only \u201cpartially\u201d address the problem. DNSSEC provides authentication and integrity for signed domains, which means a validating resolver can detect and reject forged or tampered responses.<\/p>\n

\u201cWhat it does not do is provide confidentiality or availability,\u201d the company said. \u201cIt does not encrypt DNS traffic or stop an attacker from intercepting, blocking, or redirecting requests.\u201d<\/p>\n

So while DNSSEC can defeat certain response-forgery attacks against signed zones, an on-path gateway can still see queries, drop them, or force fallback behavior. However, this protection layer only helps when domains are actually signed, and then only when the client or resolver performs validation, which \u201cmany stub resolvers do not,\u201d according to ReliaQuest.<\/p>\n

Full-tunnel VPNs required<\/h2>\n

To combat the problem, enterprises should require all corporate devices to use a full-tunnel VPN for network connection. Controls should prevent internet access until a tunnel is active, ReliaQuest advised.<\/p>\n

This will route all of a device\u2019s traffic, including DNS, through an encrypted connection to a trusted VPN server before it travels anywhere else, the company explained, thus preventing local networks like hotel gateways from seeing or modifying DNS and internet traffic.<\/p>\n

\u201cIn effect, it takes the untrusted network out of the trust equation,\u201d ReliaQuest noted.<\/p>\n

However, full-tunnel configuration is not the default for VPNs, because it comes with \u201creal trade-offs,\u201d the researchers noted: It adds cost, latency, and bandwidth demands, since every packet has to travel through company infrastructure. Thus, forcing all traffic through the corporate backbone is \u201cnot always practical\u201d for distributed or bandwidth-heavy workforces.<\/p>\n

Enterprises should also enforce conditional access in Entra ID to block device-code authentication flow<\/a>, which has few legitimate use cases for most users in most environments, ReliaQuest noted.<\/p>\n

Additional precautions<\/h2>\n

The company also advised:<\/p>\n