How a single compromised point on a hospitality network turns "sign in to Wi‑Fi" into stolen Microsoft 365 sessions and espionage malware — step by step.
Microsoft has not named the vendor or the entry vector. The compromise sits at one of two places — and which one decides whether this hits independents or scales to big brands:
Because that device is the DHCP-assigned DNS resolver for every guest, a lookup for the real login.microsoftonline.com gets a forged reply pointing at attacker infrastructure. The domain looks legitimate; the IP behind it is swapped. To dodge a TLS certificate warning, victims land on look-alike domains the attacker holds valid certs for — ms365-live[.]com, owa-ms365[.]com.
On join, every OS fires an unauthenticated, plaintext connectivity probe (msftconnecttest.com, connectivitycheck.gstatic.com) — that's what triggers the "sign in to Wi‑Fi" window. No HTTPS, no certificate, no warning. It is the perfect place to hijack the redirect, and it looks exactly like the captive portal users already expect.
Three parallel options ride the same hijack — two steal cloud access, one drops malware:
A reverse proxy relays to the real Microsoft in real time, capturing the password and the post-login session cookie. The user logs in for real and notices nothing.
The attacker starts a device-code login and tricks the user into approving their code at the genuine microsoft.com/devicelogin. The user passes their own MFA — the token is issued to the attacker.
A bogus "browser / OS update" delivers a loader that drops the CornFlake RAT and ChocoShell stealer.
Stolen session tokens hand over corporate cloud accounts; the RAT settles in for surveillance. What the malware harvests: