WLAN Threats - Attack Reference
802.11 protocol design decisions from 1997 created attack surfaces that took decades to close. Understanding these threats at the protocol level - not just as tool names - is the difference between configuring against them and understanding why the configuration works.
Every 802.11 attack exploits a design decision made in 1997. Most work because management frames were never required to be authenticated until 802.11w in 2009. Knowing which protocol gap each attack targets is how you configure against it rather than just naming it.
wlan.fc.type_subtype == 0x0cDeauth frames. Burst from spoofed BSSID = deauth flood attack.eapol && eapol.keydes.type == 2EAPOL-Key frames - PMKID in M1. Capture even one to run hashcat mode 22000.wlan.bssid != aa:bb:cc:00:00:00 && wlan_mgt.ssid == "TargetSSID"Same SSID, different BSSID = possible evil twin. Substitute real BSSID.wlan.fc.type_subtype == 0x0b && wlan.fixed.auth.alg == 3SAE commit frames. High rate without confirm = Dragonblood commit flood.wlan.fc.type_subtype == 0x08Beacons. Sequential different BSSIDs at rapid rate = beacon flood (MDK4).wlan.fc.retry == 1 && eapolRetransmitted EAPOL frames. M3 retry = potential KRACK nonce-reuse attempt.Evil Twin / Rogue AP
Hostapd + dnsmasq creates a rogue AP matching target SSID. MDK4 deauths clients from legitimate AP. Clients auto-associate to evil twin. HTTP intercepted via SSLstrip. HTTPS requires separate cert downgrade or HSTS bypass.
Client associates to AP with same SSID but different BSSID MAC OUI. Beacon interval or capability mismatch vs legitimate AP. Wireshark: two Beacon streams from different BSSIDs with identical SSID.
wlan.bssid != aa:bb:cc:dd:ee:ff && wlan.ssid == "TargetSSID" Deauth / Disassoc Flood
aireplay-ng --deauth or MDK3/MDK4 broadcast deauth. Attacker spoofs AP BSSID (src) and FF:FF:FF:FF:FF:FF or specific STA (dst). Without PMF, AP and STA accept unsigned management frames. Clients immediately disconnect and retry.
High rate of Deauth frames (FC subtype 12) from AP BSSID to broadcast or specific STA. Reason Code 3 = leaving BSS. MDK4 signature: sequential Deauth bursts at precise intervals.
wlan.fc.type_subtype == 12 PMKID Attack
PMKID = HMAC-SHA1-128(PMK, "PMK Name" || BSSID || Client MAC). PMK = PBKDF2-SHA1(passphrase, SSID, 4096). Attacker sends EAPOL M1 without completing auth. hcxdumptool captures PMKID from a single frame. hashcat mode 22000 attacks at billions of hashes/sec on GPU.
EAPOL-Key M1 (Key Info: ACK=1, Pairwise=1) from AP to client, then no M2 response (attacker disconnects). PMKID is in EAPOL Key Data of M1.
eapol && eapol.keydes.type == 2 KRACK (Key Reinstallation)
Attacker sits between STA and AP (channel-based MitM). Replays M3 - client reinstalls already-used PTK, resetting Packet Number (PN) to 0. CCMP: nonce reuse recovers keystream via XOR. TKIP: worse - authentication key also recoverable. GCMP: nonce reuse leaks authentication key entirely.
Duplicate EAPOL M3 frames (same content, same sequence) from AP. Client PN reset to 0 visible in subsequent encrypted data frames (PN counter goes backward).
eapol && wlan.fc.retry == 1 Dragonblood (WPA3-SAE)
H&P loop iterations vary based on password bits → timing differences reveal password bits. Cache side-channel via flush+reload on shared system. DoS: attacker sends SAE commit frames without completing exchange → exhausts AP state table (before anti-clogging tokens).
High rate of SAE commit frames (Auth Algorithm=3, Seq=1) without corresponding confirms. Anti-clogging token response changes the Auth frame body structure.
wlan.fc.type_subtype == 11 && wlan.fixed.auth.alg == 3 KARMA Attack
Devices probe for remembered SSIDs using directed Probe Requests. Karma-enabled AP (hostapd-wpe) responds to all probes with matching SSID. Devices auto-associate. Combined with PEAP credential harvesting (hostapd-wpe captures inner MSCHAPv2 credentials).
Rogue AP responds to directed probes for multiple different SSIDs - a legitimate AP only responds to its configured SSIDs. Probe response BSSID does not match any known infrastructure AP.
wlan.fc.type_subtype == 5 Beacon Flood
MDK3/MDK4 --beacon-flood or mdk4 b mode generates Beacon frames at high rate with randomised BSSIDs and SSIDs. Fills client Preferred Network Lists. Some clients crash or exhibit high CPU due to scan list overflow. Can be used as cover for evil twin deployment.
Beacon bursts from many unique BSSIDs in rapid succession. OUI range may be sequential or random (locally administered bit set in MAC = random). Very short intervals between beacons from the same BSSID.
wlan.fc.type_subtype == 8 Rogue DHCP + DNS Spoofing
Race condition: attacker DHCP server responds faster than legitimate DHCP. Options 3 (gateway) and 6 (DNS) point to attacker. dnsmasq on rogue AP handles DNS queries and returns forged A records. SSLstrip or custom forged pages served at resolved IPs.
Multiple DHCP Offer frames from different source MACs for the same DHCPDISCOVER. Client selects first offer received. Compare DHCP option 6 (DNS) against known infrastructure IP ranges.
bootp.option.dhcp == 2 EAPOL Silence Attack
Selective jamming of EAPOL M3 from AP forces client to time out and retry, producing additional M1/M2 pairs containing different SNonces. Multiple SNonce captures enable cryptanalysis. Also used to force downgrade from WPA3 to WPA2 on transition-mode networks.
Multiple EAPOL M1→M2 pairs from same STA+BSSID without M3→M4 completion. High retry rate on EAPOL frames. Look for pattern: M1, M2, M1(retry), M2(retry) repeating.
eapol && eapol.keydes.key_info.key_ack == 1