Captive Portal Attacks: Proven Hotel WiFi Risk Guide UK

Captive portal pages are the most-clicked screens in British hospitality and the least-owned systems in the building. Every guest who joins the wireless network meets one, accepts whatever it says, and moves on. In 2026 a Russian state-linked operation turned that habit into a global intrusion campaign, and the lesson for UK hotels is uncomfortable: the small appliance that prints your terms and conditions is now a piece of security infrastructure.

Microsoft named the campaign CaptiveCrunch and published its analysis on 31 July 2026. The operators compromised the gateway appliances that run guest wireless at hotels and conference centres, then used that position to forge DNS answers, redirect guests to attacker-controlled pages and harvest Microsoft 365 credentials and tokens. No guest device had to be exploited. The network itself did the work. If you have already reviewed your wider hotel WiFi security posture, this is the specific failure mode that guide warned about, now confirmed in the wild.

This article explains what a captive portal actually does, how CaptiveCrunch abused it, who ran the campaign and what British operators should change. It covers gateway hardening, network design, supplier questions, detection, incident response and the duties a UK hotel owes its guests when the login page it commissioned starts serving malware. It ends with a ninety-day plan that assumes no new hardware budget.

Table of contents

What a Captive Portal Is, and Why It Became the Target
How the CaptiveCrunch Captive Portal Attack Chain Works
Who Is Behind CaptiveCrunch: Storm-2945 and Midnight Blizzard
The Three Payloads Delivered Through a Hijacked Captive Portal
Device Code Phishing: The Captive Portal Trick That Needs No Malware
Why UK Hotels Are Exposed: Shared Captive Portal Platforms
What the UK Numbers Say About Captive Portal Risk in Hospitality
Captive Portal Gateway Hardening: The Controls That Stop This
Captive Portal Design: What a Safe Guest Network Looks Like in 2026
What UK Hotels Owe Their Guests When the Captive Portal Fails
Captive Portal Vendor Management: Questions to Ask Your Supplier
Detecting a Compromised Captive Portal Before a Guest Does
Incident Response When Your Captive Portal Is the Breach
What Business Travellers Should Do on Any Captive Portal
A 90-Day Captive Portal Remediation Plan for UK Hotels
Captive Portal Attacks: Frequently Asked Questions
References

What a Captive Portal Is, and Why It Became the Target

Almost nobody in hospitality can describe what happens between joining an SSID and reaching the terms-and-conditions screen. That gap in understanding is precisely why this attack worked.

The mechanics nobody documents

When a device joins an open wireless network, it is issued an IP address, a gateway and — critically — a DNS resolver by DHCP. On a guest network, all three usually point at the same box. The device then performs an automated connectivity check against a known vendor URL. If the answer is not the expected one, the operating system concludes that a sign-in is required and opens a browser window. The page that appears is served by the gateway. That is the whole trick: a captive portal works by deliberately intercepting and rewriting traffic before the guest is authorised.

The appliance is a man-in-the-middle by design

Read that description again from an attacker’s point of view. A captive portal system is a legitimate, permanently deployed interception device that every guest is trained to trust and to click through without reading. It resolves DNS for every connected client. It answers HTTP requests on behalf of other hosts. It presents pages that look nothing like the site the user asked for, and users accept that as normal. Compromise it once and you inherit all of those powers over everyone in the building.

Why it sits outside every security programme

The gateway is usually bought as part of a wireless installation, configured by an installer, and never touched again. It rarely appears on an asset register. It is often excluded from patching schedules because nobody is sure who owns it. It frequently has an internet-facing management interface so the supplier can support it remotely. In most properties, the captive portal is the single most privileged device with the least governance attached to it.

The pattern is not limited to hotels

ReliaQuest’s researchers noted that the same appliance families run guest wireless in conference centres, airports, co-working spaces, universities, healthcare sites and event venues. Anywhere a captive portal fronts a shared network, the same exposure exists. Hotels dominated the observed victim set simply because hotels have the highest concentration of corporate travellers signing into work accounts.

How the CaptiveCrunch Captive Portal Attack Chain Works

The chain is short, which is part of what makes it effective. There is no exploit against the guest device at any stage until the guest chooses to run something.

Step one: compromise the gateway

ReliaQuest assessed with low-to-medium confidence that initial access came from internet-facing management services — SSH, SNMP and web administration consoles — combined with weak or reused administrative credentials. No zero-day was required. These are appliances left reachable from the public internet with the credentials the installer set.

Step two: own DNS for every client

Because the compromised appliance is the DHCP-assigned resolver, the attacker controls name resolution for every device that connects. ReliaQuest put it plainly: once that foothold exists, the attacker controls DNS resolution for every client, without touching a single endpoint. This is the step that converts one appliance compromise into building-wide adversary-in-the-middle access, catalogued by MITRE as technique T1557.

Step three: redirect the connectivity check

Microsoft observed the operators manipulating DNS and HTTP traffic from networks served by captive portals from early May 2026. The redirect is triggered by the operating system’s own automated connectivity check — the same mechanism that normally makes the captive portal window appear. The guest does not have to browse anywhere. The prompt arrives on its own, at the exact moment the user expects a captive portal to interrupt them.

Step four: choose a payload

From the adversary-in-the-middle position, three outcomes were observed. Some guests were shown a fake Microsoft 365 sign-in page. Some were pushed a fake browser or operating system update. From 16 July 2026, some were funnelled into Microsoft’s genuine device code authentication flow. Each is covered in detail below.

Date	What happened	Source
February 2026	AI-augmented operations begin within the cluster	Microsoft
Early May 2026	DNS and HTTP manipulation observed on captive portal networks	Microsoft
June 2026	Gateway compromises active across US cities, India and Saudi Arabia	ReliaQuest
16 July 2026	Landing pages begin redirecting into device code authentication	Microsoft
23 July 2026	Public disclosure of the DNS poisoning campaign	ReliaQuest
31 July 2026	Campaign named CaptiveCrunch and attributed to Storm-2945	Microsoft

Who Is Behind CaptiveCrunch: Storm-2945 and Midnight Blizzard

Attribution matters here for one practical reason: it tells a hotel operator what the attacker wants, and therefore which guests are actually at risk.

The named actor

Microsoft attributes CaptiveCrunch to Storm-2945, which it assesses as an operational sub-cluster of Midnight Blizzard. Midnight Blizzard is more widely known as APT29 or Cozy Bear, and both the UK and US governments attribute that broader actor to Russia’s Foreign Intelligence Service, the SVR. This is espionage tradecraft, not commodity crime.

The competing assessment

ReliaQuest, which disclosed the gateway compromises eight days earlier, stopped short of attribution. Its analysts noted tradecraft resembling APT28 — Fancy Bear or Forest Blizzard, associated with Russian military intelligence — while explicitly flagging that the assessment rested on overlapping techniques rather than direct technical linkage. Both readings point in the same strategic direction.

What the target list tells you

The traffic passing through the compromised gateways came from organisations in financial services, professional services, legal, healthcare, energy and retail. That is not a sector-specific campaign. It is a campaign against travelling employees, wherever they happen to sleep. A hotel is not the target; it is the collection point.

Why the AI angle is being reported

Microsoft found unusually consistent developer comments inside the ChocoShell code, including references to detection signatures and explanations of evasion decisions, and noted that the pattern suggests AI-assisted code generation may have been used. Microsoft did not confirm it. Treat it as a signal about tooling speed rather than a new category of threat.

The Three Payloads Delivered Through a Hijacked Captive Portal

Microsoft documented a three-part toolkit. Understanding what each component takes is what lets a hotel explain the risk honestly to a corporate client.

CornFlake, the persistent implant

CornFlake is a full-featured Windows remote access trojan written in Go. Microsoft documented a raw input keylogger capturing all keystrokes, idle-triggered and on-demand screenshots, microphone capture, webcam access, a module derived from ChromeKatz supporting live cookie extraction, and a remote shell through cmd.exe or PowerShell. It installs as a Windows service named svchost32 with the display name Cloud Sync Service, and a watchdog routine restores any persistence mechanism a defender removes.

ChocoShell, the in-memory stealer

ChocoShell is a PowerShell infostealer delivered and executed entirely in memory. It disables the Antimalware Scan Interface before harvesting browser cookies, saved passwords, Microsoft 365 single sign-on tokens, Azure AD access tokens, Web Account Manager tokens and stored wireless credentials. It uses three separate user account control bypass techniques with fallbacks, and communicates over HTTPS using URI paths designed to blend in with legitimate web traffic.

FruitStone, the operator console

FruitStone is the web-based command-and-control panel used to run the campaign. It is branded as a CloudSync Console and masquerades as a company called Acuity Systems, Inc. It offers an agent dashboard with real-time status, a campaign builder wizard for producing new payloads, and multi-operator support. Its existence is why this reads as an industrialised operation rather than opportunistic tampering.

Component	Type	What it takes	Why a hotel should care
CornFlake	Go Windows RAT	Keystrokes, screenshots, microphone, webcam, cookies, shell	A guest leaves your building with a monitored laptop
ChocoShell	In-memory PowerShell stealer	Cookies, passwords, M365 and Entra tokens, WiFi credentials	Leaves almost no disk artefacts to find afterwards
FruitStone	Web C2 panel	Agent management, payload building, collected data review	Indicates sustained operations, not a one-off test

The ClickFix delivery step

None of this happens silently. The fake update page uses the ClickFix pattern — user execution of a malicious file dressed as a repair procedure. Microsoft observed instructions for manually repairing a failed automated driver repair, including steps to run a verification script via Windows Terminal. The guest copies a command and runs it. That single human action is the only gate between a poisoned captive portal and a compromised endpoint.

Device Code Phishing: The Captive Portal Trick That Needs No Malware

The most elegant part of the campaign involves no malicious software at all, which is exactly why it defeats most endpoint controls.

How the flow is abused

Device code authentication exists so that input-constrained devices — televisions, meeting-room panels, command-line tools — can sign a user in. The device shows a short code, and the user enters it on a normal Microsoft page from a phone or laptop. From 16 July 2026, CaptiveCrunch landing pages began instructing guests to enter a supplied code into a genuine Microsoft sign-in page. The page is real. The certificate is valid. The domain is Microsoft’s. The code belongs to the attacker.

Why every instinct fails here

Everything security awareness training teaches a user to check comes back clean. There is no lookalike domain, no certificate warning, no attachment. Multi-factor authentication does not help, because the user completes it willingly on the legitimate page. What the attacker receives at the end is a valid token for the user’s account, issued by Microsoft, on a device the organisation has never seen.

The control that actually works

Both Microsoft and ReliaQuest give the same answer: block the device code flow in Conditional Access wherever it is not needed. Microsoft’s guidance on blocking authentication flows covers the policy directly, and the device code flow documentation explains which legitimate scenarios need an exception. For most organisations that list is very short.

What the guest sees	What the attacker gets	What stops it
A fake Microsoft 365 sign-in page	Username and password, replayed live	Passkeys, phishing-resistant MFA
A genuine Microsoft page asking for a code	A valid access token on an unknown device	Conditional Access blocking device code flow
A browser or OS update prompt	CornFlake or ChocoShell on the endpoint	Never updating software from a captive portal
A driver repair with a command to paste	Attacker code running as the signed-in user	Blocking paste-and-run, user training

Why UK Hotels Are Exposed: Shared Captive Portal Platforms

British operators reading the victim list — US cities, India, Saudi Arabia — may conclude this is somebody else’s problem. The supply chain says otherwise.

One supplier, hundreds of properties

Microsoft noted commonalities in the equipment and management systems across affected networks, suggesting access to shared captive portal services rather than individual venue compromises. UK hospitality runs on exactly that model. A handful of specialist providers operate guest wireless for large parts of the sector, and a single management platform can reach hundreds of properties. A compromise upstream is a compromise everywhere downstream.

Brand standards do not equal control

Franchise and management agreements typically mandate that a property provides guest wireless meeting a brand standard. They rarely specify who patches the gateway, who holds the administrative credentials, or who is notified when the vendor’s platform is breached. The result is a control that everybody assumes somebody else owns.

The exposure arithmetic

Model it explicitly for a 180-room property. Assume 78% occupancy, giving 140 occupied rooms a night (180 x 0.78 = 140.4, rounded down). Assume two devices per occupied room join the captive portal, a phone and a laptop, giving 280 sessions a night. Over the 92 days from 1 May to 31 July 2026 that is 25,760 captive portal sessions. If one session in twenty belongs to a corporate traveller who signs into Microsoft 365 while connected, that is 1,288 identity opportunities from one appliance.

Captive portal sessions exposed at one 180-room property (280 per night)

One night 280

One week 1,960

Thirty nights 8,400

Ninety-two nights 25,760

Conference space multiplies it

A property with meeting rooms concentrates exactly the guests this campaign wants. Delegates arrive, join the captive portal on a corporate laptop, and sign into work accounts within minutes. Venues that market themselves to corporate bookers have a materially higher-value guest network than their room count suggests.

What the UK Numbers Say About Captive Portal Risk in Hospitality

The national statistics explain why a campaign like this succeeds against British operators specifically.

The breach baseline

The UK government’s Cyber Security Breaches Survey 2025/2026, published in April 2026 by DSIT and the Home Office, found 43% of UK businesses reported a breach or attack in the previous twelve months — roughly 612,000 organisations. Phishing was involved in 38% of cases and was the most disruptive breach type for 69% of those affected.

The size curve is the hospitality curve

Reported breach rates rise sharply with organisation size: 42% of micro businesses, 46% of small, 65% of medium and 69% of large. Hotel groups sit in the upper bands while individual properties are staffed like the lower ones — a mismatch that puts enterprise-scale exposure behind small-business resourcing.

UK businesses reporting a breach or attack, by size (2025/2026 survey)

Micro 42%

Small 46%

Medium 65%

Large 69%

The preparedness gap

Only 25% of UK businesses hold a formal incident response plan and only 31% have a board member with responsibility for cyber security. Cyber Essentials certification stands at 5%. Those three figures describe an industry that will discover a compromised captive portal from a guest complaint rather than from a control.

What the wider threat data adds

The Verizon Data Breach Investigations Report for 2026 found software-flaw exploitation had become the leading initial entry point at 31%, overtaking stolen credentials, with the human element present in 62% of breaches and third-party involvement now reaching 48%. CaptiveCrunch is all three at once: an exploited appliance, a human click, and a supplier’s platform.

Breach factors relevant to a captive portal compromise

Human element involved 62%

Third-party involvement 48%

Phishing in UK breaches 38%

Software-flaw exploitation 31%

Captive Portal Gateway Hardening: The Controls That Stop This

Every documented entry route in this campaign is closed by configuration rather than capital expenditure. Nothing below requires new hardware.

Take the management plane off the internet

The single highest-value change is removing SSH, SNMP and the web administration console from public reachability. Management should be accessible only from a dedicated administrative network or through a supplier VPN with named accounts. This one control removes the entire assessed initial-access route.

Replace installer credentials

Weak or reused administrative credentials were the second half of the assessed entry method. Every gateway, controller and access point needs a unique credential held in a password manager, with the installer’s account removed rather than merely renamed. Enable multi-factor authentication on the vendor’s management platform if it is offered, and check the vendor’s own account recovery process while you are there.

Patch the appliance like a server

The gateway runs an operating system and a web stack. Open-source captive portal software is patched on the same cadence as anything else — the openNDS vulnerability remediation guidance shows what a single captive portal package can accumulate between releases. Put the appliance on the same patch calendar as your servers and record the version in your asset register.

Pin and monitor DNS

If guest DNS resolution is forced to a known upstream resolver and monitored, a poisoned answer becomes visible. Log queries where you lawfully can, alert on resolution for Microsoft sign-in hostnames that returns unexpected addresses, and make sure the gateway itself cannot silently become the authoritative answer for domains it does not own. Proper network monitoring is what turns this from a theoretical control into an alert.

Control	What it prevents	Evidence to retain
No internet-facing management	The assessed initial access route	External scan showing closed ports
Unique administrative credentials	Credential reuse across the estate	Password manager entry, account list
Appliance on the patch calendar	Known vulnerabilities in the gateway	Firmware version and date per device
Forced, monitored upstream DNS	Silent DNS forgery on the guest network	Resolver configuration and query logs
Guest network isolation	Lateral movement into business systems	VLAN map and inter-VLAN rule set
Quarterly rogue AP scan	Unauthorised wireless alongside the captive portal	Scan report with dates and findings

Captive Portal Design: What a Safe Guest Network Looks Like in 2026

Hardening the appliance is necessary but not sufficient. The design around it decides how much damage a future compromise can do.

Segment first, portal second

A compromised gateway on a properly segmented network reaches guests and nothing else. On a flat network it reaches the property management system, the point-of-sale estate and the building controls. The detailed design work is covered in our guide to VLAN segmentation for hotel guest WiFi, and it remains the highest-value structural control available to any property.

Enable client isolation

Guest devices should not see each other. Client isolation is a single setting on most controllers and prevents an infected laptop in one room from scanning its neighbours. It costs nothing and it is off by default more often than it should be.

Consider Enhanced Open

The Wi-Fi Alliance defines Enhanced Open, based on Opportunistic Wireless Encryption, which gives every client its own encryption on a password-free network. It defeats passive eavesdropping, which is worth having. It does not authenticate anything and it will not stop a compromised captive portal, so deploy it as one layer rather than as a fix.

Reduce what the captive portal collects

Every field on the sign-in form is personal data you must then protect, justify and eventually delete. Room number and surname verification is defensible. Marketing consent capture with indefinite retention is a liability with a captive portal attached to it. Shorter forms and shorter retention periods make the whole system less attractive to steal.

Design factor	Typical legacy setup	Hardened 2026 setup
Management access	Public SSH and web console	Admin VLAN or supplier VPN only
Guest DNS	Resolved by the gateway, unlogged	Forced upstream resolver, monitored
Network layout	Flat, one broadcast domain	Guest, staff, payments, building, management
Client-to-client traffic	Permitted	Isolated at the controller
Encryption on guest SSID	None	Enhanced Open, with WPA3 elsewhere
Portal data captured	Everything, retained indefinitely	Minimum fields, defined retention
Ownership	Unassigned	Named owner, on the asset register

What UK Hotels Owe Their Guests When the Captive Portal Fails

The legal position is less ambiguous than most operators assume, and the reputational position is harsher.

Portal records are personal data

Sign-in records that tie a device to a room and a surname are personal data under UK GDPR. A compromise that exposes them, or that uses the same system to attack the people who submitted them, is a security incident with a reporting question attached. The ICO’s guidance on reporting a breach sets out the 72-hour assessment clock.

You cannot outsource accountability

Where a specialist provider operates the captive portal on your behalf, they are typically a processor and you remain the controller. Contractual delegation of the work does not delegate the duty. That makes the supplier’s security posture your risk, which is why IT governance over outsourced systems belongs on the executive agenda rather than in the facilities file.

Corporate clients will ask

Any organisation that has read the CaptiveCrunch reporting now has a reason to ask a venue how its guest wireless is secured before signing a conference contract. A property that can answer with a segmentation diagram, a patch record and a rogue access point scan will win business from one that cannot. This is rapidly becoming a commercial differentiator rather than a compliance chore.

Payment scope still applies

If any part of your estate touches cardholder data, PCI DSS requires quarterly detection of unauthorised wireless access points under requirement 11.2.1, even where wireless is prohibited in the cardholder data environment. Segmentation is not mandatory under the standard, but it remains the cheapest way to shrink assessment scope.

Captive Portal Vendor Management: Questions to Ask Your Supplier

Most UK properties do not operate their own gateway. That makes supplier assurance the primary control, and a short list of questions does most of the work.

The eight questions that matter

Ask each of these in writing and keep the answers: Is any management interface reachable from the internet? Which administrative accounts exist on our appliance and who holds them? What firmware version are we running and when was it last updated? Which DNS resolvers do our guests use? Is client isolation enabled? Where are portal sign-in records stored, and for how long? How would you notify us of a compromise on your platform? Have you assessed our estate against the CaptiveCrunch indicators?

What a good answer looks like

A competent provider will answer all eight without escalation, will already have checked the published indicators of compromise, and will offer evidence rather than assurance. A provider that cannot name your firmware version is telling you that nobody has looked at your appliance since installation.

Put it in the contract at renewal

Patch cadence, notification obligations, credential ownership and a right to scan should be contractual rather than assumed. Structured vendor management turns a wireless contract from a coverage guarantee into a security agreement, and renewal is the only moment when you have leverage to change it.

Check the platform, not just the box

Because the compromises appeared to reach shared management systems rather than individual venues, ask specifically about the multi-tenant platform behind your appliance. Who can administer your tenant? Is access to it multi-factor protected? What happened during the CaptiveCrunch disclosure window, and what did the provider change afterwards?

Detecting a Compromised Captive Portal Before a Guest Does

Detection in this scenario is unusual, because the strongest signals appear on devices you do not own.

Watch for the wrong prompt

A guest reporting that the hotel network asked them to install a browser update, run a command in Windows Terminal, or enter a code into a Microsoft page is describing an active compromise. Front-of-house staff should be told that these three reports are escalations, not IT support requests, and should have a named person to pass them to immediately.

Test your own portal from a guest device

Someone should join the guest network weekly from a device that is not on the corporate network, complete the sign-in and confirm that the captive portal looks exactly as commissioned and that no update prompt appears. This is a five-minute task that catches the visible half of the attack, and it is the closest thing to a free control available.

Check the published indicators

Microsoft published domains including ms365-device[.]com, ms365-live[.]com, m365-owa[.]com and owa-ms365[.]com, alongside attacker IP addresses. Any DNS or firewall telemetry you retain should be searched against them, and your supplier should confirm it has done the same across its estate. Good cybersecurity practice here is simply asking for the search results in writing.

Monitor the appliance itself

Administrative logins to the gateway, configuration changes, firmware changes and new outbound connections from the appliance are all worth alerting on. Most properties have none of this because the gateway was never onboarded into device management in the first place, which is the underlying problem rather than a monitoring gap.

Incident Response When Your Captive Portal Is the Breach

If the gateway is compromised, the incident has two victim populations: your business and every guest who connected. Both need handling.

Contain without destroying evidence

Isolate the appliance from the guest network rather than factory-resetting it, and preserve logs and configuration before rebuilding. A reset removes the only record of what was changed and when, which matters enormously when you later have to tell corporate clients which dates were affected.

Rebuild rather than clean

The gateway should be rebuilt from known-good firmware with new credentials, not repaired in place. Anything that could hold attacker persistence — scheduled tasks, custom scripts, additional accounts, modified portal templates — is cheaper to discard than to audit.

Work out the exposure window

You need two dates: when the compromise began and when it was contained. Everything between them is a period during which guests may have been served hostile content. That window drives your notification decisions, your guest communications and any conversation with corporate accounts. The NCSC incident management collection is the right framework to work through, and a retained incident response capability is what makes the timeline achievable.

Tell guests something useful

A notice that says a third-party wireless system was compromised, states the dates, and advises anyone who installed software or entered a code while connected to contact their own IT team is far more valuable than a generic apology. It is also the version that corporate clients will accept.

What Business Travellers Should Do on Any Captive Portal

Hotels cannot fix guest behaviour, but they can publish sensible advice — and employers can enforce most of it centrally.

The four rules that cover almost everything

Never install a software update offered while connected to a guest network. Never paste a command into a terminal because a web page asked you to. Never enter an authentication code you did not personally request. Never reuse a corporate password on a captive portal registration form. Microsoft’s own guidance lists all four, and they cost nothing to follow.

Employer-side controls do the heavy lifting

An always-on full-tunnel VPN neutralises DNS and HTTP manipulation on any untrusted network, which is why both Microsoft and ReliaQuest lead with it. Blocking the device code flow removes the token theft path. Preventing connections to networks not provisioned through mobile device management removes the decision from the traveller entirely. Deploying passkeys removes the value of a stolen password.

Cellular is the simplest answer

For short stays, a phone hotspot or an eSIM data plan avoids the captive portal altogether. For teams that travel constantly, an enterprise-managed travel router creates a single controlled network the devices trust, with the hotel connection upstream of it. Both are cheaper than an incident.

Control	Hotel	Employer	Traveller
Gateway hardening and patching	Owns	Can ask for evidence	No control
Always-on full-tunnel VPN	No control	Owns	Must leave it enabled
Blocking device code flow	No control	Owns	No control
Refusing portal-served updates	Can warn	Can train and block	Owns the decision
Passkeys instead of passwords	No control	Owns	Must enrol
Using cellular instead of guest WiFi	No control	Can fund	Owns the choice

A 90-Day Captive Portal Remediation Plan for UK Hotels

This plan assumes no new hardware, one competent supplier and a few hours of management attention a week.

Days 1 to 14: find out what you have

Identify every gateway, controller and access point, record model and firmware version, and establish who holds the administrative credentials. Ask your supplier the eight questions above in writing. Run an external scan of your public IP ranges and confirm no management interface answers. Most properties find at least one surprise in this fortnight.

Days 15 to 45: close the entry routes

Remove internet-facing management access, replace all administrative credentials, apply outstanding firmware updates and force guest DNS to a monitored upstream resolver. Enable client isolation. Confirm the guest network cannot reach payment, property management or building systems, and document the rule set that enforces it.

Days 46 to 75: prove it

Commission an independent test of the guest network, including an attempt to reach business systems from a guest device. A structured penetration test turns a configuration claim into evidence you can show a corporate client, and it satisfies the segmentation testing expectations that apply if you are in payment scope.

Days 76 to 90: make it durable

Add the gateway to your asset register and patch calendar with a named owner. Write the escalation path for guests reporting update prompts. Schedule the quarterly rogue access point scan and the weekly guest-device portal check. Put patch cadence and breach notification into the supplier contract at the next renewal, and brief the board using the survey figures above.

What this costs

For most properties this is configuration time plus one test, not capital expenditure. Where an appliance is genuinely end-of-life, replacement belongs in the next refurbishment cycle rather than an emergency budget. An independent review from a managed IT services partner is usually cheaper than the first hour of an incident, and properties without in-house expertise can lean on a local IT support team in Chester to run the fortnightly milestones.

Captive Portal Attacks: Frequently Asked Questions

Was CaptiveCrunch confirmed at any UK hotel?

Neither Microsoft nor ReliaQuest named affected venues. ReliaQuest traced compromised gateways to multiple US cities, India and Saudi Arabia. Microsoft described hospitality networks in several countries without enumerating them. The absence of a named UK property is not evidence of UK safety, particularly given the shared-platform pattern both reports describe.

Does a VPN really protect a guest on a hostile network?

An always-on, full-tunnel VPN prevents DNS and HTTP manipulation from reaching the applications on the device, which removes the redirection step entirely. It does not protect a user who then chooses to run a command they were shown. Both defences are needed, which is why Microsoft pairs the VPN recommendation with ClickFix awareness training.

Is this a reason to remove the captive portal altogether?

No. Removing the sign-in page does not remove the gateway, and the gateway is the compromised component. A property that drops the captive portal but keeps an unpatched, internet-managed appliance has changed nothing. Harden the device and the network design instead.

How is this different from an evil twin attack?

An evil twin is a rogue access point broadcasting a familiar SSID and hoping guests connect. CaptiveCrunch compromised the real infrastructure, so guests connecting to the genuine hotel network were served hostile content by the legitimate captive portal. There is no wrong SSID to spot, which is why guest-side detection fails.

What should we tell corporate clients who ask?

Tell them what you have verified: whether management interfaces are exposed, what firmware you run, how guest traffic is segmented, which resolver guests use, and when the network was last tested. Specific answers close deals. Assurances that the wireless is “fully secure” invite the next question.

Does Cyber Essentials cover any of this?

Partly. Cyber Essentials covers firewalls, secure configuration, patching and access control, all of which bear directly on the gateway. It is a sensible baseline, and at 5% national certification it also remains a genuine differentiator when a corporate booker asks.