Hotel Wi-Fi Is Stealing Microsoft 365 Sessions

Your chief lending officer checks into a conference hotel, joins the guest Wi-Fi, and clicks through the little sign-in page that asks for a room number. Nothing about that is unusual. It is the single most routine thing anyone does on a business trip.

On July 31, 2026, Microsoft Threat Intelligence published research on a campaign it calls CaptiveCrunch, in which a Russian state-linked actor has been compromising exactly that sign-in page at hotels, conference centers, and other shared venues. The goal is not the room number. It is the Microsoft 365 session sitting on the laptop.

For credit unions, banks, and mortgage companies, this one deserves a closer look than the average threat headline, because it breaks an assumption most institutions have quietly built their remote-access posture on: that the danger arrives as a message someone has to fall for. Here, the danger is the network itself.

What Microsoft Found on Hotel and Conference Wi-Fi

Since early May 2026, Microsoft has observed the actor manipulating DNS and HTTP traffic on hospitality networks served by captive portals, the sign-in pages that intercept your browser when you join guest Wi-Fi. Traffic gets redirected through infrastructure the attacker controls.

Microsoft attributes the campaign to a group it tracks as Storm-2945, which it assesses to be an operational sub-cluster of Midnight Blizzard. Midnight Blizzard is the actor that the United States and United Kingdom governments have attributed to Russia's Foreign Intelligence Service, the SVR. Worth reading precisely: Microsoft says it assesses the relationship based on technical and operational overlaps. That is analytic confidence, not a courtroom finding.

From the redirected position, the attack looks like a helpful prompt. The browser runs its normal connectivity check, and the response comes back as a fake update notice: a Windows Update screen, a driver repair utility, a browser update. Microsoft's research documents eight different fake windows the operator can pick from at build time. The user is asked to paste and run something to finish the fix.

Two pieces of malware do the work. Microsoft names them CornFlake, a Windows remote access trojan written in Go that installs itself as a service and re-creates its own persistence if a defender removes it, and ChocoShell, a PowerShell infostealer that runs entirely in memory.

ChocoShell is the one that matters for identity. Microsoft reports that it collects Microsoft 365 and Entra access tokens, refresh tokens, and Web Account Manager tokens from the Token Broker cache on the device. In Microsoft's own words, that collection lets an actor replay single sign-on sessions without browser cookies. It also grabs saved Wi-Fi credentials from the machine, which is a tidy way to make the next venue easier.

The CaptiveCrunch chain, from compromised venue Wi-Fi to replayed Microsoft 365 session.

Two Attack Paths, and Why the Difference Decides Your Controls

This campaign contains two separate routes to your tenant, and conflating them is the fastest way to buy a control that does not cover what you think it covers.

The first path is the malware route described above. The second appeared later. Since July 16, 2026, Microsoft has observed some of the campaign's landing pages redirecting users into device code authentication flows. Device code is a legitimate Microsoft sign-in method built for devices that cannot show a normal login screen, like a conference room display. The abuse is simple: the attacker starts a sign-in, gets a code, and convinces you to type that code into a genuine Microsoft page. You authenticate, and the session you just approved belongs to them.

Microsoft is careful here, and so are we. Its research states plainly that the device code technique "does not appear fundamentally novel." We have covered it before in our breakdown of Microsoft 365 device code phishing and again when the FBI issued a public warning about a phishing kit built to industrialize it. What is new is the setting. A sign-in prompt that appears while you are joining a hotel network feels far more legitimate than the same prompt arriving in an unexpected email.

If you take one thing from this article into your next security meeting, make it this distinction. Across the financial institution tenants ABT manages, the most common finding is not a missing policy. It is a policy that covers less than the person who turned it on believes it covers. Here, one policy covers one of two doors.

The Part That Should Worry You: This Happens After MFA

Multi-factor authentication is not the weak point in this story, and anyone telling you MFA is useless is overselling. MFA defeats large classes of attack, it is the single highest-value identity control most institutions deploy, and nothing here is an argument for turning it off or slowing a rollout.

But a stolen refresh token is not a password. It is the artifact Microsoft issues after you have already proven who you are. The multi-factor prompt happened. Your user passed it, correctly, on their own device. The attacker then copies the receipt.

That describes the malware path. The device code path arrives at the same place by a different road: nothing gets copied, because the user is persuaded to approve a sign-in that was never theirs to approve. Either way the end state is identical, and it is the state that matters. Someone else is holding a live session that your multi-factor prompt already blessed.

That is why the honest answer to "are we covered, we require MFA everywhere" is: partly, and not on this. The follow-up questions are whether your session tokens are bound to a device, whether a risky session gets revoked while it is still live, and whether a managed laptop is even permitted to join an unmanaged network in the first place.

The attacker does not need to beat your multi-factor prompt. They wait until your user passes it, and take what the prompt produced.

The Controls That Actually Map to Each Path

Microsoft published mitigation guidance alongside the research. Below is that guidance organized by which path it addresses, because a control list is only useful when you know what each item covers.

The sixth row of that table, revoking a session while it is still live, is the one we automated. ABT Tokenator, the one automation Guardian owns, calls Microsoft Graph to revoke sign-in sessions on a risk detection. That invalidates the refresh tokens on Microsoft's side, so the attacker cannot keep minting new access from the stolen material and has to authenticate again. Microsoft raises the signal, and the revocation runs on its own without waiting for someone to read an alert. That combination, Microsoft's detection paired with a standing response, is what Guardian MxDR is.

Be precise about what revocation does not do, because this is where people over-trust it. It does not reach into the attacker's browser and delete a cookie, and an access token that was already issued can keep working until it expires. Continuous Access Evaluation is what shortens that window on the workloads that support it, which is why the two belong together rather than as alternatives. The other boundary is upstream: revocation depends on Microsoft flagging risk in the first place, and a quiet replay from a plausible location may never raise a signal. What the automation removes is the hours between a risk signal appearing and a human acting on it, which on a Saturday during a conference is the entire window.

The registration control deserves more attention than it usually gets. If an attacker is riding a stolen session, the natural next move is to register their own authentication method so they no longer need the stolen token. Restricting where registration can happen closes that door, and it is a policy most institutions have never configured. If your Conditional Access baseline is thinner than you would like, our guide to Conditional Access policies for financial institutions covers the foundation this builds on.

One of the seven controls above is already in the Conditional Access baseline we deploy under the M365 Guardian operating model: the device code restriction. The registration-location restriction is the one we most often add next, and this campaign is a good argument for moving it up the list. Guardian is the layer that configures Microsoft's own controls against a documented baseline across every tenant ABT manages, and then monitors for the drift that quietly reopens them. That second half is the part that matters here, because most of the seven controls above are not one-time switches. They get relaxed for a project, exempted for one executive, and never put back. Six months later the policy still exists in the portal, and the exception is what is actually running.

A travel-hardening baseline mapped to Microsoft 365 controls, with the gap each one closes.

Building a Travel Baseline Without Stranding Your Executives

Microsoft's user-facing advice is blunt: when traveling, treat hotel, conference, airport, and other guest wireless networks as untrustworthy. Prefer a phone hotspot or cellular data over venue Wi-Fi. Never accept a software update, certificate, browser update, or network troubleshooting tool offered through a captive portal or an unexpected web prompt. Verify updates through the operating system, not a pop-up.

That is good guidance and it is free. Tell your traveling staff this week. But guidance that depends on a tired person making a good decision is the weakest control in the stack, which is why the technical version matters.

On managed Windows devices you can prevent connections to any Wi-Fi network that was not provisioned by your device management platform. The setting is a policy called AllowManualWiFiConfiguration, and it is genuinely effective, because a device that cannot join the compromised network cannot be redirected by it.

A workable sequence for most institutions looks like this. The first two you can start this week without a budget conversation. The rest need a pilot group, money, or both, and the Wi-Fi restriction needs a rollback plan before it reaches anyone who travels.

Microsoft also lists Global Secure Access, its Security Service Edge offering, as an option for travelers. It is on the list for good reason, though it is worth being realistic: in practice the portal interaction usually has to happen first, which is the exact moment this campaign exploits, so an agent does not remove that step. It changes what an attacker can reach afterward, which is still worth having.

One thing worth thinking through before conference season. If the account whose session gets replayed is licensed for Microsoft 365 Copilot, the attacker does not simply inherit that person's mailbox. They inherit a search tool that will assemble, in a single prompt, whatever that person had permission to reach and never got around to finding. Copilot respects the permissions it is given, which is exactly the problem when the session it is running under is not the one you issued. That is an argument for tightening permissions before you widen a Copilot rollout rather than after it.

It is also worth naming who at your institution this actually targets. At a community bank or credit union, the people who travel most are lending leadership, the executive team, and the board. That is the same short list with the broadest access to loan files, board packets, and strategic plans, which is why "corporate travelers" undersells the exposure.

One more piece of hygiene that costs nothing. Microsoft advises against reusing corporate credentials on venue registration pages, and against volunteering more identifying detail than necessary when booking or registering for guest network access. Conference attendee lists are not a secret, and an actor deciding which venues to compromise is reading them too.

Before any of this, the question worth asking is whether it already happened. Microsoft published detection and hunting guidance alongside the research, so the signals exist to check: risky sign-in reports covering your recent travel dates, authentication methods registered on accounts whose owners did not register them, and file creation immediately after a device ran a network connectivity check. Pull those three for the last ninety days, and for whatever conference your executives attended most recently. If nobody at your institution is reviewing those signals, that is the finding.

What an Examiner Will Ask

The 2021 FFIEC guidance on authentication and access defines multi-factor authentication using the NIST definition, and addresses remote users directly, noting that remote access software such as a VPN can be protected with multi-factor credentials. It is written, sensibly, around the problem of proving that the person signing in is who they claim to be.

It does not contain explicit language about session tokens or token replay. We want to be careful with that observation, because it is easy to misread in both directions. It does not mean examiners have no expectation here, and it certainly does not mean your institution has no obligation. Broader risk-management and layered-security expectations continue to apply, and an examiner is entitled to ask how you addressed a known, publicly documented attack against your environment.

What it does mean is that the control decision belongs to you. Nobody is going to hand you a citation that says "bind your refresh tokens." The defensible position is a documented one: you knew about the risk, you assessed which of your people are exposed, you selected controls, you noted the limitations of those controls, and you can show the dates. That is a far better conversation than producing a policy that says multi-factor authentication is required and hoping the question stops there.

If phishing-resistant methods are still on your roadmap rather than in production, that work now has a second justification beyond the one we wrote about in our piece on phishing-resistant MFA and examiner expectations. And if you want the endpoint side of this story, the same fake-prompt technique used here is the one we broke down in our look at ClickFix infostealers draining Microsoft 365 logins.

Conference season does not pause for a security review. The people most worth targeting at your institution are the ones who travel the most, carry the broadest access, and are the least likely to call the help desk about a strange update prompt at the end of a long day. That combination is the whole reason this campaign exists.

Frequently Asked Questions