Detecting WPA2 PMKID Capture in Your Wireless Estate

The PMKID attack changed the economics of WPA2 cracking. Where the classic attack needed you to capture a four-way handshake — which meant waiting for (or forcing) a client to connect — the PMKID approach can pull crackable material straight from a vulnerable access point with no client connected at all. For defenders, the lesson is that “no one was connected” is not a defense. This post explains the mechanism in the lab, then focuses on what actually stops it.

How the technique works

When a station associates with a WPA2-PSK access point, the AP can include a PMKID in the first message of the EAPOL handshake. The PMKID is derived from the Pairwise Master Key (PMK), the AP’s MAC (BSSID), and the station’s MAC via a known HMAC-SHA1 construction. Because the PMK is itself derived from the network passphrase and SSID, an attacker who captures the PMKID can mount an offline dictionary/brute-force attack against the passphrase.

The capture is collected with standard wireless tooling and converted to the hashcat mode 22000 format. From there it is a pure offline cracking problem: throughput is bounded by GPU and passphrase strength, with no further interaction with the network. The relevant ATT&CK mappings are T1040 (Network Sniffing) and T1110.002 (Brute Force: Password Cracking).

Why the key hierarchy decides everything

The defence follows from the derivation, so it is worth being precise about what an attacker actually holds after a successful capture.

For WPA2-PSK the Pairwise Master Key is derived from the passphrase with a deliberately slow function:

PMK = PBKDF2-HMAC-SHA1(passphrase, SSID, 4096 iterations, 256 bits)

The PMKID is then a keyed hash over that PMK and the two MAC addresses:

PMKID = HMAC-SHA1-128(PMK, “PMK Name” ‖ AP MAC ‖ station MAC)

Three consequences fall directly out of those two lines, and each is a control:

• The SSID is the salt. Two networks with the same passphrase but different SSIDs produce completely different PMKs. This is why a default or extremely common SSID is a genuine weakness: precomputed tables exist for popular network names, and an attacker who hits one skips the expensive derivation entirely. A distinctive SSID forces per-network work.
• PBKDF2 with 4096 iterations is doing real work. Every candidate passphrase costs thousands of SHA-1 operations before a single comparison. WPA2 guess rates are therefore orders of magnitude below what the same hardware achieves against an unsalted hash — which is precisely why passphrase length translates into security here far more effectively than it does for a fast hash.
• There is no network interaction after capture. Once the PMKID is recorded, the attacker is offline. No rate limiting, no lockout, no alert, no time pressure. Anything you might have done to slow them down had to happen before the capture.

The captured material is converted to hashcat’s mode 22000 (WPA-PBKDF2-PMKID+EAPOL), which consolidated the older 2500 and 16800 modes and handles PMKID and four-way-handshake captures in one format.

What passphrase length actually buys

Because the attack is a pure keyspace search, the size of the space is the control. These are plain combinatorics, not benchmarks — apply whatever guess rate your threat model justifies:

Passphrase	Keyspace
8 characters, lowercase only	26⁸ ≈ 2.1 × 10¹¹
8 characters, mixed alphanumeric	62⁸ ≈ 2.2 × 10¹⁴
12 characters, lowercase only	26¹² ≈ 9.5 × 10¹⁶
4 random words from a 7,776-word list	7,776⁴ ≈ 3.7 × 10¹⁵
5 random words from a 7,776-word list	7,776⁵ ≈ 2.8 × 10¹⁹
20 characters, random alphanumeric	62²⁰ ≈ 7 × 10³⁵

The gap between rows four and five is the useful lesson: one additional random word multiplies the space by roughly 7,776, and it costs the user about six characters of typing. Length bought through randomness scales the defence far faster than complexity rules do, and it produces passphrases people will actually enter on a phone keyboard.

The caveat that matters: this arithmetic only holds if the words are chosen randomly. A human-chosen four-word phrase is not 7,776⁴, because humans pick related words in predictable order, and every serious cracking rule set exploits exactly that. Generate it, do not compose it.

Detection

Wireless attacks are hard to detect from the wire alone, so detection lives in the RF and management-frame layers:

• Wireless IDS / IPS. A WIDS sensor (or your AP vendor’s rogue-AP and anomaly features) can flag deauthentication floods, rogue/evil-twin APs, and abnormal association patterns near your APs.
• Deauth as a signal. While PMKID itself is clientless, real engagements often pair it with deauth attacks to also grab handshakes. A spike in deauthentication frames is a classic, detectable indicator.
• New BSSIDs broadcasting your SSID. An evil-twin AP impersonating your network is a strong tampering signal — monitor for unexpected BSSIDs advertising your ESSID.
• Clients roaming to a BSSID you do not own. This is interception actually happening rather than reconnaissance, and it is the highest-priority wireless alert you can build. It requires a client inventory to be useful, which is the work most WIDS deployments never finish.
• Signal strength that does not match a known AP location. A strong emitter on your ESSID from a direction with no access point in it is worth walking down. Physical location is a discriminator no packet capture provides.

All of these detect an attacker who transmits. None of them detect one who only listens, which is the fundamental asymmetry of wireless defence and the reason the control that matters is cryptographic rather than observational.

Be honest: you cannot detect the capture itself

This deserves stating plainly, because a detection-focused guide that implies otherwise is selling something. A PMKID capture is passive and produces no detectable event. The attacker sends one association request — indistinguishable from any device attempting to join — and reads the AP’s reply. There is no flood, no anomaly, and no log line. Some captures are entirely passive, requiring the attacker to transmit nothing at all.

What you can detect is the noisier behaviour that often accompanies it, and what you can control is the value of a successful capture. Both matter, and they are different arguments:

Signal	What it actually indicates	Confidence
Deauthentication flood	Handshake capture, not PMKID — but the same operator	Medium
Unexpected BSSID advertising your ESSID	Evil twin; a separate and more serious attack	High
Association attempts from unknown MACs	Weak — normal in any public-adjacent space	Low
Persistent unknown device in an RF survey	Someone has parked hardware near the building	High
Client roaming to a rogue BSSID	Active interception in progress	High

Notice that the two high-confidence rows are not PMKID detections at all — they are evil-twin detections. That is the accurate picture. Wireless monitoring is worth deploying, and its value is catching interception and rogue infrastructure, not catching a passive hash capture.

The strategic conclusion follows: stop trying to detect the capture and make it worthless. A 20-character random passphrase or a migration to SAE means an attacker can capture PMKIDs all day with no path to your network. That is a control you can actually verify, unlike a detection for an event that emits nothing.

The WPA3 nuance that undoes the migration

WPA3-SAE genuinely removes this attack. The Dragonfly handshake is a password-authenticated key exchange: an observer cannot derive material that permits an offline guess, so capturing the exchange yields nothing to crack. WPA3 also mandates Protected Management Frames (802.11w), which closes the deauthentication attack used to force handshakes on WPA2.

WPA3-transition mode does not give you this. Transition mode runs SAE and WPA2-PSK concurrently on the same SSID with the same passphrase, so that older clients can still connect. An attacker simply associates as a legacy client, gets the WPA2 path, and captures a PMKID derived from the identical passphrase. The network advertises WPA3 and is exactly as crackable as before.

This is the most common way a WPA3 migration produces no security benefit at all, and it is worth correcting wherever the advice “enable WPA3-transition mode” appears without the caveat. Transition mode is a client-compatibility measure, not a security control. It is the right stepping stone only if you pair it with a passphrase strong enough that the WPA2 path is not worth attacking, and you treat the migration as unfinished until transition mode is off.

Two further honest notes. The Dragonblood research (2019) demonstrated timing and cache side-channel attacks plus downgrade attacks against early SAE implementations; these were addressed in firmware, which makes AP firmware currency part of the control rather than a separate chore. And 802.11r fast roaming is closely related to how PMKIDs became readily obtainable in the first place — if you do not need fast roaming, checking whether it is on is a free reduction in exposure.

Prevention and hardening

• Move to WPA3-SAE. SAE is resistant to the offline dictionary attack that PMKID/handshake cracking depends on. Target WPA3-only; transition mode is a client-compatibility stepping stone that leaves the WPA2 path intact, so treat it as unfinished migration rather than as the fix.
• Enforce long, random passphrases (20+ characters) on any WPA2-PSK network that must remain. This alone defeats realistic cracking.
• Use 802.1X (WPA2/3-Enterprise) for corporate networks so there is no shared PSK to crack at all, and so revoking one person’s access is an account change rather than an estate-wide passphrase rotation.
• Segment guest and IoT SSIDs so a cracked PSK does not expose the core network.
• Enable Protected Management Frames (802.11w) even on WPA2 where clients support it. It removes the deauthentication attack that supplies the other half of this technique.
• Use a distinctive SSID. The SSID is the PBKDF2 salt, so a default or extremely common name is the one case where precomputation helps an attacker.
• Turn off 802.11r fast roaming unless you need it, and keep AP firmware current.

What do you do if you believe a PSK was captured?

Unlike most credential compromises, there is no way to confirm this one — you will never find the capture in a log. The decision is made on suspicion, and the operational cost is what makes people hesitate, so it is worth planning before you need it.

1. Assume the passphrase is compromised from the moment of suspicion. Offline cracking runs for as long as the attacker cares to run it. “We saw them last month” does not mean they failed; it means they have had a month.
2. Estimate your actual exposure honestly. If the passphrase is 20+ random characters, the capture is worthless and rotation is optional. If it is a word and a year, treat it as already broken. This is the moment the keyspace table above stops being academic.
3. Rotate the PSK — and price the rotation first. This is the genuinely hard part. Every device on that SSID needs the new passphrase: laptops, phones, printers, badge readers, HVAC controllers, and whatever was configured by a contractor in 2019 and never documented. Plan it as a change, not an incident action.
4. Rotate in the right order. Stand up the replacement SSID alongside the current one, migrate devices onto it, then retire the old SSID. Changing the passphrase in place at 09:00 on a Monday disconnects the whole estate simultaneously, including the devices you need in order to fix the rest.
5. Use the rotation to fix the class of problem. If you are touching every device anyway, that is the cheapest opportunity you will ever get to move to 802.1X or WPA3-only. Rotating to another weak PSK spends the entire operational cost and buys a repeat of this conversation.
6. Check what the SSID actually reaches. A guest or IoT PSK compromise is contained if the segmentation is real. Verify it rather than assuming it — this is the control that determines whether a cracked passphrase is an inconvenience or an intrusion.

Step 3 is why PSK networks quietly persist long past the point anyone defends them: the rotation cost scales with device count, and it grows every year the decision is deferred. That is the real argument for 802.1X on corporate networks. There is no shared secret to rotate, and revoking one user’s access is an account change rather than an estate-wide event.

Common wireless-defence mistakes

• Treating “no clients connected” as protection. That was true of the classic four-way handshake capture and is exactly what PMKID removed. An empty office at 2 a.m. is a better time to capture, not a worse one.
• Building a detection for the capture. It emits nothing. Effort spent here is effort not spent on the passphrase, which is the control that actually works.
• Enabling WPA3-transition mode and considering the migration done. The WPA2 path remains, on the same passphrase. The network reports WPA3 and is unchanged.
• Complexity rules instead of length. Forcing a symbol and a digit into an eight-character passphrase adds negligible keyspace and guarantees a predictable pattern that rule-based cracking already models.
• A human-composed word phrase. Four words chosen by a person are worth a small fraction of four words chosen randomly, because word association and ordering are predictable.
• A default or extremely common SSID. It is the PBKDF2 salt, and popular names have precomputed tables.
• One PSK across the whole estate. It makes rotation so expensive that it never happens, which converts a recoverable compromise into a permanent one.
• Ignoring 802.11w. Protected Management Frames are available on WPA2 and remove the deauth attack that supplies handshake captures.
• Never surveying the RF environment. An evil twin is detectable and materially worse than a PMKID capture, and it is the thing wireless monitoring is genuinely good at finding.
• Assuming guest-network segmentation works. It is usually asserted and rarely tested, and it is the control that decides whether a cracked guest PSK matters.

Wireless PMKID defence checklist

1. Migrate to WPA3-SAE only; treat transition mode as an unfinished migration, not a fix.
2. Where WPA2-PSK must remain, enforce 20+ random characters or five random words, generated rather than composed.
3. Prefer 802.1X (WPA2/3-Enterprise) on corporate networks so there is no shared secret at all.
4. Enable Protected Management Frames (802.11w) wherever clients support it.
5. Use a distinctive SSID — it is the salt.
6. Disable 802.11r fast roaming unless you need it, and keep AP firmware current.
7. Deploy a wireless IDS and alert on deauth floods and unexpected BSSIDs advertising your ESSID — the evil-twin signals, which are the detectable ones.
8. Segment and verify guest and IoT SSIDs so a cracked PSK is contained by design.
9. Plan the PSK rotation before you need it, as a parallel-SSID migration rather than an in-place change.
10. Run authorized assessments against your own APs to confirm passphrase strength and that WPA3 enforcement is genuinely on.

Items 1 and 2 are the whole defence; the rest reduce exposure and improve what happens afterwards. If you only do one thing, make the passphrase long and random — it is the control that works whether or not you ever detect anything.

Tooling for an authorized lab

Disclosure: Some links below are affiliate links. If you buy through them, darkpwn may earn a commission at no extra cost to you. We only recommend training and tools we actually use in our own lab, and affiliate links never influence editorial coverage.

If you are standing up a legal home lab to study wireless defense, structured training is the safest on-ramp — it gives you authorized targets instead of tempting you toward real networks. Platforms such as TryHackMe and Hack The Box provide guided, authorized wireless and network-security labs. For RF experimentation against hardware you own, a Flipper Zero is a common bench tool.

The takeaway

PMKID proved that “nobody was connected” is not wireless security. But the defense is unglamorous and durable: migrate to WPA3, enforce strong passphrases, watch the RF layer for deauth and evil twins, and prefer 802.1X where you can. Understand the capture; make the crack worthless.

The wider lesson generalises past wireless. When an attack is passive and produces no observable event, detection engineering has nothing to work with, and the only remaining lever is making a successful attack worthless. That is an uncomfortable conclusion for a discipline built on telemetry, and it is the correct one here: no sensor you deploy will see a PMKID leave your access point, while a generated 20-character passphrase makes the question irrelevant for as long as the network exists. Spend the effort where it changes the outcome.

The offline-cracking economics here are the same ones behind Kerberoasting. To turn the RF and management-frame signals above into alerts that hold up, see writing Sigma rules that actually fire. The same bench tooling runs through the hardware cluster — HackRF One for defensive RF awareness, Flipper Zero NFC risk, and the WiFi deauthentication detection guide — or browse the full Hardware Security and Detection Engineering pillars.