Your security awareness program has spent years teaching people one lesson: be suspicious of the inbox. Check the sender. Hover the link. Do not open the attachment.
That lesson is correct. It is also incomplete in a way that a Russian state-linked operation has been quietly exploiting since May.
On July 31, Microsoft Threat Intelligence published research on a campaign it calls CaptiveCrunch, attributed to Storm-2945, an operational sub-cluster of Midnight Blizzard. The US and UK governments attribute Midnight Blizzard to Russia’s foreign intelligence service, the SVR. The campaign does not start with an email. It starts with the sign-in page that appears when a traveler joins the Wi-Fi at a hotel or a conference center.
The captive portal was always a strange thing to trust
Think about what a captive portal asks a user to do.
It intercepts their traffic. It redirects their browser to a page they have never seen before, hosted on a domain they cannot verify, styled by a vendor they have never heard of. It asks for a room number, a last name, an email address, sometimes an agreement to terms nobody reads. Then it lets them through.
Every single one of those behaviors is something we train users to treat as a red flag anywhere else. On hotel Wi-Fi, we train them to treat it as normal. We had to, because the alternative was a help desk ticket every time someone traveled.
Storm-2945 built an operation on top of that trained tolerance.
How the chain works
Microsoft’s research describes an adversary-in-the-middle position established at the network layer. Once the actor controls DNS and HTTP responses on a portal-served network, three things become possible that are not possible from an inbox.
The lure arrives before the user does anything. When a device joins a network, the operating system automatically issues a connectivity check to confirm whether the connection is open or gated. The user does not initiate it. The user does not see it. In this campaign, that automatic check gets answered with attacker-controlled content, including prompts styled as browser updates, operating system updates, or repair utilities. Some of these are ClickFix-style lures that walk the user through pasting a command into a terminal themselves.
The destination looks legitimate because it partially is. Microsoft and ReliaQuest both documented lookalike domains mimicking Microsoft online services, used to run adversary-in-the-middle phishing against sign-in flows. A user who has just accepted one unfamiliar interstitial page is primed to accept a second one.
And then there is the device code. Since mid-July, some CaptiveCrunch landing pages have pushed users into the device code authentication flow. This is worth understanding precisely, because it is the part that defeats the mental model most organizations are operating on.
Why “we have MFA” is not the answer here
Device code authentication is a legitimate OAuth workflow. It exists for devices that cannot render a normal sign-in experience, like a TV or a conference room appliance. The device displays a short code, and the user enters that code on a real sign-in page from a second device.
An attacker can start that flow themselves and then convince the user to type the attacker’s code into the genuine Microsoft sign-in page. The user sees the correct domain. The certificate is valid. Multi-factor prompts come from the real identity provider, and the user approves them, because from the user’s perspective nothing is wrong. What they have done is authenticate the attacker’s session.
Microsoft is direct that the technique itself is not new. What is new is the delivery. A device code prompt served through a captive portal, at the exact moment a user expects to jump through an unfamiliar authentication hoop to get online, is far more believable than the same prompt arriving cold in an email.
Push-based MFA does not stop this. A one-time code does not stop this. The user is not being tricked into handing over a credential. They are being tricked into completing a legitimate authorization on the attacker’s behalf.
The supply chain nobody put on the questionnaire
Here is the structural finding that should change how security leaders think about this.
Microsoft noted common equipment and management systems across multiple affected networks and assessed that the activity might not be a series of unrelated venue compromises. It could instead reflect access to shared services within portions of the captive portal ecosystem.
Read that again with a vendor risk lens. A handful of providers supply the guest Wi-Fi management layer behind an enormous number of hotels, conference centers, and shared venues. Your organization has never assessed any of them. They are not in your third-party inventory. They have never filled out your questionnaire. Nobody in procurement has heard of them. And every time one of your executives’ travels, they connect to infrastructure operated by one of them.
This is the same asymmetry we keep running into on engagements. Organizations spend enormous effort hardening the systems they know they own, then walk their most sensitive accounts through infrastructure they have never once evaluated.
What your phishing simulation program did not cover
If your awareness program is built around simulated email, your people have been trained to spot a category of attack that this operation never uses.
Ask yourself honestly whether your users would recognize any of the following:
A browser update prompt that appears immediately after joining conference Wi-Fi. A “network verification failed” page with instructions to paste a command into Windows Terminal. A device code screen presented as a step required to reach the internet. A sign-in page on a domain that is one hyphen away from the real one, reached without the user ever typing a URL.
None of those are email. None of them will be caught by a mail gateway. None of them show up in a quarterly click-rate report. If the only phishing your program tests is the kind that arrives in an inbox, you have measured one channel and declared the whole surface covered.
What to do
The mitigations here are not exotic. They are just things most organizations have not prioritized because the scenario felt abstract until now.
Treat guest networks as hostile by default. Microsoft’s own guidance to travelers is to prefer cellular data, hotspots, or eSIM connectivity over venue Wi-Fi where practical. For managed devices, policy can restrict connections to networks that have not been provisioned. Enterprise travel routers that tunnel back to trusted infrastructure are a reasonable control for high-value travelers.
Block the device code flow where it is not needed. This is the single highest leverage change available. Most organizations do not need device code authentication broadly enabled. Where it is required, scope it with conditional access rather than leaving it open tenant wide.
Move to phishing-resistant authentication. Passkeys and FIDO2 credentials change the math on adversary-in-the-middle. Prioritize privileged accounts and frequent travelers first rather than waiting for a full rollout.
Establish the rule that updates never come from a network prompt. Legitimate operating system and browser updates do not arrive through a captive portal or a pop-up. Neither do certificates, repair tools, or verification scripts. Anything asking a user to paste a command into a terminal is malicious. Say it plainly and repeat it.
Stop reusing corporate credentials on venue registration pages. The email address and organizational affiliation your employees hand a hotel portal is targeting data, and it is being collected at scale.
Extend the tested surface beyond email. Your social engineering testing should include the channels an actual operator would use, which now clearly includes network-position lures, fake update prompts, paste-and-run instructions, and OAuth abuse.
The uncomfortable framing
The traveler in this scenario did nothing wrong by the standard of the training they received. They did not click a suspicious link. They did not open an attachment from a stranger. They joined the Wi-Fi at a conference their company paid to send them to, and they followed the prompts the network gave them.
That is what a mature adversary looks like. It does not attack the control you tested. It attacks the assumption underneath it.
Compliance frameworks will keep asking whether you run phishing simulations. They will not ask whether your executives can be compromised between the airport and the keynote. That gap is not going to be closed by an annual artifact. It gets closed by testing the way an attacker operates.