Microsoft reports CaptiveCrunch activity resumed through hospitality Wi-Fi

Microsoft says it observed a renewed wave of CaptiveCrunch activity on September 29, after first disclosing the campaign in July. The October 5 update describes manipulated network traffic and captive portals in hospitality environments, with some incidents involving credential theft or malware delivery. It does not say that every hotel, airport or public Wi-Fi network is compromised.

The renewed activity changes the story from a July disclosure about a developing threat into a campaign Microsoft says it has seen return. The practical concern is not simply that travelers connect to shared Wi-Fi. It is that a compromised network gateway can alter what some users see when a device checks whether internet access is available. A familiar-looking sign-in or update prompt can then become part of a credential-theft or malware-delivery attempt.

Microsoft’s October 5 update to its CaptiveCrunch investigation says Threat Intelligence observed Storm-2945 resuming the activity on September 29. Microsoft describes Storm-2945 as an operational sub-cluster of Midnight Blizzard. That is Microsoft’s attribution based on its investigation; the public report does not identify every affected venue or publish a complete count of impacted travelers.

The timeline: from May observations to the October update

The dates matter because some reporting about hotel Wi-Fi gateways appeared before Microsoft’s latest update. ReliaQuest’s July report described its own observations and assessed that the tactics resembled prior APT28 activity, while noting limits to its attribution confidence. Microsoft’s October update attributes CaptiveCrunch to Storm-2945. These assessments should not be collapsed into a claim that every report describes one proven operator or one identical intrusion set. The sources describe overlapping network-access risks, but attribution is an analytical judgment, not a fact established merely by similar techniques.

In its update, Microsoft also says that Black Lotus Labs’ reporting was consistent with the possibility that multiple hospitality managed-service providers were implicated. Microsoft assesses that continued access to upstream providers may have enabled a rapid redeployment. The wording is important: the public report presents an assessment about the campaign’s reach and infrastructure, not a verified list of compromised providers or a conclusion that a particular hotel chain is affected.

Why a hotel login page can become part of the attack

A captive portal is the welcome or sign-in page a network may show before allowing a device onto the internet. Hotels, airports, conference centers and other venues use these pages for ordinary reasons: accepting terms, entering a room code, redeeming a voucher or authenticating with a network provider. Seeing such a page is not, on its own, evidence of an intrusion.

The concern described in CaptiveCrunch is the network infrastructure behind the page. Microsoft says Storm-2945 manipulated DNS and HTTP traffic on networks served by captive portals, redirecting some requests through infrastructure controlled by the actor. A device may open a connection-check page automatically when it joins Wi-Fi. If the network has been tampered with, the resulting browser experience can be redirected to a lookalike sign-in flow or a prompt that claims an update is required.

That changes the social-engineering moment. A traveler is expecting to get online, not to evaluate a new software download. A page that appears immediately after connecting can borrow the venue’s context and urgency: “finish setup,” “repair the connection,” or “update before browsing.” The setting makes the request feel routine even when the action being requested—entering an unrelated account password, running a file, installing an app or changing a device setting—has nothing to do with ordinary Wi-Fi access.

Microsoft says the campaign used actor-controlled phishing infrastructure and fake browser or operating-system update lures. The report also discusses ClickFix-style instructions that attempt to persuade a person to perform a manual action. This article does not reproduce those instructions or list operational indicators. The useful point for travelers is simpler: a connection page should not be treated as an authority to install software or run commands. Use the device’s own update mechanism and the venue’s verified access instructions instead.

In instances where the campaign delivered infostealer malware, Microsoft says it observed a Rust variant of CornFlake. The company described characteristics it considers consistent with continued AI-enabled malware development. That is a finding about samples observed in specific incidents, not proof that AI independently created the malware or that every person who visited a captive portal received it.

What is confirmed—and what is still not public

The most defensible reading is narrower than the alarming headline “hotel Wi-Fi is hacked.” Microsoft has reported observed activity affecting hospitality-related networks and devices whose traffic was manipulated. It has described credential phishing and malware delivery, and it has said the campaign resumed on September 29. The report also explains that its investigation into the initial compromise of captive-portal networks was ongoing.

• Confirmed in Microsoft’s public account: its threat-intelligence team observed renewed CaptiveCrunch activity on September 29 and updated its report on October 5.
• Confirmed as reported activity: traffic manipulation and captive portals were used in hospitality-related environments; some activity led to phishing or malware delivery.
• Not established publicly: a complete list of affected hotels, the total number of exposed devices, or whether a particular traveler’s account was accessed.
• Still under investigation: Microsoft says the initial compromise vector for the captive-portal networks had not been determined in its report.
• Not a justified conclusion: that every hotel network, public hotspot, or device that joined ordinary Wi-Fi is compromised.

This distinction matters for people who have recently traveled. Joining a network is not the same event as entering a password into a counterfeit sign-in page, approving an unexpected authentication request or installing a file. The facts that would change a person’s response are what the device displayed and what the traveler did next—not simply whether the network was public.

What the update means for travelers

For most travelers, the practical response is to keep the access decision separate from the account decision. Confirm the network name and the expected login process with the venue using a route independent of the page on screen. A room number, access code or terms acceptance may be part of a legitimate service. A request to sign into an unrelated mailbox or download a “Wi-Fi repair” program deserves a pause and an independent check.

If the portal asks for a browser update, a certificate, a configuration profile, a mobile application or a command-line action, do not treat the network page as proof that the change is necessary. Close it and use the operating system’s normal update settings or ask the venue through its published contact channel. On a company-managed device, follow the employer’s travel and network policy; a hotel instruction should not override an organization’s controls.

Where available and suitable, mobile data or a personal hotspot can provide an alternative to a questionable network. This is a cautious fallback, not a guarantee against all account compromise. The important safeguard is still to verify where credentials are being entered and to avoid responding to unexpected requests for software installation or account approval.

For organizations, the incident is a reminder that travel security involves more than endpoint antivirus. Staff should know how to report a suspicious portal, what their approved remote-access configuration is, and which helpdesk channel to use when a network demands an unusual step. Security teams can consult Microsoft’s updated detections and hunting guidance if they operate the relevant Microsoft security products; those technical instructions are intended for defenders with the required access, not for travelers to run on personal devices.

If you already interacted with a suspicious page

Start by writing down what happened: the venue, approximate time, network name, page or prompt, and whether you entered information, approved a sign-in, downloaded a file or installed anything. Do not revisit the page to test it. If you entered a password, use a trusted connection to reach the real provider independently, change that password and review account activity and recovery settings. If the same password protects other accounts, change it there too.

If you approved an unexpected sign-in or granted access to an application, tell the account provider or your organization’s security team what you approved. A password change may not revoke an existing session or undo an authorization. If you downloaded or ran a file, avoid using that device for sensitive account recovery until you have followed the appropriate support process. Work devices should be reported through the employer’s incident channel rather than “fixed” by installing tools advertised by the same portal.

These steps are not an indication that every suspicious-looking page caused harm. They are a way to respond proportionately to the specific action taken. If a person only connected to Wi-Fi and did not enter credentials, approve access or install anything, the public reporting alone is not enough to conclude that an account has been compromised.

Why this story is bigger than a fake login

CaptiveCrunch illustrates a difficult trust boundary: a traveler may believe they are dealing with a hotel’s network, while the system handling the connection is operated by an outside service provider or another upstream partner. A guest cannot inspect those relationships from a welcome page. That is why a clear, verified access process matters—and why investigations into shared network infrastructure can take time.

The campaign also shows how familiar digital habits can be repurposed. People expect browsers to check connectivity, portals to request a room number and operating systems to display update messages. Attackers can exploit the timing and context without inventing a completely new behavior. The defense is not to distrust every page or avoid travel connectivity altogether. It is to notice when the requested action crosses the boundary from “connect me” to “give me a separate secret, run a file, or change my device.”

Microsoft says it is continuing to track the activity and has updated indicators and defensive guidance for organizations. The public update does not provide a final incident count or say that the campaign has ended. For travelers, the best current takeaway is therefore measured: hospitality Wi-Fi gateways have been part of a reported targeted campaign, but an ordinary connection is not proof of infection. Verify the venue’s process, refuse unexplained software prompts, and respond to the specific information or action you actually provided.

Sources and related coverage

• Microsoft Security Blog: CaptiveCrunch investigation, updated October 5, 2026 — campaign timeline, Microsoft’s attribution, observed activity and defensive guidance.
• ReliaQuest: DNS Poisoning Tactics Expand to Hospitality Wi-Fi, July 23, 2026 — separate threat research and its assessment of hotel and conference-center gateway activity.
• How to read an OAuth consent request — related coverage on unexpected account authorization.
• When a browser update prompt appears on a webpage — related coverage on distinguishing a real update from a web-based lure.

Editorial note: This report summarizes public threat-intelligence reporting and does not identify affected venues beyond what the cited sources disclosed. Attribution and incident scope reflect the named researchers’ assessments as of October 7, 2026.

The shared-service question behind the venue branding

One reason the investigation is difficult to translate into a simple warning is that “hotel Wi-Fi” can describe several different layers. A venue may own the guest experience and choose the network name, while a specialized provider supplies the captive-portal software, network appliances or day-to-day management. A guest normally sees only the welcome page; they cannot tell from its logo which company operates the systems that route the connection.

Microsoft says it observed commonalities in equipment and management systems across multiple affected networks. It says those similarities could mean the activity was not confined to isolated venue compromises and may involve shared services in parts of the captive-portal ecosystem. That is a meaningful investigative lead, but it is still an assessment. The public report does not name every provider, explain the full access path or establish that all customers of a particular service were affected.

This is also why a traveler should avoid trying to diagnose the network from a single visual clue. A polished page may be legitimate or imitated; a slow connection may be ordinary congestion or a technical fault. Neither appearance proves compromise. Stronger evidence comes from verified notices by the venue or service provider, security-team telemetry, or the specific unexpected action a device was asked to take. Until those facts are available, the proportionate response is to stop at a suspicious request, record what appeared and report it through a known channel rather than circulating an unverified claim about a named hotel.

Microsoft thanked Google Threat Intelligence Group for collaboration on tracking the re-emergence. That partnership does not change the limits of the public evidence: the update offers a threat assessment and defensive guidance, not a consumer-facing directory of safe or unsafe hotels. Travelers should rely on current information from the venue and their employer, while security teams should follow the reporting organizations’ technical advisories for investigation.