The Hotel Wifi Your Sales Team Logs Into Just Became a Way Into Your Microsoft 365 Account
· by IDE Solutions
The standard advice for hotel wifi has always been the same: turn on a VPN, avoid entering passwords, and treat the network as untrusted. That advice assumes the danger is someone on the same network reading your traffic. It was never built for what Microsoft confirmed on July 31, 2026: a Russian state-linked group had compromised the actual sign-in equipment at hotels and conference venues, and was using that position to log guests straight into a fake Microsoft page before they ever reached their inbox.
Microsoft calls the campaign CaptiveCrunch and attributes it to Storm-2945, a sub-group of Midnight Blizzard, the same Russian intelligence-linked actor better known as APT29 or Cozy Bear. The business risk is not abstract. Any employee who checks email from a hotel room, an airport lounge, or a conference centre this quarter is a potential entry point into your Microsoft 365 tenant, and a VPN by itself does not close it.
What actually happened
Hotel and conference wifi almost always runs through a "captive portal", the page that asks for a room number or forces you to click "I agree" before the internet works. According to Microsoft, the attackers running CaptiveCrunch got control of that captive portal equipment itself, not individual guest devices, at properties used by travellers worldwide since at least May 2026. From that position, they could show any guest whatever page they wanted before the guest's real connection ever started.
Two things happened next, and both bypass the advice most companies have already given staff. Some guests were redirected to a page that looks exactly like the real Microsoft sign-in screen and typed their password straight into it. Others were shown a fake browser or Windows update notice, a technique security researchers call ClickFix, and clicking it installed a piece of malware Microsoft named CornFlake. CornFlake logs keystrokes, takes screenshots, can turn on the webcam, and, critically, pulls the active Microsoft 365 session token directly out of the browser.
Why "we already use a VPN" does not cover this
A VPN protects data once your device has a working internet connection. The captive portal step happens before that, at the moment your laptop first joins the hotel network and needs to authenticate to get online at all. If the portal itself is compromised, the VPN never gets the chance to help, because the fake login page or the fake update prompt appears during the step the VPN was never involved in.
The session token theft matters even more than the password theft. A password can be reset the moment you suspect it leaked. A stolen session token is already-authenticated proof that a login happened and passed multi-factor authentication, so the attacker can often open your mailbox or SharePoint files without entering a password or a code at all, for as long as that token stays valid. Microsoft's own token theft playbook walks through exactly this mechanism, and it is the reason "we have MFA turned on" is not the same answer here that it is against an ordinary password-guessing attempt.
Keep this in proportion
It is worth saying plainly: this style of attack is still rare next to the ordinary threats that actually fill most incident reports. Microsoft's own 2025 Digital Defense Report found that token theft, adversary-in-the-middle phishing, and other technically sophisticated identity attacks together made up under 3% of identity compromise attempts, with more than 97% still simple password spraying or brute force.
The reason CaptiveCrunch is still worth acting on is who it targets, not how common it is. State-linked groups run this kind of operation against travellers likely to be worth the effort, which in practice means anyone in sales, procurement, executive roles, or partnerships whose inbox and calendar carry real business value. A 15-person company with staff visiting clients or conferences is exactly inside that target profile, whether or not the owner thinks of the business as a target for a nation-state actor.
What actually stops this, ranked by what it takes to set up
| Control | What it stops | Effort to set up |
|---|---|---|
| Personal mobile hotspot instead of hotel wifi | The captive portal entirely; the attacker never sees the connection | None, a travel policy decision |
| Phishing-resistant MFA (a physical security key or Windows Hello passkey) | The fake-login-page half of the attack; a spoofed page cannot complete the check | Low, per user, one-time enrolment |
| Conditional access tied to a managed, compliant device | Sign-in from an unmanaged or newly risky device, even with a valid password | Medium, needs a tenant security review to configure correctly |
| Continuous access evaluation and token lifetime limits | A stolen session token staying valid for hours or days after theft | Medium, an admin-side policy change, not user-facing |
| Staff trained to distrust unexpected update prompts on any network | The ClickFix malware install specifically | Low, a five-minute briefing before travel |
None of these require replacing your existing setup. Most small businesses already own the licensing that includes conditional access and continuous access evaluation; what is usually missing is someone who has gone in and turned the settings on. That gap is what a cloud security review is built to close.
The decision most companies have not made yet
Ask a 10 to 30 person business what its policy is for staff connecting to hotel or conference wifi, and the honest answer in most cases is that there is not one. Nobody decided against a policy; it simply never came up until a headline like this one forces the question. That is the actual gap CaptiveCrunch exposes: not a missing piece of software, but a decision nobody has made.
The decision does not need to be complicated. A short written rule, mobile hotspot preferred over hotel or venue wifi for anyone travelling for work, phishing-resistant MFA required on any account with access to financial systems or client data, and a standing instruction to never accept an unexpected update prompt on any network, covers the great majority of the exposure this campaign creates. Writing it down and telling staff once before their next trip is most of the work.
If someone already travelled and connected before reading this
There is a practical difference between a device that merely joined a hotel network and one that actually hit a compromised captive portal, and most staff will not know which happened to them. Rather than guessing, treat any recent business trip as worth a five-minute check, not a full incident response.
Start with the sign-in log for that person's account, available to an admin under Microsoft 365 sign-in activity or Entra ID, and look for a location or device that does not match the trip, a login from a country nobody visited, or a device name nobody recognises. Next, revoke that user's active sessions from the admin centre; this forces every open session, including a stolen token, to re-authenticate, and a genuine token theft stops working the moment it happens. Finally, have the user change their password even if nothing looks wrong in the log, since a captured password with no obvious follow-up use yet is still worth invalidating.
None of this requires specialist tooling, and it takes less time than the trip itself did to book. The businesses that get hurt by campaigns like this one are rarely the ones that check and find nothing; they are the ones where nobody thought to look until a client called asking why an unfamiliar invoice arrived from what looked like the right email address.
Quick answers
Does this mean hotel wifi is unsafe to use at all?
No. Most hotel networks are not compromised, and CaptiveCrunch targets specific properties the attackers chose to invest effort in. The sensible response is not avoiding hotel wifi altogether, it is not trusting any captive portal to be the source of a genuine Microsoft or Windows update, and preferring a mobile hotspot for anything sensitive when one is available.
If MFA is already turned on, are we still exposed?
Partially. Ordinary MFA, a code from an app or a text message, stops most password-guessing attacks but does not stop session token theft, since the token is copied after a legitimate login already succeeded. Phishing-resistant MFA (a physical key or a device passkey) closes that specific gap; app-code MFA alone does not.
Before your next employee travels
- Confirm whether conditional access and continuous access evaluation are actually turned on in your tenant, not just licensed.
- Move anyone with financial or client-data access onto a physical security key or passkey rather than a code-based MFA app.
- Issue mobile hotspots, or confirm phone data plans cover it, for staff attending conferences or client visits this quarter.
- Tell staff once, in writing, to never install an update prompted by a wifi login page, on any network, ever.
- Ask your managed IT provider to show you your current token lifetime and conditional access settings, rather than assume they are configured.
We check whether your tenant would actually stop this
Our Microsoft 365 security assessment tests your conditional access, MFA, and token policies against exactly this kind of attack, not a generic checklist, and tells you in plain terms what would happen if an employee's laptop connected through a compromised network tomorrow.
Where gaps exist, we close them: phishing-resistant MFA rollout, conditional access tuning, and ongoing monitoring so a stolen token gets caught, not missed.