PMKID Attack: Crack WPA2 Offline Without a 4-Way Handshake

What the PMKID actually is

The Pairwise Master Key Identifier, or PMKID, is a 16-byte value computed by the access point as a function of the PMK (Pairwise Master Key), the AP's MAC address, and the station's MAC address. The exact formula is HMAC-SHA1(PMK, "PMK Name" || AP_MAC || STA_MAC), truncated to the first 128 bits. It serves a legitimate purpose: it lets a station that has previously authenticated to an access point skip the full 4-way handshake on reconnect by presenting a cached PMKID. Intel, Broadcom, Qualcomm and most consumer-grade SoC vendors include the PMKID in the first message of every 4-way handshake as a matter of convenience, even on first-time associations where no caching is possible.

That inclusion is the entire vulnerability. The PMK, from which the PMKID is derived, is itself the output of PBKDF2-HMAC-SHA1(passphrase, SSID, 4096, 256). An attacker who observes AP_MAC, STA_MAC, SSID and PMKID has everything needed to run a dictionary attack offline: for each candidate passphrase, compute PBKDF2 to get a candidate PMK, compute HMAC-SHA1 to get a candidate PMKID, and compare. The match rate is identical to a 4-way handshake crack, because the PBKDF2 step dominates both workloads.

Why this is better than handshake capture

Both approaches converge on the same hc22000 output format and the same hashcat mode 22000 crack. The PMKID advantage is entirely in the capture phase, which is simpler, more reliable, and does not disturb any user of the network. That is why modern audit workflows in 2026 default to PMKID first and only fall back to full handshake if the target access point strips the PMKID field.

Installing hcxdumptool and hcxtools

hcxdumptool is the capture engine; hcxpcapngtool (shipped in the hcxtools package) converts the resulting pcapng into the hc22000 format that hashcat understands. On Kali 2026 both are in the default repositories.

sudo apt update
sudo apt install hcxdumptool hcxtools
# verify versions
hcxdumptool --version
hcxpcapngtool --version
# recent releases: hcxdumptool 6.3.x, hcxtools 6.3.x

The hcxdumptool binary does everything aircrack-ng would do in three separate tools: it puts the card into monitor mode, scans channels, transmits association requests to every in-range BSSID, and logs whatever the access points reply with. If you prefer manual channel control, pass -c 6 or a comma-separated list of channels; otherwise the tool hops automatically.

Capturing the PMKID

The simplest capture command. Against a vulnerable access point you own, this produces a hc22000-ready pcapng within a minute or two. The --active-beacon flag enables association requests; without it the tool only captures what flies past passively.

# disable interfering services
sudo airmon-ng check kill
# put the interface in monitor mode manually (hcxdumptool prefers this)
sudo ip link set wlan0 down
sudo iw wlan0 set type monitor
sudo ip link set wlan0 up
# run the capture against your own BSSID
sudo hcxdumptool -i wlan0 -o capture.pcapng \
    --active-beacon \
    --filterlist_ap=my-ap.txt \
    --filtermode=2 \
    --enable-status=15
# my-ap.txt contains one line: AABBCCDDEEFF (your router's BSSID, no colons)
# --filtermode=2 means "only scan this BSSID, ignore everyone else"
# --enable-status=15 prints EAPOL and PMKID hits to the console

When the access point sends a PMKID in its response, hcxdumptool prints a line like [INFO] PMKID RECEIVED: aa:bb:cc:dd:ee:ff. At that point you have what you need; Ctrl+C and move on to conversion. If after three minutes you see no PMKID messages, the access point is suppressing the field and you will need to fall back to waiting for a real 4-way handshake from a connected client — the aircrack-ng workflow, or hcxdumptool with different filter modes.

Converting to hc22000

hcxpcapngtool reads the captured pcapng and writes hc22000 lines, one per unique PMKID or handshake. The hc22000 format is the unified successor to the older hccapx format — it handles both PMKID and 4-way handshake in the same file and is the only format hashcat mode 22000 accepts.

hcxpcapngtool -o hash.hc22000 -E wordlist-candidates.txt capture.pcapng
# -o   output hc22000 file
# -E   write extracted ESSID + MAC candidates for targeted cracks
# output lines starting with WPA*02*  = PMKID
# output lines starting with WPA*01*  = full 4-way handshake EAPOL
# example PMKID line:
# WPA*02*a1b2c3d4...*aabbccddeeff*112233445566*4d794e6574776f726b***

The hc22000 line is self-contained: mode identifier, PMKID (or MIC for handshakes), AP MAC, station MAC, ESSID in hex, plus optional fields. If you want to confirm what you captured before burning GPU time, paste the file into our handshake analyzer — it reports whether the file contains a PMKID, a complete handshake, or only an unusable partial.

Cracking with hashcat mode 22000

Mode 22000 covers both PMKID and handshake in a single code path. Speed is identical in both cases because the dominant cost is PBKDF2-HMAC-SHA1. On an RTX 4090 expect roughly 2.5-3.0 million candidates per second; on a CMP 90HX (our rig's GPU) roughly 500-700 k/s. A 14-billion-word wordlist runs for a few days on a single high-end GPU, which is why real workflows rely on smart wordlists and rules rather than raw size.

# basic wordlist + rule attack
hashcat -m 22000 hash.hc22000 rockyou.txt -r rules/OneRuleToRuleThemAll.rule -O
# targeted mask for 10-digit phone number PSKs
hashcat -m 22000 hash.hc22000 -a 3 ?d?d?d?d?d?d?d?d?d?d
# dictionary with ESSID-based mangling (e.g. SSID = StarbucksWiFi5G)
hashcat -m 22000 hash.hc22000 rockyou.txt -r rules/hob064.rule \
    --loopback --outfile found.txt

For a full tutorial on hashcat mode 22000, attack modes and rule files see our hashcat 22000 tutorial. If you do not have a GPU big enough to run serious wordlists, submit the hc22000 file to our recovery service — we run 10 GPUs against a curated 14B+ wordlist and only charge if we find the password.

Vulnerable vs patched access points

Whether an access point emits a PMKID is a firmware decision. A non-exhaustive 2026 survey of consumer routers in our test lab shows the following pattern. Intel AX200/AX210 chipsets running Realtek firmware: consistently emit PMKID. Broadcom BCM43 family in TP-Link Archer series: consistently emit PMKID. MediaTek MT7915 in older D-Link and Tenda models: emit PMKID. Qualcomm QCN9074 in recent Netgear Nighthawk firmware (March 2024 or later): PMKID suppressed. Cisco Meraki enterprise: always suppressed. Aruba Instant On: suppressed since firmware 2.8. Ubiquiti UniFi: configurable per SSID; default varies.

"Suppressed" does not mean "safe". Suppressing the PMKID only forces the attacker to fall back to the handshake capture path, which adds a client dependency but ultimately produces the same crackable hash. The only durable defence is a strong passphrase (20+ random characters) or migration to WPA3, which replaces the PMK-derived handshake with SAE entirely. For the WPA3 side of the story, see our WPA3 vs WPA2 cracking analysis.

Performance economics of PMKID cracking

A serious question that every defender should answer before dismissing PMKID cracking as "too slow to worry about" is: how long does it actually take for a motivated attacker with modest hardware to crack an average consumer Wi-Fi password? The number is uncomfortably small. In 2026, a single RTX 4090 pushes roughly 2.8 million WPA candidate evaluations per second in hashcat mode 22000. An RTX 5090, available since late 2025, pushes closer to 4.5 million. A rented 8-GPU cloud instance for six hours costs about $50 and delivers on the order of 500 billion candidate evaluations. The rockyou.txt wordlist is 14 million entries; with the OneRuleToRuleThemAll rule file that expands to roughly 20 billion variants. Cracking rockyou + OneRule against a captured PMKID on a rented 8-GPU instance takes well under an hour and costs less than a restaurant meal.

Longer wordlists change the arithmetic but not the conclusion. The HashMob.net "Known Passwords" list at 14 billion entries combined with targeted mask attacks for common structures (firstname+year, street name+number, pet name+digits, phone numbers) covers somewhere between 50 and 70 percent of real-world consumer Wi-Fi passwords in our internal recovery statistics. The uncovered 30 to 50 percent are passwords that are genuinely random, either because the ISP printed a strong factory default on the router sticker or because the owner is security-conscious. A user who chose the Wi-Fi password to be something memorable — a child's name, a favourite team, a rental address — almost certainly has their PMKID-derived PMK fall in a crackable set.

The defensive implication is direct: if your passphrase could appear in a list that a human could reasonably construct, assume the PMKID is enough to compromise you. The fix is equally direct: rotate to a 20-character random string from a password manager. That one change lifts the expected crack cost from under $100 of cloud GPU time to astronomical numbers that no attacker will spend on a residential network. Our home network security guide walks through the full hardening checklist.

Detecting PMKID harvesting in practice

PMKID capture is close to silent from the perspective of the victim network. There is no deauth flood, no sustained probe traffic, and the association requests look identical to any random device attempting to connect. Detection therefore depends on either anomalous association patterns (a single MAC trying to associate to many BSSIDs in quick succession, which hcxdumptool does by default) or RF fingerprinting of the attacker's card. Consumer-grade routers almost never log these events; enterprise WIPS sensors can and do, flagging patterns like a station that never completes authentication against 20 different BSSIDs in 60 seconds. Home users cannot realistically detect PMKID harvesting; the defence has to be at the passphrase strength layer rather than the detection layer.

One partial mitigation is to disable PMKID emission on your own router if the firmware exposes it. OpenWrt offers this via the disable_pmksa_caching=1 option in hostapd.conf; some Asus routers expose a "PMKID caching" toggle in advanced wireless settings. Disabling it costs a small amount of roaming performance (every reconnect now runs a full 4-way handshake instead of a cached PMKSA resumption) in exchange for eliminating the PMKID attack surface. For most home users the tradeoff is worth it.

Frequently asked questions