Security researchers at ReliaQuest have uncovered an active campaign, running since at least June 2026, in which threat actors hijack the DNS settings of Wi-Fi gateways at hotels and conference centers to redirect guests toward fake Microsoft 365 login pages. Compromised Wi-Fi gateways have been identified in multiple U.S. cities as well as other regions, including India and Saudi Arabia. Because these gateways serve corporate travelers and event attendees, hijacking Microsoft 365 accounts could give attackers access to sensitive business information, communications, and private documents across a wide range of industries.
Hotel Wi-Fi DNS Hijacking: Why Changing Your DNS Server Isn't Enough
Hotel Wi-Fi has always carried a certain amount of risk. You're connecting a laptop or phone to a network that you don't control, using infrastructure that you know very little about.
But a recently reported campaign takes that risk to another level.
Security researchers at ReliaQuest discovered attackers compromising Wi-Fi gateways at hotels, conference centers and other shared venues and modifying their DNS configuration. The attackers then redirected travelers toward fake Microsoft 365 login pages designed to steal corporate credentials or obtain legitimate authentication tokens. The activity has been observed since at least June 2026.
What makes this campaign particularly interesting from a networking perspective is that the victim doesn't necessarily have to make a traditional security mistake.
There doesn't have to be a phishing email.
There doesn't have to be a malicious attachment.
The user can simply connect to the hotel Wi-Fi and attempt to access a legitimate work service.
That's what makes this attack worth understanding.
The Attack Starts With the Network
The basic concept is surprisingly simple.
When a device connects to a hotel network, it normally receives network configuration through DHCP. That configuration typically includes an IP address, default gateway and DNS server information.
The DNS server translates names such as Microsoft's login services into IP addresses.
If an attacker gains administrative control of the hotel's Wi-Fi gateway, however, the attacker can potentially manipulate that process.
Instead of allowing a DNS request to resolve normally, the compromised gateway can return an attacker-controlled destination.
The user's browser may then display something that looks like a legitimate Microsoft login page.
From the user's perspective, everything can appear normal.
The Wi-Fi works.
The browser works.
The Microsoft branding looks familiar.
And there may not be anything obviously suspicious about the connection itself.
Why This Attack Is More Interesting Than Normal Phishing
Traditional phishing depends on getting the victim to click something.
This campaign changes the equation.
The attacker is manipulating the network that the victim is already using.
That's an important distinction.
Security awareness training often teaches users to examine links in emails and messages before clicking them.
That's good advice, but it doesn't solve a compromised network infrastructure problem.
If DNS resolution is being manipulated upstream, a user can manually type a legitimate-looking address and still potentially be redirected.
This is a good example of why security has to operate at multiple layers.
Protecting the user isn't enough if the network path underneath the user has been compromised.
Why Google DNS Doesn't Automatically Save You
Here's one of the most interesting networking details in this campaign.
You might think that changing your DNS server to a well-known public resolver such as Google's 8.8.8.8 would solve the problem.
It doesn't necessarily.
ReliaQuest explains that the compromised gateway can intercept and manipulate plain-text DNS traffic before it reaches the intended resolver.
This is an important distinction.
There is a difference between choosing a trustworthy DNS resolver and protecting DNS traffic between your device and that resolver.
If the DNS query travels across the local network in a form that the compromised gateway can intercept, the gateway may still be able to interfere with the request.
That's why encrypted DNS and, more importantly, a properly configured full-tunnel VPN can make such a significant difference.
The VPN Changes the Security Boundary
A full-tunnel VPN changes the path that traffic takes.
Instead of allowing the hotel network to handle your device's Internet traffic directly, the device establishes an encrypted tunnel back to a trusted VPN endpoint.
Traffic — including DNS requests — travels through that tunnel.
The hotel network still provides the underlying Internet connection, but it has much less visibility into what you're actually doing inside the encrypted tunnel.
ReliaQuest specifically recommends always-on, full-tunnel VPN for corporate devices as a primary defense against this type of attack.
This is an important lesson for IT departments.
Don't tell traveling employees simply to "use a VPN."
Make sure the corporate VPN is configured correctly.
A split-tunnel configuration may leave some traffic, including potentially sensitive DNS requests, outside the protected tunnel.
For high-risk users, always-on full-tunnel VPN is a much stronger security model.
MFA Doesn't Always Mean You're Safe
The campaign also demonstrates another uncomfortable reality.
Multi-factor authentication is extremely valuable, but it isn't a magic shield.
Researchers observed abuse of Microsoft's device-code authentication flow in some cases.
The victim can be presented with what appears to be a Microsoft authentication request. If the user approves it without understanding what they're actually authorizing, the attacker may obtain a legitimate OAuth token.
That means the attacker doesn't necessarily need to steal the user's password.
The authentication process itself can be abused.
This is an important lesson for security teams:
MFA protects an authentication process. It doesn't guarantee that users understand what they are approving.
Organizations should review which authentication methods they actually need and consider disabling device-code authentication where it isn't required. ReliaQuest specifically recommends this for organizations that don't have a legitimate business need for the feature.
WPAD Adds Another Layer of Risk
The campaign also involved attempts to abuse Windows Web Proxy Auto-Discovery, commonly known as WPAD.
WPAD allows systems to automatically discover proxy configuration.
That's convenient in managed environments, but convenience can become a security problem on an untrusted network.
ReliaQuest reported WPAD-related activity in roughly one-third of the investigated cases, although researchers could not confirm that those attempts successfully redirected traffic.
From a network administrator's perspective, this is a good reminder to ask a simple question:
Do our endpoints really need automatic proxy discovery when connected to untrusted networks?
If the answer is no, disabling WPAD can remove an unnecessary attack surface.
What Should Traveling Employees Actually Do?
The advice for employees is fairly straightforward.
When connecting to hotel or conference Wi-Fi:
1. Treat the network as untrusted.
Don't assume that because the Wi-Fi requires a room number, password or access code that the network itself is secure.
2. Use the corporate VPN.
Preferably, the organization should enforce an always-on full-tunnel configuration rather than relying on employees to remember to activate it.
3. Pay attention to unexpected login prompts.
If Microsoft suddenly asks you to authenticate when you weren't expecting it, stop and investigate.
4. Don't blindly approve authentication requests.
Especially when using device-code or other authentication workflows.
5. Keep endpoint security enabled.
A compromised network should not automatically mean a compromised laptop.
6. Avoid sensitive work until the secure connection is established.
If possible, connect to the corporate VPN before accessing corporate applications.
What Network Administrators Should Be Looking At
There is also a valuable lesson here for network and security teams.
Hotel Wi-Fi operators should treat their gateway infrastructure as a security-sensitive asset.
Management interfaces should never be unnecessarily exposed to the Internet.
Administrative credentials should be unique and protected with strong authentication.
Firmware should be kept current.
SNMP should be secured or disabled where unnecessary.
Management traffic should be isolated from guest traffic.
And changes to DNS configuration should generate alerts.
That last point is particularly important.
A gateway suddenly changing its DNS configuration should not be treated as an ordinary configuration change.
It should be something the security team can detect and investigate.
This Is Where Network Monitoring Becomes Valuable
A campaign like this also illustrates why network visibility remains important even in an increasingly cloud-based world.
A security team could potentially look for:
Unexpected DNS server changes
DNS queries going to unusual destinations
Connections to newly registered domains
Unexpected Microsoft authentication traffic
WPAD-related activity
Changes to gateway configuration
Unusual outbound connections from network infrastructure
Authentication activity inconsistent with a user's normal location
DNS logs can be particularly useful because they provide a historical record of where systems were attempting to connect.
Packet captures can provide even more detail during an investigation.
Tools such as Wireshark can help determine whether DNS requests are leaving a device normally, identify unexpected DNS responses and establish whether the network path is behaving as expected.
The Bigger Lesson: Don't Trust the Local Network
The most important takeaway from this campaign isn't that hotel Wi-Fi is dangerous.
It's that the local network should not automatically be part of your security trust model.
That applies to hotels, airports, conference centers, coffee shops and even some guest networks inside corporate buildings.
The device should establish its own security boundary.
Authentication should be protected.
Traffic should be encrypted.
DNS should be protected.
Access should be limited.
And security monitoring should continue regardless of where the device happens to be connected.
This is essentially the philosophy behind zero-trust networking.
The network connection itself doesn't establish trust.
My Take
What I find most interesting about this campaign is how many traditional security assumptions it challenges.
"Use MFA."
Good advice — but authentication approval can still be abused.
"Use a reputable DNS provider."
Good advice — but the local gateway may interfere with unencrypted DNS traffic.
"Don't click suspicious links."
Good advice — but a compromised network can redirect traffic without requiring the user to click a phishing email.
"Hotel Wi-Fi uses a password."
That doesn't tell you whether the underlying infrastructure is trustworthy.
The better approach is to assume the opposite.
Treat public Wi-Fi as hostile infrastructure and build your security controls accordingly.
For corporate laptops, that means an always-on full-tunnel VPN, encrypted DNS, endpoint protection, strong identity controls and centralized monitoring.
For network administrators, it means protecting the gateways themselves and watching for unexpected configuration changes.
The hotel Wi-Fi doesn't have to be trusted.
Your security architecture should be designed so that it doesn't need to be.
Reference links:
