Reconnaissance and Target Enumeration
Passive vs. Active Discovery
The first decision in wireless reconnaissance is whether to listen silently or probe the environment. Passive discovery places the adapter in monitor mode and records every 802.11 frame on a tuned channel. This leaves no radio footprint—no association requests, no probe requests with your MAC address, no telltale burst pattern that a WIDS might flag. The trade-off is time: you capture only what the infrastructure and clients transmit organically. On quiet channels, you may wait minutes for a beacon burst or client probe.
Active discovery sends directed or broadcast probe requests, triggering AP responses and accelerating SSID resolution. It also paints a target on your radio. Enterprise WIDS signatures routinely flag rapid channel-hopping probe floods, and some countermeasures (AP-based radio resource management, dynamic channel selection) will alter the target environment in response. For authorized defensive assessment, active discovery belongs in controlled lab windows; for production baseline enumeration, passive collection over extended windows yields cleaner data.
What it does: Captures all 802.11 traffic on a specified channel without joining any BSS. When to use it: Baseline topology mapping, stealth assessment, or when you need frame sequences for troubleshooting association failures. Risks: Channel-hopping without discipline fragments capture; clients may be on a channel you miss for minutes. Expected output: Raw 802.11 frames with radiotap headers including signal strength, channel, and data rate metadata.
# Lab: Set interface to monitor mode, fix channel to avoid hopping gaps
sudo ip link set wlan0 down
sudo iw wlan0 set monitor none
sudo ip link set wlan0 up
sudo iw wlan0 set channel 36 HT20
# Verify mode and channel
iw dev wlan0 info
Production variant: Use shorter capture windows (5–10 minutes per channel) with scripted channel rotation rather than continuous manual hopping. Log channel dwell times to correlate with missed traffic later.
802.11 Frame Types: A Field Reference
The Frame Control field's Type and Subtype bits determine everything about a frame's security relevance. Wireshark display filters build directly on these classifications.
| Frame Type | Subtype Examples | Security Relevance | Key Display Filter |
|---|---|---|---|
| Management (0) | Beacon, Probe Request/Response, Authentication, Association Request/Response, Deauthentication, Disassociation | BSS topology, capabilities, client enumeration, attack surface for spoofing | wlan.fc.type == 0 |
| Control (1) | RTS, CTS, ACK, Block ACK | Medium reservation, hidden node mitigation; rarely contains security data directly | wlan.fc.type == 1 |
| Data (2) | Data, Null, QoS Data, Data+CF-Ack | Encapsulated upper-layer traffic; protection status reveals WPA2/WPA3 vs. open | wlan.fc.type == 2 |
| Extension (3) | Reserved/uncommon | Not typically encountered in standard reconnaissance | wlan.fc.type == 3 |
Critical subtypes for reconnaissance:
| Subtype | Decimal Value | Filter | What It Reveals |
|---|---|---|---|
| Beacon | 8 | wlan.fc.subtype == 8 |
AP capabilities, SSID (or blank for hidden), RSN IE, 802.11w support, channel, rates |
| Probe Request | 4 | wlan.fc.subtype == 4 |
Client-desired SSIDs (directed) or wildcard (broadcast); reveals roaming targets |
| Probe Response | 5 | wlan.fc.subtype == 5 |
AP response to probe; comparable data to beacon but triggered |
| Authentication | 11 | wlan.fc.subtype == 11 |
Authentication sequence numbers; algorithm type (Open System vs. SAE) |
| Association Request | 0 | wlan.fc.subtype == 0 |
Client capabilities, supported rates, RSN IE from client perspective |
Hard-won insight: A "hidden SSID" AP does not omit its beacon—it sends beacon frames with an empty SSID element (
length 0). The SSID leaks in probe responses to legitimate clients and in association request frames from those clients. A passive capture over time almost always recovers the name without active probing.
Hidden SSID Discovery and Client Enumeration
Capturing the SSID leak:
# Capture beacons and directed traffic on target channel
sudo tcpdump -i wlan0 -w hidden_ssid.pcap -e -s 0 \
'type mgt and (subtype beacon or subtype assoc-req or subtype reassoc-req or subtype probe-resp)'
Wireshark display filters for post-capture analysis:
# Isolate AP with blank SSID in beacons but SSID elsewhere
wlan.fc.subtype == 8 && !(wlan.ssid) && wlan.bssid == 00:11:22:33:44:55
# Then search for same BSSID with non-empty SSID in other frames
wlan.bssid == 00:11:22:33:44:55 && wlan.ssid
Client enumeration from probe requests—clients reveal preferred networks and sometimes themselves:
# All probe requests (broadcast and directed)
wlan.fc.type == 0 && wlan.fc.subtype == 4
# Group by SSID being probed for—reveals client roaming history
tshark -r capture.pcap -Y 'wlan.fc.subtype == 4' -T fields \
-e wlan.sa -e wlan.ssid | sort | uniq -c | sort -rn
Sample output interpretation:
42 6a:3c:4f:12:89:ab CorpWiFi
17 6a:3c:4f:12:89:ab GuestNet
9 6a:3c:4f:12:89:ab [EMPTY: broadcast probe]
Client 6a:3c:4f:12:89:ab has associated with CorpWiFi previously; the broadcast probe suggests it failed to find a preferred network and fell back to wildcard discovery. The MAC prefix may be randomized (see below).
RSN Information Elements: Reading Protection Status
The RSN IE in beacons and probe responses encodes the difference between WPA2-PSK, WPA2-Enterprise, WPA3-SAE, and whether management frame protection (802.11w) is required or optional.
Wireshark filters for capability parsing:
# Networks with any RSN IE present (not WEP, not open)
wlan.rsn
# 802.11w mandatory (MFP required)
wlan.rsn.capabilities.mfpr == 1
# 802.11w optional (MFP capable but not enforced)
wlan.rsn.capabilities.mfpc == 1 && wlan.rsn.capabilities.mfpr == 0
# WPA3-SAE (Authentication Key Management suite selector 00-0F-AC:8)
wlan.rsn.akms.suites == 00-0f-ac:08
| RSN IE Field Position | Meaning for Assessment |
|---|---|
| Group Cipher Suite | Broadcast/multicast encryption: typically CCMP (00-0F-AC:4) or GCMP-256 for WPA3-Enterprise |
| Pairwise Cipher Suite Count | Usually 1; multiple entries suggest transition mode or misconfiguration |
| AKM Suite List | PSK (00-0F-AC:2), 802.1X (00-0F-AC:1), SAE (00-0F-AC:8), FT-SAE (00-0F-AC:9) |
| RSN Capabilities bits 6-7 | MFPC (bit 6: capable), MFPR (bit 7: required)—together define 802.11w posture |
What it does: The
wlan.rsnfilter isolates modern protected networks; combining with AKM suite selectors identifies WPA3 vs. legacy transition modes. When to use it: Prioritizing assessment targets by hardening level, or detecting downgrade-capable networks. Risks: Misreading "capable" as "enforced" leaves false confidence; always check MFPR.
MAC Address Randomization: Tracking Impact
Modern clients randomize MAC addresses in probe requests to prevent tracking. This breaks naive client enumeration by source MAC but not all correlation methods.
Detecting randomization patterns:
| Indicator | Technique | Limitation |
|---|---|---|
| Locally administered bit (U/L = 1 in first octet) | wlan.sa[0] & 0x02 == 0x02 |
Not all random MACs set this; some implementations use globally unique ranges |
| OUI mismatch | wlan.sa[0:3] != wlan.tag.oui in vendor-specific IEs |
Rarely present in probe requests |
| Sequence number gaps | wlan.seq jumps without rollover pattern |
Stateful tracking across probe bursts; fails if client goes silent |
| Timing/fingerprinting | Inter-probe interval, supported rates, IE ordering | Heuristic; requires training data |
When randomization is active, pivot enumeration to behavioral correlation: SSID probe lists, 802.11 capabilities (HT/VHE capabilities, extended capabilities bitmap), and vendor-specific IEs. A client probing the same five SSIDs across multiple random MACs is still one client for threat modeling purposes.
Spectrum Analysis and Non-WiFi Interference
Not all radios speak 802.11. Bluetooth, Zigbee, proprietary FHSS, cordless phones, and microwave ovens occupy the 2.4 GHz band; LTE-U and radar systems encroach on 5 GHz DFS channels. Software-defined radio tools (hackrf, rtl-sdr) or dedicated spectrum analyzers (Wi-Spy, Oscium WiPry) reveal energy the 802.11 stack discards as unparseable noise.
Practical correlation:
| Symptom in 802.11 Capture | Likely Interferer | Confirmation |
|---|---|---|
| High retry rate, low RSSI, clean spectrum on other channels | Co-channel interference from dense AP deployment | Channel utilization in beacon quiet elements |
| Periodic spikes in noise floor, ~15–20 second cycle | Microwave oven in 2.4 GHz | Spectrum waterfall shows broad 20 MHz burst |
| Complete deafness on specific 5 GHz channel with radar pattern | DFS radar detection (meteorological, military) | Channel switch announcement frame in capture; check regulatory domain |
| Narrow, frequency-hopping energy bursts | Bluetooth Classic or BLE | SDR waterfall shows 1 MHz hops; 802.11 capture shows only elevated noise floor |
Hard-won insight: A WiFi adapter in monitor mode cannot report what it cannot decode. Before blaming "poor WiFi coverage," always rule out non-WiFi interferers with spectrum visualization—especially in industrial environments where proprietary 2.4 GHz telemetry coexists with enterprise WLANs.
Enterprise Topology Inference
Enterprise deployments leak structure through beacon and probe patterns:
- Multiple BSSID sets with identical SSID and sequential MACs: Indicates controller-based architecture with virtual APs on dedicated radios or interfaces. The gap between MACs suggests vendor allocation block size.
- Identical beacon intervals but varying DTIM periods: Different power-save or multicast delivery policies per AP role (indoor vs. outdoor, voice-optimized vs. best-effort).
- Probe response timing variance: APs with identical SSID but disparate response latency may be on different controller groups or WAN-connected remote APs.
- 802.11k/v/r neighbor reports in beacons: Reveals planned roaming topology—adjacent channels and BSSID targets the infrastructure wants clients to prefer.
Wireshark filter for neighbor report elements:
wlan.tag.number == 52 # Neighbor Report element
wlan.tag.number == 69 # Fine Timing Measurement Parameters (802.11mc)
Wardriving Database Correlation
Collected BSSIDs, SSIDs, and geolocation data can be correlated with public databases. WiGLE.net provides the largest open aggregation; its API permits bulk lookup for infrastructure change detection.
Ethical boundary: WiGLE data is crowdsourced. Correlating your own authorized environment against historical records is defensive; bulk querying to map third-party targets is not.
Lab: WiGLE API correlation for owned infrastructure
# Query WiGLE for a single BSSID known to belong to your organization
curl -s -u "WiGLE_USER:WiGLE_API_KEY" \
"https://api.wigle.net/api/v2/network/detail?netid=00:11:22:33:44:55" \
| jq '.results[] | {ssid, trilat, trilong, lastupdt}'
Production variant: Export BSSID list from NMS/WLC, batch-query nightly via API with rate limiting (WiGLE permits 100 queries/minute for registered users), flag newly exposed or relocated APs.
What it does: Identifies whether authorized APs have been geolocated and logged by third-party wardrivers—useful for rogue AP detection and physical security assessment. When to use it: Periodic infrastructure audit, post-merger integration, or after physical site changes. Risks: API rate limits; stale data (last seen dates may be months old); false positives from MAC reuse in recycled hardware.
Common Mistakes in Reconnaissance Capture
| Mistake | Why it bites you |
|---|---|
| Capturing in managed mode instead of monitor mode | You see only your own traffic and broadcast/multicast on joined BSS; miss beacons from other ESSs, direct client-to-client frames, and deauth floods |
| Forgetting to lock channel or hopping too fast | Fragments handshake sequences across files; Wireshark cannot reassemble or follow streams split by channel change |
| Ignoring 802.11 radiotap header fields | FCS errors, bad PLCP, or non-data frames with garbage payload appear as "malformed" unless you filter wlan_radio.fcs_bad == 0 |
| Trusting SSID string as unique identifier | Multiple ESSs can share an SSID; BSSID is the reliable key. SSID collision attacks deliberately exploit this confusion |
| Overlooking 6 GHz / Wi-Fi 6E captures | Requires 6 GHz-capable hardware and often different regulatory activation; silent on 2.4/5 GHz-only tools |
Checklist: Baseline Reconnaissance Workflow
- [ ] Verify adapter monitor mode support and driver stability under load
- [ ] Document channel plan for regulatory domain; note DFS channels requiring radar detection
- [ ] Capture minimum 5 minutes per channel, or one full beacon interval × dwell factor
- [ ] Log capture metadata: adapter type, driver version, antenna configuration, physical location
- [ ] Post-process: extract unique BSSIDs, SSIDs, AKM suites, 802.11w status, client MAC randomization indicators
- [ ] Cross-reference against authorized infrastructure inventory; flag unknown BSSIDs for rogue AP triage
- [ ] Archive raw PCAP with retention matching incident response policy; derive summary CSV for trending