Hidden SSIDs are one of those security measures that feel effective but provide almost no real protection against a determined attacker. Here’s why — and exactly how they’re defeated.
Why Hidden SSIDs Exist (and Why They Don’t Help)
When a network administrator hides an SSID, the access point stops broadcasting its name in beacon frames. The SSID field is zeroed out. The idea is that potential attackers won’t know the network exists.
The problem: the SSID still appears in probe request and probe response frames. Any client that has previously connected to the network will actively probe for it, broadcasting the SSID into the air every time it looks for known networks.
Monitor mode is all you need to see it.
Step 1: Capturing the SSID Passively
| |
Hidden networks appear as <length: N> in airodump-ng output — the N tells you how many characters the SSID contains. Wait for a client to probe, and the SSID appears in the STATION section.
Step 2: Forcing the Reveal Actively
If no clients are actively probing, you can send a deauthentication frame to force a reconnect:
| |
When the client reconnects, its probe request contains the SSID in plaintext.
Step 3: Revealing with Scapy
For a more controlled approach:
| |
Step 4: Cracking the Password
Once you have the SSID, the attack surface is identical to any other WPA2 network. Capture the 4-way handshake or PMKID:
| |
The Bottom Line
Hidden SSIDs provide security through obscurity — and obscurity isn’t security. The SSID is always revealed in probe frames. Any client on the network will hand it to a passive observer.
If you’re relying on hidden SSIDs to protect a sensitive network segment, replace that with network segmentation, strong WPA3 passphrases, and certificate-based authentication.