A traveling employee checks into a hotel, connects to the guest Wi-Fi, and opens their laptop to catch up on email. Microsoft 365 asks them to sign in again, nothing unusual about that. They enter their credentials. Except the login page was never Microsoft's, and the network they trusted quietly sent them somewhere else. No phishing email arrived. No malicious attachment was opened. Their device was never touched. The compromise happened entirely in the space between their laptop and the internet, at the hotel's Wi-Fi gateway.
In July 2026, the ReliaQuest Threat Research team documented exactly this campaign: attackers compromising public Wi-Fi gateways at hotels and conference centers to poison DNS and harvest Microsoft 365 credentials from traveling corporate employees. It is a clear illustration of a principle worth understanding, that whoever controls DNS controls where your traffic goes, and it is worth walking through how the attack works and why several common defenses do not stop it.
This analysis is based on the original research published by ReliaQuest. The campaign details, attribution, and indicators are drawn from their report.
The Attack in Brief
According to ReliaQuest, adversaries have been compromising the captive-portal appliances that run guest Wi-Fi at hotels and similar venues, and using that control to redirect users to attacker infrastructure. The activity has been ongoing since at least June 2026, with compromised gateways identified across multiple US cities and internationally in India and Saudi Arabia.
ReliaQuest assesses the tradecraft as similar to APT28 (also known as Fancy Bear or Forest Blizzard), a Russian military intelligence group previously linked to a comparable router-based campaign. They are careful to note this is a similarity in tactics rather than a direct attribution, the assessment rests on overlapping techniques rather than shared infrastructure or code.
Notably, the targeting was not sector-specific. ReliaQuest observed traffic to the compromised gateways from organizations across financial services, professional services, legal, healthcare, energy, and retail, consistent with a campaign that goes after traveling employees wherever they connect, rather than any single industry.
How the Attack Works
Step 1: Compromise the Gateway
The attack begins with the attacker gaining administrative access to an internet-facing Wi-Fi gateway. ReliaQuest assesses with low-to-medium confidence that initial access came through exposed management interfaces, internet-facing SSH, SNMP, or web administration consoles, combined with weak or reused administrative credentials.
The significance of this device class is the environment it controls. A captive-portal appliance sits at the network perimeter for every guest on that network. Compromising one does not compromise one victim; it positions the attacker to redirect traffic for everyone who connects that day, without touching a single endpoint.
Step 2: Poison DNS for Every Client
Once in control of the gateway, the attacker controls DNS resolution for every device that joins the network. This works because of a trust assumption built into how networks function: when your device joins a network, it accepts that network's DNS resolver and trusts the answers it returns. DNS translates a name like the Microsoft login domain into an IP address, and whoever answers those queries decides where you actually go.
Because the compromised gateway is the resolver handed to every connecting client, queries for legitimate domains can be silently answered with attacker-controlled IP addresses. In the cases ReliaQuest investigated, forged responses redirected users to Microsoft-impersonating pages. This is DNS poisoning at the gateway level, and it is conceptually related to the broader class of attacks we cover in our explainer on DNS cache poisoning.
Step 3: Harvest Credentials and Tokens
The attackers registered four lookalike domains impersonating Microsoft: m365-owa, owa-ms365, ms365-device, and ms365-live (each a .com). ReliaQuest assesses with high confidence these were operated by a single actor, based on shared registration details and their appearance together within single browsing sessions.
ReliaQuest also observed the redirect paired with abuse of Microsoft's device-code authentication flow, a path to account compromise that does not require intercepting a password at all. In that flow, approving what looks like a routine sign-in prompt can authorize a session the attacker initiated, causing Microsoft to issue valid, MFA-satisfied OAuth tokens to the attacker. The lesson is sobering: multi-factor authentication does not help if the user is tricked into authorizing the attacker's own session.
Why Common DNS Protections Do Not Stop This
The most counterintuitive part of ReliaQuest's findings is that several defenses people assume would protect them do not. This is worth understanding, because it corrects a widespread misconception.
Hard-coding a public resolver does not help. Setting your device to use a public DNS server such as Google's does not protect you here. The request still leaves your device as unencrypted traffic that the gateway can read, forge, and redirect before it ever reaches that resolver.
Opportunistic encrypted DNS does not help. Many DNS-encryption tools default to opportunistic mode, which allows plaintext fallback when encrypted resolution fails. A malicious gateway can force that fallback and then redirect the plaintext request. Only strict-mode encrypted DNS, where plaintext fallback is disabled, closes the gap.
ReliaQuest identifies two configurations that do stop the attack: an always-on, full-tunnel VPN that routes all DNS through the corporate network before the gateway can touch it, and strict-mode encrypted DNS (DNS over HTTPS or DNS over TLS with fallback disabled). The distinction between opportunistic and strict mode is exactly the kind of detail that matters, and we cover these protocols in our guide to DoH versus DoT.
Defending Against Gateway DNS Poisoning
ReliaQuest's recommendations center on preventing poisoned DNS from reaching endpoints in the first place. In summary:
- Enforce always-on, full-tunnel VPN on corporate devices, so all DNS routes through trusted corporate resolvers before reaching any public gateway. Eliminate split-tunneling exceptions that would let DNS bypass the tunnel.
- Use strict-mode encrypted DNS where a VPN is not in play, ensuring a gateway cannot forge responses through plaintext fallback.
- Disable Web Proxy Auto-Discovery (WPAD) where it is not required, since ReliaQuest observed WPAD abuse as a secondary redirection channel in roughly a third of cases.
- Block the device-code authentication flow at the identity provider for users who do not need it, removing the token-theft path the campaign depended on.
- Train employees to verify the URL and certificate of any page requesting credentials, especially on hotel, airport, and conference Wi-Fi.
The through-line is that this is primarily an endpoint and network-configuration problem for the traveling user, solved with VPN, strict encrypted DNS, and identity-provider hardening. For the full technical detail, indicators of compromise, and detection guidance, read ReliaQuest's original report.
The Broader Lesson: DNS Trust Is Assumed Everywhere
What makes this campaign instructive is not any single technique but the assumption it exploits. Every device that joins a network trusts that network to resolve DNS honestly. That trust is almost never verified, which is precisely why controlling DNS is such a powerful position for an attacker, whether at a hotel gateway, a home router, or anywhere else in the resolution path.
The same principle applies on the other side of DNS, to the domains an organization owns. Just as a traveling user cannot assume a network resolves DNS honestly, an organization cannot assume its own DNS records, delegations, and configurations remain correct and untampered without checking. That is the idea behind applying Zero Trust principles to DNS: never assume, always verify.
It is worth being clear about scope. This particular attack happens on the client-resolution side, at a network the victim does not control, and the defenses are endpoint and network controls rather than domain monitoring. DNS Assistant operates on a different part of the DNS picture, continuously verifying the security posture of the domains you own, so their records, email authentication, and configuration stay correct and any change is surfaced quickly. Different layer, same underlying lesson: DNS is too important to leave on unverified trust.
Assess Your Own DNS Posture
While the defenses against gateway poisoning are endpoint-side, keeping your own domains verified is its own discipline. Inspect a domain's records, DNSSEC status, email authentication, and TLS posture with the free DNS lookup tool or a Free Domain Risk Report.
For continuous monitoring of the domains you own, start free at dnsassistant.com.
This analysis is based on original research published by the ReliaQuest Threat Research team in July 2026. The campaign details, attribution assessments, indicators of compromise, and defensive recommendations are drawn from their published report, linked above. This article summarizes and contextualizes that research for educational purposes. If you may be affected, consult ReliaQuest's original report for the full indicators of compromise and detection guidance.
Top comments (0)