A connection that looks ordinary
On July 31, 2026, Microsoft Threat Intelligence published an analysis of a campaign called CaptiveCrunch. Since early May, attackers have been manipulating traffic on networks that use captive portals, particularly in hospitality. The activity also involves conference centers and other shared venues; initial reporting by ReliaQuest, cited by specialist coverage, suggests that business travelers are a preferred target.
The lesson is not that every hotel Wi-Fi network is dangerous. It is that a network can be genuine and provided by the right venue while still presenting an attacker-controlled page if the equipment managing the portal has been compromised.
The captive portal as a trust boundary
When a laptop or phone joins public Wi-Fi, the network tells it where to find certain services, including the sign-in page. Normally this is invisible. In CaptiveCrunch, Microsoft observed DNS and HTTP manipulation that redirected users to attacker-controlled infrastructure.
Several follow-on actions were observed: fake browser or operating-system updates, Microsoft 365 pages designed to capture credentials, and, since July 16, abuse of the device-code authentication flow. The delivered malware could collect files, keystrokes, credentials, and session tokens.
Why the page can feel legitimate
A page that appears immediately after joining Wi-Fi benefits from the context. The user expects to click, accept, or wait, so a software update can look like a normal part of getting online.
The device-code flow is even more deceptive. It is a legitimate Microsoft feature, but an attacker can provide a code and persuade the victim to enter it on the real sign-in site. The page is genuine; the session belongs to the attacker. Approving MFA in that situation does not make the request legitimate.
Rules worth sharing with a team
While traveling, one simple rule blocks most of the scenarios described: a captive portal may request network access, but it should never request a work password, a system update, a Microsoft device code, or an unexpected MFA approval.
In practice:
- Use your phone’s hotspot for sensitive work, or a full-tunnel VPN already configured by your organization.
- Do not install software or run commands suggested by a page that appeared after joining Wi-Fi.
- Reject any device-code or MFA request that you did not initiate yourself.
- If you must sign in, open the usual bookmark directly from an up-to-date device and verify the domain and the context of the request.
- Report unusual pages to IT immediately, even if you did not install anything.
What this means for an SMB
Security does not stop at the office. A traveling employee may have several sensitive accounts on one laptop: email, invoicing, CRM, document storage, and administration tools. A stolen session token or password can therefore be more valuable than the device itself.
Reducing the impact requires unique secrets, phishing-resistant MFA where available, short-lived sessions, and the ability to revoke access quickly. Soclyde can help with the secret-management layer: generate different passwords for each service and keep them in a local-first vault. That does not secure public Wi-Fi or a Microsoft 365 configuration, but it limits the blast radius of a compromise and avoids centralizing every credential in a cloud repository.
To review your team’s practices, read the Soclyde guide to local-first password managers.
