The Wireless Guest VLAN That Wasn't
Users report intermittent slowness on the corporate WLAN in a branch office. Surveying the RF environment shows a rogue AP broadcasting the same SSID with a stronger signal in the east wing. Your WLAN uses WPA2-Enterprise with 802.1X against RADIUS, certificate validation is 'optional' on the managed Windows clients, and the guest SSID is on a flat VLAN with a /22 address space shared with the IoT badge readers. DHCP logs show 40 leases issued in the east wing on the guest SSID that never authenticate again, with MAC addresses from a single vendor OUI. Physical walk-through locates the device in a ceiling void accessible from an unlocked telecom closet.
1. Rank the risks this represents and identify which one you act on first.
Read the worked answer
Rank by what is reachable, not by what is loudest.
- Highest: guest VLAN shared with badge readers. A /22 flat segment means anyone on the guest SSID - including the rogue AP's clients - is one hop from physical access control. That is a safety and compliance exposure regardless of the rogue AP.
- Second: certificate validation 'optional'. This is the enabling condition for an evil-twin. With validation off, clients will happily complete an 802.1X exchange with a RADIUS server presenting any certificate, and an attacker who captures the MSCHAPv2 exchange can crack weak credentials offline.
- Third: physical placement in an unlocked closet. It explains the deployment and predicts repeats; it is a fix, not an incident.
Action order Physically secure/remove the device now (10 minutes, no business impact, stops collection), then segment the guest/IoT VLANs, then fix certificate validation via policy. Note that the 40 never-reauthenticating leases with one OUI look like IoT devices onboarding to the rogue SSID - which suggests either a rogue device rollout by a business unit or an attacker harvesting; determine which by matching the OUI and MACs against the asset register before accusing anyone.
2. How do you determine whether credentials were harvested, and what is your response if they were?
Read the worked answer
Work backwards from the authentication logs, not from the users.
- Pull RADIUS/NPS logs for the east wing for the window the rogue AP was up. Look for authentication attempts from client MACs to an unknown NAS/client IP - the rogue's RADIUS would not be your server, but your server will show failures for clients that tried the real SSID and were deauth'd.
- Check for successful authentications from those same users at unusual times or from other sites afterwards - credential reuse is the tell.
- Assume MSCHAPv2 exchange capture if clients did associate; with certificate validation optional and PEAP, an offline crack of a weak password is realistic.
If harvest is indicated Force password reset for all users whose MACs appear in the window, prioritising anyone with privileged AD groups, and do it before the analysis is complete - the reset is cheap and reversible, the wait is not. Then re-issue machine certificates, enforce server certificate validation on the supplicant profile, and add EAP-TLS with certificate-based auth so a stolen password alone no longer authenticates.
Judgement Do not wait for proof of cracking before resetting. With optional validation, the probability that credentials were exposed is high enough that the reset cost is justified by expected loss alone.