We spend years telling users to be suspicious of certificate warnings, and then hand them a corporate laptop that has to click through a captive portal in a hotel lobby before it can reach anything at all. That contradiction has been sitting in plain sight for two decades. Microsoft's write-up of CaptiveCrunch is the bill arriving.
The short version, from Microsoft's Threat Intelligence team: Storm-2945, an operational sub-cluster of Midnight Blizzard, has since early May 2026 been manipulating DNS and HTTP traffic on captive portal networks, mainly at hotels, conference centres and similar shared venues, to push fake update prompts and ClickFix-style lures at travellers. The payloads Microsoft names are CornFlake, a Go-based Windows remote access trojan, and ChocoShell, a PowerShell infostealer that takes browser cookies, saved passwords and Microsoft 365 SSO tokens. Microsoft has not yet determined the initial compromise vector, but notes common equipment and management systems across the affected networks, which points to shared services in the captive portal ecosystem rather than isolated venue breaches. Its post was updated on 5 October after activity resumed on 29 September.
Why the captive portal is such a good place to stand
Think about what a captive portal does to a managed device. It intercepts traffic. It presents a page the user is trained to accept without scrutiny. It frequently breaks TLS validation, or at minimum produces a warning that the operating system itself teaches the user to dismiss — Windows will happily open its own browser surface to complete the sign-in. It runs before your VPN comes up, before Conditional Access has anything to evaluate, often before endpoint protection has finished its cloud lookups on a cold network.
That is a genuinely privileged position, and it costs an attacker nothing in terms of novel tradecraft. No zero-day, no signed driver, no clever loader. Compromise a hotel chain's portal infrastructure — which is typically outsourced to a hospitality Wi-Fi provider, patched on someone else's schedule, and monitored by nobody your CISO has ever met — and you get a captive audience of business travellers. Travellers who are, by definition, the people going to conferences, negotiations, government meetings and site visits. Midnight Blizzard does not go after volume. It goes after proximity to interesting people.
This is the same shift as ClickFix
State actors picking up ClickFix showed the same thing, and the point stands here: the interesting variable is no longer technique sophistication, it is targeting sophistication. CaptiveCrunch is supply chain thinking applied to physical travel. The hotel is not the target. The hotel is the delivery mechanism, chosen because it sits upstream of a population that is otherwise well defended.
If your threat model assumes that nation-state activity looks exotic on the wire, you will keep missing this class of operation. It looks like a user visiting a login page on a hotel network. It looks, in your logs, like nothing.
What actually reduces exposure
Most of the mitigations here are things we already know how to do and have deprioritised because travel felt like an edge case. It is not an edge case; it is a recurring monthly event for your senior people.
- Phishing-resistant authentication, properly enforced. If the credential harvest yields a password and a push-approved MFA prompt, you have lost. FIDO2 keys or Windows Hello for Business with Conditional Access requiring the authentication strength — not just "MFA" as a boolean — turns credential theft into a non-event. Microsoft also recommends blocking device code flow where possible, since this actor has used device code and OAuth phishing since February. This is the single highest-leverage control and in too many organisations it still applies to admins only.
- Device compliance as a gate, not a report. Conditional Access policies keyed to Intune compliance state mean a compromised traveller device stops being useful the moment it drifts out of policy. Combine with token protection where you can.
- Get off the hotel network entirely. A corporate eSIM or mobile hotspot costs less per trip than one incident triage hour. Make it the default build for anyone who travels, and treat hotel Wi-Fi as a fallback you log.
- Always-on tunnelling with a hardened captive portal path. If the device must use hotel Wi-Fi, the portal interaction should happen in a constrained context and the tunnel should establish before anything else touches the internet. Test this. Most "always-on" configurations have a gap during portal negotiation, and that gap is precisely where CaptiveCrunch lives.
- Loaner devices for high-risk itineraries. Unglamorous, effective, and standard practice in sectors that learned this lesson early.
The travel briefing needs rewriting
Our user guidance on this has been bad for years. "Don't use public Wi-Fi" is unactionable when the client site's guest network is the only option. "Look for the padlock" is useless when the portal deliberately breaks TLS. What travellers actually need is narrower and more useful: never install anything a network asks you to install, never run a command a web page gives you, and if the portal asks for corporate credentials, stop and call the service desk — because a hotel has no legitimate reason to want your Entra ID password.
That last one is worth saying out loud in the briefing. The confusion between "sign in to the Wi-Fi" and "sign in to work" is entirely reasonable from a user's perspective, and it is the confusion this operation monetises.
The detection angle is thin, and that is the point
You will get limited value from hunting portal traffic. What you can do is instrument the aftermath: unusual sign-ins from foreign IP space that correlate with travel calendars, token replay indicators, new device registrations in Entra ID during trips, and endpoint process trees showing browser-spawned script hosts. Correlating identity telemetry with actual travel bookings is an integration few organisations bother with, and it turns a noisy signal into a sharp one. If HR or the travel booking system knows the CFO is in Vienna this week, your SIEM should too.
The uncomfortable structural problem
None of this addresses the root issue, which is that hospitality Wi-Fi is a globally distributed, thinly governed piece of infrastructure that millions of corporate endpoints touch every day, and no enterprise has any leverage over it whatsoever. We cannot audit it. We cannot patch it. We can only assume it is hostile.
So assume it. Design the travel build as though every network it joins is actively adversarial, because for a subset of your staff it demonstrably is. That is not paranoia — it is the cheapest architecture available, and it removes an entire attack surface rather than trying to detect activity on it.