The network changed where login traffic went
ReliaQuest documented a campaign in July that targeted Wi-Fi gateways at hotels and conference centres. After gaining control of a gateway, attackers changed its DNS settings so people trying to reach Microsoft sign-in pages could be redirected to a fake page.
Use a full-tunnel work VPN or a trusted mobile hotspot.
Continue after a certificate warning or unexpected device-code prompt.
Tell IT the network, location, time, and sign-in screen you saw.
Why the page could still look convincing
Some victims were shown a device-code flow. Approving it could authorise a session started by the attacker, which meant ordinary multi-factor authentication did not necessarily stop the takeover. The login request looked connected to the user's own action on the hotel network.
What to do now
Use an always-on full-tunnel VPN on work devices and avoid signing in after a certificate warning or unexpected device-code prompt. Type the known Microsoft address yourself, use a mobile hotspot for sensitive work, and contact IT when the sign-in flow changes unexpectedly.
Leave the suspicious Wi-Fi and use a trusted connection.
End active sessions and remove unknown sign-in methods or apps.
Change the password and confirm MFA settings.
Check sign-in logs, mailbox rules, OneDrive, and SharePoint activity.
Good practice and mistakes to avoid
- Work devices use an approved full-tunnel VPN when travelling.
- Device-code authentication is disabled when the organisation does not need it.
- Unexpected certificate warnings are never ignored.
- Staff know how to report a suspicious sign-in quickly.
After a suspicious sign-in, disconnect from the network, report it, revoke active sessions, review new sign-in methods and applications, and change the password from a trusted connection. A password change alone may not remove a token or application permission already granted.