CaptiveCrunch turned hotel Wi-Fi into CornFlake malware and token theft

Microsoft has described CaptiveCrunch, a campaign that turned routine hotel Wi-Fi access into a multi-stage attack. DNS and HTTP manipulation redirected victims to fake updates or device-code sign-in. Later stages installed the CornFlake backdoor and modules that stole browser data, Microsoft 365 sessions and cloud tokens.

The central lesson is not “never use hotel internet.” The attack exploits a moment when users expect captive-portal redirection, network warnings and an additional sign-in step. Unusual browser behaviour appears credible in that context.

What Microsoft found

In its analysis published on 31 July, Microsoft attributes the activity to Storm-2945, a subset of Midnight Blizzard. The company associates the broader Midnight Blizzard operation with Russia’s Foreign Intelligence Service; other researchers use names including APT29 and Cozy Bear.

The campaign has operated since at least early May 2026 and affected hospitality captive-portal systems worldwide. Microsoft observed two primary variants:

• fake browser or operating-system updates that delivered malware;
• device-code phishing targeting Microsoft accounts.

From 16 July, operators increasingly used the device-code path. This illustrates attacker adaptation: where organisations block payloads or improve endpoint detection, the operation can shift toward a legitimate identity workflow.

Why a captive portal is effective camouflage

Hotel and conference networks commonly intercept the first HTTP request to display acceptable-use terms, a room-number prompt or sign-in form. Users see a domain different from the one requested, a certificate-related transition or an operating-system message saying the network requires authentication. Under normal conditions, that is part of how the network works.

CaptiveCrunch exploited that tolerance. DNS and HTTP manipulation could direct a traveller to attacker-controlled content. A fake update fit the setting: “this network requires a newer browser” feels less suspicious when internet access has just failed.

A VPN does not always solve the initial stage because the tunnel may not be established until after the captive portal is accepted. Security policy therefore has to cover the period before the VPN starts.

The malware chain: CornFlake and ChocoShell

Microsoft describes CornFlake as a Go-based backdoor. It copied itself to %APPDATA%\svchost32\svchost32.exe and created a service named “Cloud Sync Service.” The path and name imitate legitimate software, but svchost32.exe inside a user profile differs from the operating system’s svchost.exe.

Operators used multiple persistence methods and a watchdog process that restarted components. CornFlake could receive further commands and modules, including functions related to browser data.

Another component, ChocoShell, ran as an in-memory PowerShell payload. Microsoft describes capabilities to steal:

• stored browser credentials and cookies;
• Microsoft 365 session data;
• Azure tokens;
• Web Account Manager tokens.

Cookie and token theft changes response priorities. A password reset may not invalidate every active session. The organisation needs to revoke sessions and tokens, inspect application registrations and review cloud activity.

Device-code phishing without a fake password page

In a legitimate device flow, a device displays a short code and the user enters it on an identity-provider page. An attacker can initiate sign-in from their own session and send that code to the victim. The victim opens Microsoft’s genuine site, authenticates and approves the process, but the token is delivered to the attacker-controlled session.

The sign-in domain and certificate can therefore be correct. Context is the signal: why is a hotel, document or caller asking for a device code? Users should approve a code only when they personally initiated sign-in on a known device and understand which application will receive access.

Guidance for travellers

A personal cellular hotspot is the safer choice for sensitive work. Where hotel Wi-Fi is necessary:

• update the operating system and browser on a trusted network before travelling;
• never install an “update required by Wi-Fi”;
• use the captive portal only to obtain connectivity, not to sign in to corporate accounts;
• start a full-tunnel VPN immediately after clearing the portal;
• never bypass TLS warnings;
• do not enter a device code for a sign-in you did not initiate;
• disconnect and switch to a hotspot when anything looks suspicious;
• report the event before attempting to clean the device.

Employees should not have to choose between a business deadline and safe connectivity. Organisations need to provide roaming, hotspots or another practical alternative.

Identity controls

If the organisation does not need device-code flow, block it. Where a defined device population requires it, restrict the flow with Conditional Access, a limited user group and device-compliance context.

Also:

• require managed devices for sensitive data;
• use phishing-resistant authentication such as passkeys or FIDO2 keys;
• alert on device-code sign-ins from new locations;
• correlate token issuance with user and device activity;
• shorten privileged-session lifetime;
• give the SOC a rapid process for revoking tokens and sessions.

MFA remains valuable, but an approval prompt cannot protect a user who knowingly authorises the attacker’s flow. Domain- and device-bound methods and contextual policy are needed.

Endpoint and network detection

On Windows, inspect creation and execution under %APPDATA%\svchost32\, the “Cloud Sync Service,” unusual PowerShell child processes and watchdog-style persistence. Correlate these events with later access to cookies, token stores and browser profiles.

In DNS and proxy data, look for unexpected responses while joining a captive network, redirection to fake updates and traffic from a process imitating a system binary. If a laptop was used in a hotel during the campaign window, correlate endpoint evidence with Entra ID and Microsoft 365 logs.

Response procedure

1. Disconnect the device from the untrusted network, but do not immediately delete artifacts.
2. Contact the SOC from a separate trusted device.
3. Revoke the user’s sessions and tokens; a password reset alone is insufficient.
4. Preserve endpoint, Entra ID, Microsoft 365, DNS and VPN logs.
5. Inspect mailbox rules, application consent, new devices and cloud activity.
6. Rebuild from a trusted image where malware is confirmed or scope is uncertain.
7. Expand the hunt to other travellers who used the same properties.

Primary facts versus Breachroad analysis

Microsoft confirms the observed redirection chain, CornFlake, ChocoShell, the shift toward device-code phishing and technical indicators. Attribution to Storm-2945 and its relationship with Midnight Blizzard are Microsoft’s assessment, not mathematical proof of operator identity.

Breachroad’s organisational conclusion is that secure travel policy must cover connectivity, identity and endpoint as one process. A VPN alone is insufficient if the user must first cross an untrusted page; EDR alone is insufficient when an attacker steals a valid token without installing a file.

Cybersecurity training and phishing simulations can prepare staff for fake updates and device-code requests in a travel context. An IT security audit can assess Entra policy, token revocation, VPN, EDR and SOC readiness.