On one office assessment we never went inside the building. We sat in the parking lot, pulled a PMKID off the guest SSID, cracked the key over lunch, joined the guest network, and discovered the guest and corporate VLANs were not actually separated. A weak Wi-Fi password had quietly handed us internal network access from a car. Range, not a network jack, is the scope of a wireless test, and a single guessable key or an unvalidated 802.1X certificate can undo every firewall you own.
This guide walks the wireless pentest workflow with the real tool output you would see: discovery, PMKID capture, cracking, WPA3 transition-mode testing, and Evil Twin credential harvesting, then the config-level fixes. It sits alongside our network penetration testing overview and the internal network penetration testing guide that picks up once you are on the LAN.
Wireless penetration testing is an authorized assessment of Wi-Fi networks and the clients that use them, aimed at finding weaknesses an attacker could exploit from radio range. That includes the encryption protecting each SSID, the strength of pre-shared keys, the configuration of enterprise 802.1X, and whether users can be lured onto rogue access points.
Unlike a wired test, range is the scope. A tester maps which networks are reachable from public areas, checks guest and corporate SSID separation, and confirms whether a wireless foothold reaches the internal network or stays sandboxed. The deliverable is usually a mix of crackable keys, missing client protections, and segmentation gaps.
The methodology follows a predictable arc: passive survey, target selection, capture (handshake, PMKID, or RADIUS challenge), offline cracking or live credential harvest, then a pivot test. Rules of engagement matter more than on a wired test, because radio attacks like deauthentication can disrupt nearby networks outside your scope, so targeted deauth beats broad flooding every time.
The one piece of special hardware is a wireless adapter that supports monitor mode and packet injection, such as chipsets based on the Atheros AR9271 or Realtek RTL8812AU. Everything else is software that ships with Kali: the aircrack-ng suite (airmon-ng, airodump-ng, aireplay-ng, aircrack-ng), hcxdumptool and hcxtools for PMKID capture and format conversion, hashcat for GPU cracking, Kismet for passive discovery, and eaphammer or hostapd-wpe for enterprise rogue-AP work.
Put the adapter in monitor mode, killing interfering processes first, then survey to list every BSSID, channel, encryption type, and connected client in range.
$ airmon-ng check kill
$ airmon-ng start wlan0
$ airodump-ng wlan0mon
BSSID CH ENC ESSID
AA:BB:CC:DD:EE:FF 6 WPA2 CorpWiFi <- target: WPA2-PSK
11:22:33:44:55:66 11 WPA3 CorpWiFi-Sec <- WPA3, check for transition mode
99:88:77:66:55:44 1 WPA2 GuestNet <- guest SSID, check VLAN separationThat survey is your target list. The ENC column tells you which attack applies, and any WPA3 SSID advertised alongside a WPA2 one of the same name is an immediate transition-mode red flag.
WPA2-PSK falls to a capture followed by offline cracking, and the cleanest capture is the clientless PMKID attack, which pulls the PMKID directly from the AP's first message with no deauth and no connected client. It is quieter because it never deauthenticates anyone, keeping you off a wireless IDS that watches for deauth floods. Convert to hashcat format and crack mode 22000, which covers both PMKID and the 4-way handshake.
$ hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1
[*] AA:BB:CC:DD:EE:FF CorpWiFi PMKID:KEY_FOUND <- PMKID grabbed, no client needed
$ hcxpcapngtool -o capture.hc22000 capture.pcapng
$ hashcat -m 22000 capture.hc22000 rockyou.txt -r rules/best64.rule
AA...:CorpWiFi:Summer2025! <- pre-shared key recovered
Status...........: CrackedThat Cracked line is the whole test in one word: the key was in a wordlist. A 12-character random key essentially cannot be cracked this way; Summer2025! falls in minutes. The alternative classic route grabs the 4-way handshake with a targeted deauth (aireplay-ng -0 5 -a <bssid> -c <client> wlan0mon) when no PMKID is available, then cracks the same mode 22000.
WPA3 closes the offline-cracking hole that defines WPA2, but it is not bulletproof. Its Simultaneous Authentication of Equals (SAE) handshake resists capture-and-crack, so a strong WPA3-only network will not fall to the workflow above. That is a genuine improvement.
The catch is transition mode. Most deployments run a mixed WPA2/WPA3 mode for backward compatibility, and an attacker can force a downgrade to WPA2 and attack that instead. The Dragonblood research also found side-channel and downgrade weaknesses in early SAE implementations. So a WPA3 test checks for transition-mode downgrade, weak-group negotiation, and whether the network can be coerced back to a crackable handshake. You survey the RSN information to confirm whether SAE is the only accepted suite or whether PSK is still advertised alongside it (hcxdumptool -i wlan0mon --rds=1). If both appear, you stand up a transition-mode-aware Evil Twin offering only WPA2 and watch whether clients downgrade. WPA3-only with a strong passphrase is the configuration you want to confirm.
Evil Twin attacks skip encryption entirely by impersonating a trusted network. You stand up a fake AP with the same SSID, deauth clients off the real one, and capture credentials or serve a captive-portal phish when they reconnect to yours. Modern clients warn before joining an unknown open network, so the reliable wins come from saved profiles and enterprise misconfigurations rather than a generic portal.
WPA2-Enterprise (802.1X) is where it gets serious. If clients do not strictly validate the RADIUS server certificate, a rogue RADIUS server harvests the MSCHAPv2 challenge-response, which you crack offline to recover domain credentials, often the same ones that authenticate to Active Directory.
$ eaphammer -i wlan0mon --essid CorpWiFi --creds
[*] Rogue AP up, waiting for clients...
mschapv2: CORP\m.lin::3a8f...:0011223344556677 <- domain creds challenge-response captured
$ hashcat -m 5500 netntlm.txt rockyou.txt
m.lin:CORP:Autumn2025! <- domain password recoveredThose harvested domain credentials are exactly the foothold an internal network penetration test picks up from. The fix is server-certificate validation and, ideally, EAP-TLS with client certificates so there is no shared secret to phish.
Network scanners miss Wi-Fi almost entirely, because the attack surface lives over the air rather than on an IP an agent can reach. Nessus will not tell you a guest SSID bridges to the corporate VLAN, that clients accept any RADIUS certificate, or that your WPA3 deployment quietly runs transition mode. Those are radio-side and configuration problems only an on-site survey with a monitor-mode adapter finds. The most common tester mistake is broad untargeted deauth flooding, which disrupts the business and can violate scope; use single targeted deauths against one client.
Securing Wi-Fi comes down to a short list. Use WPA3-only mode with a 12-plus character random pre-shared key and disable WPA2/WPA3 transition mode where you can. For enterprise, deploy EAP-TLS with client certificates, or at minimum push a configuration profile (Intune, a Mac profile, or GPO) that pins the expected RADIUS certificate and server name, so a user cannot click through a warning and hand their domain password to a fake AP. That single control neuters the highest-impact enterprise attack, because the rogue RADIUS server never gets a valid handshake to harvest. Separate guest and corporate networks at the VLAN and firewall level, not just by SSID, the same segmentation point in our enterprise misconfigurations guide, and monitor for rogue APs with a wireless IDS. Because APs, clients, and certificates change constantly, the continuous approach in agentic pentesting complements periodic on-site Wi-Fi assessments.