Hotel Wi-Fi as a Trap: APT28 Steals Microsoft 365 Logins via DNS Poisoning

Published on 2 August 2026

An employee checks into a hotel, connects to the Wi-Fi, opens their laptop – and signs in to Microsoft 365 as usual. The login page looks exactly like it always does. And that's precisely the problem: it's a fake, and by signing in, the credentials land straight in the hands of a suspected Russian hacking group. No click on a dubious link, no infected attachment, no compromised software on the device. The attack takes place at the level of the hotel network – and affects everyone who connects to it.

Such an attack campaign has been actively running since at least June 2026. The security firm ReliaQuest published a detailed report on 23 July 2026, and Microsoft Threat Intelligence confirmed a related campaign under the name "CaptiveCrunch" on 31 July 2026. As of the time of writing this article (2 August 2026), the campaign is, according to the available sources, considered to still be active. There is no patch – because this doesn't exploit a single software vulnerability, but rather abuses a fundamental principle of trust in networks.

What happened?

Attackers – with high probability the Russian hacking group APT28 (also known as Fancy Bear, Forest Blizzard or Storm-2945) – compromise the so-called captive portal gateways in hotels, conference centres and other public Wi-Fi environments. A captive portal is that login page that appears when you connect to a guest Wi-Fi and asks you, for example, to accept the terms of use. The gateway behind it controls all data traffic of all connected guests.

Once the attackers have administrative access to such a gateway, they manipulate its DNS configuration. DNS (Domain Name System) is the "phone book of the internet": it translates names like login.microsoftonline.com into the IP address of the correct server. Because the gateway is automatically assigned to all connected devices as the DNS resolver, the attackers can falsify these translations. When a device asks for the Microsoft login page, the manipulated gateway responds with the IP address of an attacker server – and silently redirects the user to a perfectly rebuilt fake.

"A single compromised gateway allows the attacker to silently redirect users' traffic without touching their devices. Every employee who connects to this network is exposed – no phishing link, no malicious attachment, no endpoint compromise required." – ReliaQuest Threat Research Team

The technical background – explained clearly

The attackers likely gain access to the gateways via openly accessible management interfaces – such as SSH (encrypted remote access), SNMP (a network management protocol) or web admin consoles – combined with weak or reused passwords. Seemant Sehgal, CEO of BreachLock, puts it in a nutshell:

"The weak point here is that these gateways were reachable at all with credentials that could be compromised – and that the existing monitoring wasn't watching for configuration changes."

For the fake Microsoft login pages, the attackers used four domains: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com and ms365-live[.]com. They were hosted on the IP addresses 31.57.243[.]154, 104.194.159[.]150 and 38.146.28[.]75. ReliaQuest assumes with high confidence that all four domains are operated by the same actor.

Why public DNS servers don't protect you

A common misconception: that anyone who manually enters a well-known public DNS server such as 8.8.8.8 (Google) is protected. That's not true. Florian Burnel, Microsoft MVP and co-founder of IT-Connect, explains:

"Forcing a public resolver like Google's offers no protection whatsoever here: the request leaves the endpoint in plaintext, and the gateway can read, manipulate and redirect it. The same applies if your machine falls back to plain DNS while you're actually using encrypted DNS (DoT, DoH)."

Encrypted DNS (DoH/DoT) also only protects reliably in so-called strict mode – in "opportunistic" mode with a permitted plaintext fallback, the gateway can force this fallback.

Two particularly dangerous additional techniques

WPAD abuse: In about a third of the investigated cases, the attackers additionally tried to exploit WPAD (Web Proxy Auto-Discovery). Windows automatically asks for proxy settings when joining a network. The compromised gateway can respond with a malicious configuration file and thus redirect application traffic through an attacker proxy. ReliaQuest was unable to conclusively confirm whether these attacks were successful.

OAuth device code flow abuse: This is the most dangerous variant, because it bypasses two-factor authentication. The device code flow is actually a legitimate sign-in procedure for devices with limited input, such as smart TVs. The attacker starts such a sign-in process and redirects the victim to a genuine Microsoft authorization page. If the victim confirms the request, Microsoft issues the attacker valid access tokens – with MFA already fulfilled. Passwords don't even need to be captured. Denis Calderone of Suzu Labs warns:

"Device code authentication was designed for input-constrained devices like smart TVs, but it's enabled by default in Microsoft's Entra ID – and many companies have never turned it off because they don't even know it exists."

The numbers show just how sharply this type of attack is increasing: device code phishing attacks rose by 1,380% in the first four months of 2026, according to Microsoft.

Who is affected?

In principle, every employee who connects to a compromised public Wi-Fi – regardless of industry, company size or hierarchy. ReliaQuest observed victims from financial services, professional services, legal advisory, healthcare, energy and retail. Compromised gateways were identified in several US cities as well as in India and Saudi Arabia.

For German SMEs, the campaign is particularly insidious because the company itself doesn't even have to be attacked. It's enough for an employee to use hotel Wi-Fi at a trade fair, conference or on a business trip. James Edwards of Keeper Security explains the appeal of these targets:

"Hotels and conference centres are not random targets. A single compromised gateway at a major industry conference gives an attacker access to hundreds – or even thousands – of corporate devices from a wide range of organisations. The infrastructure economics are extraordinary."

How to check whether you're affected

1. Check sign-in logs in Microsoft Entra ID: In the Entra Admin Center (entra.microsoft.com) under "Monitoring > Sign-in logs", look for unusual sign-ins – especially from unknown IPs, unusual locations or with the sign-in type "Device Code Flow".
2. Check risky users: Under "Protection > Risky users", look for accounts flagged as "at risk" – particularly among recently travelled employees.
3. Check the Unified Audit Log: In the Microsoft 365 Defender portal (security.microsoft.com) under "Audit > Audit log", search for suspicious actions such as MailItemsAccessed, SearchQueryInitiated or FileDownloaded from unknown IPs.
4. Check for unknown device sign-ins: Under "Devices > All devices", look for unmanaged or unknown devices that have been connected to the tenant.
5. Check DNS settings: On Windows devices, use ipconfig /all to check the DNS server in use. If it differs from the company DNS after a hotel stay, caution is advised.
6. Check proxy settings: Use netsh winhttp show proxy to check whether unknown proxy servers are configured – an indication of a successful WPAD attack.
7. Match network IOCs: In firewall and DNS logs, search for connections to 38.146.28[.]75, 31.57.243[.]154 and 104.194.159[.]150, as well as for requests to the four named attacker domains.
8. Question employees: Anyone who has recently been in hotels or at conferences should be asked whether they noticed any unusual certificate warnings, unexpected login prompts or strange authorization requests.

What you need to do now

Since there is no patch, organisational and configuration measures are crucial. Prioritise in this order:

1. Enforce always-on full-tunnel VPN: The single most effective measure. All company devices should use a VPN that activates automatically when joining a network and only allows internet access once the tunnel is active. Split-tunneling exceptions for DNS or authentication must be removed.
2. Block the device code flow in Entra ID: Use a conditional access policy to block the device code flow for all users (path: Entra Admin Center > Protection > Conditional Access > New policy > Authentication flows). Exceptions only for accounts that demonstrably need it.
3. Disable WPAD: In environments with no need for automatic proxy discovery, turn off WPAD via group policy (service WinHttpAutoProxySvc).
4. Use phishing-resistant MFA: SMS- or TOTP-based MFA does not protect against these attacks. Use FIDO2 security keys or passkeys – especially for privileged accounts.
5. Enable DNS encryption in strict mode: Configure DoH or DoT without plaintext fallback.
6. Train employees: Treat hotel Wi-Fi as fundamentally insecure. Recommendation: use your own smartphone hotspot. Never confirm unexpected login prompts, certificate warnings or authorization requests, and report them.
7. Enable Continuous Access Evaluation and sign-in risk policy: This automatically enforces MFA or blocks access in the case of medium or high risk.
8. Remove unknown Entra devices: Check and clean up regularly – otherwise an attacker device registered via device code remains active even after a password reset.
9. For operators of public Wi-Fi networks: Update captive portal appliances to current firmware, change default credentials, do not expose management interfaces to the internet.

Context and GDPR

If this attack is used to steal credentials that enable access to personal data – such as customer data in Microsoft 365, SharePoint or Teams – then a personal data breach has occurred. This gives rise to clear obligations:

• Notification obligation under Art. 33 GDPR: Notification of the competent data protection supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Even small companies are not exempt from this.
• Notification obligation under Art. 34 GDPR: If there is likely to be a high risk to the affected individuals, they too must be informed.
• Liability risk under Art. 32 GDPR: If appropriate technical and organisational measures are lacking – such as mandatory VPN, MFA or device code blocking – the company may be liable. Fines of up to €10 million or 2% of global annual turnover are possible. For context: in Germany, a fine of €45 million was imposed on Vodafone in June 2025.

Concrete, documentable measures such as a mandatory VPN for business travellers and blocking the device code flow reduce not only the technical risk but also the liability risk.

Conclusion

This campaign is so dangerous because it works even though everything looks "right": the hotel network appears trustworthy, the login page looks genuine, the OAuth authorization is technically legitimate. James Edwards of Keeper Security sums it up aptly: the attackers have learned to weaponise trust itself – and none of these assumptions hold up when the infrastructure is compromised.

Larry Pesce of Finite State adds that what's actually new is not the method, but the proof: "The gap between 'we know this is possible' and 'we can prove it's happening' has just closed – and that should worry anyone who travels for work." For German SMEs, this means: even fully patched devices with up-to-date antivirus are unprotected if no full-tunnel VPN is active and the device code flow has not been blocked. Act now – before the next employee opens their laptop in a hotel.