Deauth and Rogue AP Against PMF-Capable Clients
A hospital wireless network uses WPA2-Enterprise with 802.11w (PMF) optional, and a separate WPA3-SAE guest SSID with PMF required. You are authorized to test client isolation and rogue-AP detection. You deploy a rogue AP with the same guest SSID and a captive portal to capture credentials. The rogue AP has a stronger signal on channel 36, while the legitimate AP is on channel 149. Some iOS devices associate to the rogue AP, but corporate Windows laptops on the WPA2-Enterprise SSID do not. You also attempt a broadcast deauthentication against the guest SSID to force reassociation, but only a few older Android devices disconnect; iOS devices remain connected. You need to explain the mixed results and adjust the attack to obtain a handshake or captive-portal credential without causing clinical disruption.
1. Why does the broadcast deauth affect only older Android devices? Explain PMF and the role of reason codes.
Read the worked answer
802.11w management frame protection authenticates deauthentication and disassociation frames. On the WPA3 guest SSID PMF is mandatory, so iOS devices negotiate PMF and discard the unprotected broadcast deauth; older Android devices without PMF accept it. Reason code 7 (class 3 frame received from nonassociated station) is common in deauth tools, but the code does not matter to a PMF client, because the frame is simply not authenticated. The Windows laptops are on the WPA2-Enterprise SSID, a different profile, so the guest deauth would not target them anyway. Check the RSN capabilities in beacons/probe responses for MFPC/MFPR bits before choosing deauth.
2. The rogue AP with the same guest SSID captured iOS devices but not Windows laptops. What configuration differences explain this, and how would you adapt?
Read the worked answer
iOS devices often auto-join a known guest SSID and will follow a stronger signal, especially if the rogue AP is on a preferred band/channel. Windows domain laptops usually have a single 802.1X profile for the corporate SSID, with certificate validation and no auto-connect to the guest SSID; they will not associate to an open captive portal. To adapt, target the guest population with the evil twin and a believable portal, and separately assess the corporate SSID with a rogue Enterprise AP using a certificate the client trusts only if you can obtain one; otherwise expect certificate warnings. Do not assume a single rogue AP will capture both populations.
3. Given PMF on the guest SSID, what alternatives remain to capture a WPA3-SAE handshake or force a client to the rogue AP?
Read the worked answer
With PMF required, deauth and disassoc are off the table. Options: (1) operate a rogue AP with the same guest SSID and capture the SAE commit/confirm exchange when a client tries to associate; SAE is offline-dictionary-crackable if the passphrase is weak; (2) use a rogue AP with a stronger signal and wait for natural client steering or roaming; (3) target the WPA2-Enterprise SSID, where PMF may be optional and a rogue EAP server can capture MSCHAPv2 for offline cracking; (4) look for a non-PMF IoT or legacy SSID. Do not use CSA or beacon spoofing against PMF-protected clients without verifying protection; clinical disruption is unacceptable.