> guest@lobby:~$ nmap -sn 10.10.0.0/16 | grep 'Host is up' | wc -l && echo 'internal hosts reachable from guest'<span class="cursor-blink">_</span>_
Every organisation we assess has a guest wireless network. The password is on a card at reception, printed on a whiteboard in the meeting room, or displayed on a screen in the lobby. It provides internet access for visitors, contractors, and personal devices. It is universally described as 'isolated' — separated from the corporate network by firewall rules that permit only outbound internet traffic.
And in a significant proportion of the environments we test, that isolation is incomplete. Not absent — the guest VLAN exists, the firewall rules exist, the architecture diagram shows a clean separation. But somewhere in the rule set, a path exists. A permitted port. A shared service. A VLAN that bridges two worlds. A rule added three years ago for a reason nobody remembers.
On this engagement, we connected to the guest wireless network in the reception area — using the password displayed on a laminated card beside the visitor sign-in book — and, within two hours, had accessed an internal file share containing board minutes, financial forecasts, and client contract documentation. From the guest network. As an unauthenticated visitor.
The client was a management consultancy — a firm of approximately two hundred and fifty staff handling commercially sensitive engagements for FTSE 250 clients. Confidentiality was central to their business. Client deliverables, strategic analyses, due diligence reports, and M&A documentation were the firm's primary assets. A data breach would not merely be a regulatory matter — it would be an existential reputational event.
We had been engaged to conduct an internal network penetration test with an additional scope element: guest network isolation testing. The client's compliance team had identified guest network segmentation as a control in their ISO 27001 risk treatment plan, and they wanted independent validation that the guest network was genuinely isolated from the corporate environment.
We were given no credentials, no network documentation, and no internal access. Our starting position was the guest wireless network — the same access available to any visitor who walked through the front door.
The guest wireless SSID was GUEST-[COMPANY], broadcast from the same enterprise wireless controller that served the corporate SSIDs. The password — Welcome2025 — was printed on a laminated card at the reception desk, visible to anyone standing in the lobby. The password had not been changed since January, based on the card's formatting and the year in the password itself.
We connected from a seat in the reception waiting area.
The initial checks were positive. Internet access worked. Internal DNS resolution was blocked — the guest VLAN used a DNS forwarder that only resolved public domains. These are the checks that most auditors perform, and both passed.
But DNS resolution and network reachability are not the same thing. A guest VLAN can be configured to use public DNS (preventing internal name resolution) whilst still permitting IP-level connectivity to internal subnets. The DNS configuration is a convenience control — it prevents guests from easily finding internal servers. It is not a security control — it does not prevent guests from reaching them if they know the IP address.
We began systematic reachability testing.
We tested connectivity from the guest VLAN to the RFC 1918 private address ranges most commonly used for internal networks. This is a brute-force approach — scanning the common internal ranges for any host that responds to a SYN probe on common service ports.
The scan results were almost clean. The 10.10.0.0/16 range (the corporate network) was completely blocked. The 192.168.0.0/16 range was blocked. Most of the 172.16.0.0/12 range was blocked. Almost is the critical word. One subnet — 172.16.50.0/24 — was reachable from the guest VLAN. Six hosts responded.
A single reachable subnet, in an otherwise well-configured environment, is the kind of finding that validates the purpose of penetration testing over documentation review. The firewall rules document would show the guest VLAN as isolated. The architecture diagram would show no connection. But the network — the actual packets on the actual wire — told a different story.
We enumerated the six responsive hosts on 172.16.50.0/24.
A print services VLAN. A Windows print server and four network printers. This VLAN existed to provide centralised print services to the organisation — and it was reachable from the guest network.
The reason became clear when we examined the firewall rule set later in the engagement with the client's cooperation. The guest network had been granted access to the print VLAN so that visitors could print — a convenience requested by the facilities team to allow guests in meeting rooms to print documents during presentations. A single firewall rule, added two years prior: Guest VLAN → 172.16.50.0/24 — Allow TCP 9100, 631, 80, 443.
The rule permitted printing protocols. It also permitted HTTP, HTTPS, and — critically — it did not restrict traffic to the printers only. The rule permitted access to the entire /24 subnet, including the print server. The print server was a domain-joined Windows Server.
A firewall rule permitting guest access to the print VLAN for visitor printing inadvertently exposed a domain-joined Windows print server (PRINT-SRV01) to the guest network. The rule was scoped to the subnet rather than individual printer IP addresses, and permitted HTTP/HTTPS in addition to print protocols.
PRINT-SRV01 was a Windows Server 2019 machine, domain-joined to corp.local, running IIS for web-based print management and SMB for print share access. The server was accessible from the guest VLAN on ports 80, 443, and 445.
Port 445 — SMB — was the significant finding. SMB access to a domain-joined server from the guest network meant we could attempt authentication against the domain through this server. But first, we examined what was available without authentication.
The print server hosted a ScanToShare folder — a common configuration where multi-function printers deposit scanned documents into a network share for users to retrieve. The share was configured with anonymous read access — no authentication required. This is a configuration often set during printer installation to simplify the scan-to-folder workflow, avoiding the complexity of configuring per-user authentication on the MFP devices.
The folder contained forty-seven documents. HR contracts. Client invoices. A passport scan. Board meeting papers. A draft non-disclosure agreement with a client name visible in the filename. Scanned documents accumulated over recent weeks, never cleaned up, sitting on an anonymously accessible share on a server reachable from the guest wireless network in the reception lobby.
From the guest Wi-Fi password on the laminated card to sensitive corporate documents — without a single credential, a single exploit, or a single line of code.
The anonymous share access provided immediate data exposure. But the print server also offered a path deeper into the network. PRINT-SRV01 was a domain-joined server with SMB accessible from the guest VLAN. This made it a target for credential-based attacks.
We attempted a password spray against the print server's SMB service, targeting a small list of common passwords against domain accounts enumerated through the IPC$ null session.
Two domain accounts compromised via password spray. From the guest wireless network. Through the print server. The print server accepted SMB authentication attempts from the guest VLAN because the firewall rule permitted port 445 as part of the subnet-wide allow rule.
With valid domain credentials, the print server became a pivot point. The server had network connectivity to the corporate VLANs — it needed it to serve print jobs to corporate workstations. Using the compromised credentials, we authenticated to the print server and used it as a relay to access corporate resources that were not directly reachable from the guest VLAN.
From the guest wireless network, through the print server, to the corporate file share. The file share contained the firm's client engagement files, financial records, HR documentation, and management papers. The user l.gardner had read access to the Clients and Projects directories — standard access for a consultant at the firm.
The entire path — guest Wi-Fi password from reception card → guest VLAN → print services VLAN → anonymous scan share → password spray → domain credentials → print server pivot → corporate file share — required no exploits, no malware, and no privileged access. Just a Wi-Fi password, a misconfigured firewall rule, and a shared print VLAN that bridged two networks that should never have been connected.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | Connected to guest Wi-Fi using password displayed at reception | Guest PSK visible to all visitors; not individually credentialled |
| 02 | Systematic reachability scan from guest VLAN to internal ranges | 172.16.50.0/24 (print services) reachable — firewall rule for guest printing |
| 03 | Accessed ScanToShare folder anonymously — 47 sensitive documents | Anonymous read access on scan share; documents never cleaned up |
| 04 | Enumerated 247 domain users via null session on print server | Null session permitted on domain-joined print server from guest VLAN |
| 05 | Password spray via print server SMB — 2 domain accounts compromised | Weak passwords (Summer2025!); SMB accessible from guest VLAN |
| 06 | Pivoted through print server to corporate file share | Print server bridged guest and corporate VLANs; no egress filtering |
Guest network isolation is one of the most frequently claimed and least frequently validated controls in enterprise networking. Organisations state that their guest network is isolated. Their documentation shows it. Their firewall rules intend it. And yet, on a meaningful proportion of our engagements, the isolation is incomplete.
The reasons form a pattern.
The immediate priority is removing the firewall rule that permits guest VLAN access to the print services VLAN. If guest printing is a genuine business requirement, it should be fulfilled with a dedicated printer on the guest VLAN itself — physically or logically separate from the corporate print infrastructure, not domain-joined, not hosting shared folders, and not connected to any corporate network segment. The guest printer prints. It does nothing else.
The ScanToShare folder must be secured immediately. Anonymous access must be removed. Scan-to-folder configurations should require authentication, and the folder should have automated cleanup — documents older than twenty-four hours should be purged. Better still, scan-to-email should replace scan-to-folder wherever possible, eliminating the shared folder as an attack surface entirely.
The guest Wi-Fi credential should not be displayed on a laminated card visible to the public. A captive portal with time-limited, individually issued credentials — provided by reception upon request and valid for the duration of the visit — provides accountability and limits exposure. Each visitor receives a unique credential. When they leave, the credential expires. If a credential is compromised, only one visitor's access is affected.
Automated guest isolation validation is the long-term control. A scheduled test that connects to the guest VLAN and scans for reachability to all internal subnets — run monthly or after any firewall change — would detect the rule that created this vulnerability within days of its creation. The test is simple: from the guest VLAN, can you reach anything that is not the internet? If yes, the isolation has failed.
A guest wireless network is an intentional point of access to your infrastructure for people you do not control. Visitors, contractors, delivery personnel, interviewees, clients — anyone who sits in your reception area and connects to the guest Wi-Fi is a device on your network. Not on your corporate network, if the isolation is working. But on your network nonetheless.
The assumption that guest isolation 'just works' — because the VLAN exists, because the firewall rules were configured once, because the architecture diagram shows a clean boundary — is an assumption that fails quietly and frequently. It fails because shared services bridge the gap. It fails because firewall rules erode over time. It fails because a convenience request from the facilities team — can visitors print? — creates a path that nobody reviews.
We sat in the reception lobby. We used the password on the card. We found a path through a shared printer VLAN. We read board papers and client contracts from an anonymous share. We cracked two domain passwords. We pivoted to the corporate file server. All from the chair where visitors wait for their meeting to start.
Until next time — stay sharp, stay curious, and test your guest isolation from the guest VLAN, not from the architecture diagram. The diagram says it is isolated. The packet capture might disagree.
This article describes a penetration test conducted under formal engagement with full written authorisation from the client. All identifying details have been altered or omitted to preserve client confidentiality. No client data was exfiltrated from the environment. Document sensitivity was assessed by filename and metadata only — document contents were not opened or read beyond confirming the finding. Unauthorised access to computer systems is a criminal offence under the Computer Misuse Act 1990. Do not attempt to replicate these techniques without proper authorisation.
Hedgehog Security tests guest network isolation the way an attacker would — from the guest VLAN, with no credentials, no documentation, and no assumptions. We identify the shared services, the stale firewall rules, and the bridges that connect your guest network to your corporate environment. If your guests can reach more than the internet, we will find out.