The WPA2 PMKID Attack: A Faster Way to Test WiFi Security

Until 2018, cracking a WPA2 password required capturing a 4-way handshake - which meant waiting for a client to connect, or sending deauth frames to force a reconnection. You needed both the AP and an active client in range.

Then Jens Steube (the author of hashcat) discovered that a specific value embedded in the first EAPOL Key frame of the 4-way handshake - the PMKID - could be used to attempt password cracking directly, without needing a complete handshake capture, and without needing a client device to be present at all. You just need to exchange one frame with the AP itself.

This changed the practical approach to WPA2 security testing. Here's how the PMKID attack works mathematically, what it means for network security, and how it fits into a security audit workflow.

graph TD
    subgraph "PMKID Derivation Chain"
        PASS["Network Password
(passphrase)"] --> PBKDF2["PBKDF2-HMAC-SHA1
4096 iterations"]
        SSID["SSID
(network name)"] --> PBKDF2
        PBKDF2 --> PMK["PMK
(256-bit key)"]
        PMK --> HMAC["HMAC-SHA1-128"]
        LABEL["Literal string:
PMK Name"] --> HMAC
        APMAC["AP MAC Address
(BSSID, 6 bytes)"] --> HMAC
        CLIMAC["Client MAC Address
(6 bytes)"] --> HMAC
        HMAC --> PMKID["PMKID
(128-bit identifier)"]
    end

    subgraph "Attack Process"
        PMKID --> COMPARE{"Compare against
candidate PMKIDs"}
        DICT["Wordlist / Dictionary"] --> CANDIDATE["Generate candidate
PMK per word"]
        CANDIDATE --> CALCPMKID["Calculate candidate
PMKID"]
        CALCPMKID --> COMPARE
        COMPARE -->|Match| CRACKED["Password Found"]
        COMPARE -->|No match| NEXT["Try next word"]
        NEXT --> CANDIDATE
    end

PMKID derivation from password through PBKDF2 and HMAC-SHA1, and the offline cracking process using dictionary candidates

What Is a PMKID?

PMKID stands for Pairwise Master Key Identifier. It's a 128-bit value derived from the PMK (Pairwise Master Key) and used by the AP to identify which security association applies to a given client.

sequenceDiagram
    participant ATK as Attacker
    participant AP as Access Point
    participant CLI as Client Device

    rect rgb(40, 40, 40)
    Note over ATK,CLI: Traditional 4-Way Handshake Attack
    ATK->>CLI: Deauth frame (force disconnect)
    CLI->>AP: Authentication Request
    AP->>CLI: EAPOL Message 1 (ANonce)
    CLI->>AP: EAPOL Message 2 (SNonce + MIC)
    AP->>CLI: EAPOL Message 3 (GTK + MIC)
    CLI->>AP: EAPOL Message 4 (ACK)
    ATK-->>ATK: Capture all 4 frames
    ATK-->>ATK: Offline dictionary attack
    end

    rect rgb(30, 50, 30)
    Note over ATK,AP: PMKID Attack (No Client Needed)
    ATK->>AP: Association Request
    AP->>ATK: EAPOL Message 1 (ANonce + RSNE with PMKID)
    ATK-->>ATK: Extract PMKID from RSNE
    ATK-->>ATK: Offline dictionary attack on PMKID
    end

Comparison: Traditional handshake capture requires a client and 4 frames - PMKID extraction needs only 1 frame from the AP, no client required

The PMKID is calculated using HMAC-SHA1:

PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AP_MAC || Client_MAC)

Where:

• PMK is derived from the network password: PMK = PBKDF2-HMAC-SHA1(password, SSID, 4096, 32)
• "PMK Name" is the literal ASCII string "PMK Name"
• AP_MAC is the AP's BSSID (6 bytes)
• Client_MAC is the client's MAC address (6 bytes)

The AP includes this PMKID in the RSNE (RSN Element) of the first EAPOL Key frame it sends to a connecting client. This first frame (EAPOL Message 1) is transmitted by the AP to initiate the 4-way handshake.

The Traditional Handshake Capture Attack

For context, the traditional WPA2 password cracking approach:

1. Put a WiFi adapter into monitor mode on the AP's channel
2. Wait for a client to connect, or send deauth frames to force reconnection
3. Capture all four EAPOL frames of the 4-way handshake (Messages 1, 2, 3, 4)
4. Extract the capture and run offline dictionary/brute-force attacks

The vulnerability: the 4-way handshake contains enough information to verify password guesses offline. Specifically, the MIC (Message Integrity Code) in Message 2 is computed using the PTK, which is derived from the PMK, which is derived from the password. An attacker tries each password candidate, derives the PTK, computes what the MIC should be, and compares it to the captured MIC.

The requirement for a connected client is the primary limitation. If no clients are actively using the network, you're waiting or actively disrupting to force a handshake.

How the PMKID Attack Works

The PMKID attack eliminates the client requirement. Here's why:

The PMKID is embedded in EAPOL Message 1, which is sent by the AP when any client initiates a handshake. The attack involves:

1. Sending a minimal association request to the target AP
2. Receiving EAPOL Message 1 from the AP (which contains the PMKID)
3. Extracting the PMKID
4. Running offline cracking against it

Why does this work for cracking? Look at the PMKID formula again:

PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AP_MAC || Client_MAC)

The AP_MAC and Client_MAC are known (you can see them in the frame exchange). The literal string "PMK Name" is constant. The only unknown is the PMK - which is derived directly from the network password and SSID.

So for each password candidate, you can compute:

1. PMK = PBKDF2-HMAC-SHA1(candidate_password, SSID, 4096, 32)
2. PMKID_candidate = HMAC-SHA1-128(PMK, "PMK Name" || AP_MAC || Client_MAC)
3. Compare PMKID_candidate to the captured PMKID

If they match, you've found the password. The entire cracking computation can happen offline at whatever speed your hardware supports.

PMKID vs Traditional Handshake: Speed and Practicality

The cracking speed for PMKID attacks is the same as for traditional handshake attacks - both ultimately reduce to testing password candidates against a derived key. The improvement is in the capture phase, not the cracking phase.

Traditional capture requires:

• A connected client device in range
• Waiting for a natural connection or forcing one via deauth
• Successful capture of all 4 EAPOL frames
• Verification that the capture is complete and valid

PMKID capture requires:

• The AP to be in range
• One brief exchange (send association request, receive EAPOL Message 1)
• Extract the PMKID from the received frame

No clients needed. No deauth needed. Just walk past an AP, initiate a brief exchange, grab the PMKID, and walk away. The cracking happens later, offline, with no further interaction with the target.

Tools: hcxdumptool and hashcat

The standard toolchain for PMKID attacks on Linux:

hcxdumptool handles the frame capture. It puts the adapter into a mode that requests EAPOL handshake exchanges from nearby APs and saves the PMKIDs. The tool cycles through nearby APs and extracts PMKIDs from each.

hcxtools converts the hcxdumptool capture file to hashcat format (hcxpcapngtool -o hash.22000 capture.pcapng). The output is a hash file in hashcat's mode 22000 format, which handles both PMKID and traditional handshake hashes.

hashcat does the actual cracking. A modern GPU cracking rig can test hundreds of millions to billions of WPA2/PMKID candidates per second, depending on hardware. A single high-end GPU (RTX 4090) benchmarks at around 1.6 million hashes per second for WPA2/PMKID due to the expensive PBKDF2 key derivation. Dictionary attacks with common password lists complete in minutes to hours depending on wordlist size.

PBKDF2 Is the Defense

The reason WPA2 cracking is slow (relative to MD5 or SHA1 cracking) is PBKDF2 with 4096 iterations. PBKDF2 is a key stretching function - it deliberately makes password-to-key derivation computationally expensive. The 4096 iterations mean each password candidate requires 4096 SHA1 computations.

On a GPU that can compute 100+ billion MD5 hashes per second, PBKDF2-HMAC-SHA1 x 4096 drops that to around 1-2 million WPA2 candidates per second. Still fast enough to crack short or common passwords quickly, but significantly slower than raw hash cracking.

The practical implication: WPA2/WPA3 password strength matters more than people think. "Password123" or any word from a dictionary is recoverable in seconds. A random 12-character alphanumeric password at 1.6 million attempts per second would require: 62^12 / 1.6M / 3.15e7 seconds/year = approximately 195 million years to brute force exhaustively. Passwords at that length and randomness are not practical to crack.

The attacks that work are dictionary attacks and rule-based attacks against common patterns. "Company2024!", "Summer@2025", "Wifi#Home" - these are recoverable. Pure random strings at sufficient length are not.

Does the PMKID Attack Work on WPA3?

Not in the same way. WPA3-Personal uses SAE (Simultaneous Authentication of Equals) instead of the PSK-based 4-way handshake. The PMK in WPA3 is derived from the SAE exchange, which is an interactive protocol - an offline attacker can't replay the SAE exchange to test passwords without actually talking to the AP in real time, for each candidate.

WPA3 was specifically designed to be resistant to offline dictionary attacks. The PMKID attack is a WPA2-specific vulnerability (or more precisely, it's a property of the WPA2 PSK derivation that enables offline attacks).

Networks in WPA3 Transition Mode (supporting both WPA2 and WPA3) may still yield a PMKID if a WPA2 association is initiated. The AP's response to a WPA2 handshake initiation includes a PMKID. So transition-mode networks are potentially still vulnerable to PMKID attacks from the WPA2 code path.

Network Security Implications

The PMKID attack changes the threat model for WPA2 networks in a few ways:

Passive wardriving becomes more actionable. An attacker driving through a neighborhood can collect PMKIDs from every WPA2 AP without interacting with any clients. They don't disrupt any connections. They just send brief association frames and collect. The cracking happens later at home with a GPU.

No disruption signature. Traditional handshake capture via deauth shows up as deauthentication frames in wireless IDS systems. PMKID capture via association request looks like a normal failed connection attempt - something that happens all the time from devices that have the wrong password. It's much harder to distinguish PMKID collection from legitimate connection attempts.

The defense is the same. A strong random password defeats both traditional handshake cracking and PMKID attacks. WPA3 eliminates the offline attack surface. PMF doesn't help against PMKID collection - PMF protects management frames after association, not the EAPOL exchange itself.

BLEShark Nano and Handshake Capture

The BLEShark Nano captures EAPOL frames in monitor mode and saves them as .pcap files. These captures can include PMKID-containing EAPOL Message 1 frames. Downloaded via the file portal, these .pcap files are compatible with hcxtools and hashcat for offline analysis.

For authorized wireless security audits, this workflow lets you test the crackability of network passwords without needing to wait for a client to reconnect:

1. Enable promiscuous/capture mode on the BLEShark on the target AP's channel
2. The capture collects EAPOL frames including any PMKID-bearing Message 1 frames
3. Download the .pcap via file portal
4. Convert with hcxtools, crack with hashcat and a wordlist
5. Report whether the network password is in common wordlists or follows crackable patterns

This is a standard component of a wireless security assessment. The result tells you objectively whether your WPA2 password is strong enough to withstand offline attack.

EU note: Handshake capture on the BLEShark Nano in EU firmware is passive-listen only. The firmware does not send deauth frames to trigger reconnections. PMKID collection via association request initiation behavior depends on firmware version.

Get BLEShark Nano - $36.99+

PMKID capture and WPA2 password testing should only be performed on networks you own or have explicit written authorization to test. Unauthorized access to computer networks is illegal in most jurisdictions regardless of method.