The Scan Said "WPA2-Personal" and Nobody Asked Why
Here's how most wireless assessments go: spin up a Kali VM, run airodump-ng for twenty minutes, screenshot the SSID list, note that WPA2 is in use, check the box. Maybe throw in a deauth flood to capture a handshake, run it through hashcat with rockyou.txt, call it a day. If the password doesn't crack in an hour, the finding gets marked low and buried on page 47 of the report.
And then six months later someone's sitting in the parking lot with a WiFi Pineapple and a thermos of coffee, and they're in.
The actual attack surface on a wireless network in 2025 is almost nothing like what a checkbox assessment covers. We've got WPA3 rollouts that are being silently downgraded by clients that never asked to be. We've got 802.1X deployments where the RADIUS server is doing everything right except the one thing that matters — validating the server certificate on the client side. We've got IoT gear auto-provisioning over an open SSID that disappears after thirty seconds and leaves a PSK burned into firmware. None of that shows up in airodump output. All of it is exploitable.
WPA3 Rollout Is Creating the Attacks You're Not Watching For
WPA3-SAE (Simultaneous Authentication of Equals) was supposed to kill offline dictionary attacks. And honestly, against a properly configured deployment, it does. The Dragonfly handshake doesn't hand you a blob you can crack offline — there's no equivalent of the four-way handshake PMKID capture that made WPA2 so painful. But "properly configured" is doing a lot of work in that sentence.
The real issue is transition mode. Almost every enterprise and SMB rolling out WPA3 enables WPA3/WPA2 mixed mode so older clients don't fall off the network. That's operationally reasonable. It's also a downgrade attack waiting to happen. A client that supports WPA3 will happily connect to a WPA2 AP advertising the same SSID — there's no mechanism in the 802.11 spec that prevents it. An attacker with hostapd can stand up a WPA2 network with your SSID, deauth clients off the legitimate WPA3 AP, and watch them reconnect to WPA2. Now you're back to PMKID capture territory.
And PMKID capture has gotten significantly quieter since the days of deauth-and-pray. hcxdumptool can pull PMKIDs passively — no deauth, no association, just listening for the EAPOL frames that APs broadcast constantly. Pipe that into hcxpcapngtool to convert to hashcat's 22000 format and you're cracking without ever touching a client. The workflow is essentially:
hcxdumptool -i wlan0mon -o capture.pcapng --active_beacon
hcxpcapngtool capture.pcapng -o hashes.22000
hashcat -m 22000 hashes.22000 wordlist.txt -r rules/best64.rule
On a modern GPU, you're clearing eight-character alphanumeric passwords in under an hour. The assessment that marks this "low" because they didn't crack it with rockyou.txt is not testing your actual exposure.
The other WPA3 landmine nobody talks about is SAE-PK — the public key variant intended to prevent the exact Evil Twin scenario above. Virtually no client hardware supports it yet. So your WPA3 deployment is advertising a security property that your clients can't actually use. That's worth documenting in a real assessment. It rarely is.
The 802.1X Misconfiguration That's Been In Your Environment for Five Years
I had a client a few years back — mid-sized financial services firm, not a startup, they had a whole security team — running EAP-PEAP for corporate wireless. RADIUS server properly segmented, certificate issued from an internal CA, the whole setup looked fine on paper. What they hadn't done was configure the supplicant on Windows endpoints to validate the RADIUS server certificate or pin the CA.
So I stood up hostapd-mana with a self-signed cert, broadcast their corporate SSID from the parking structure, and let clients connect. EAP-PEAP with MSCHAPv2 will cheerfully send your NTHash to any RADIUS server that presents a cert — any cert. Windows machines that had been connected to the legitimate network all morning started authenticating against my rogue AP within minutes of me changing position. I had NTHash captures for a domain admin account before the coffee I'd bought downstairs had cooled.
This is not a novel attack. It's been documented since at least 2012 (see Moxie Marlinspike's work on hostapd-wpe, the predecessor to mana). It still works in 2025 because nobody goes back and audits supplicant configuration after the initial 802.1X deployment. The setup that was "good enough" at rollout has drifted. Group Policy that was supposed to enforce cert validation got overridden somewhere. A new laptop image shipped without it. You'd never know from airodump output.
The fix is simple in concept: enforce server certificate validation on the supplicant, pin the issuing CA, and configure the expected server name. In practice, rolling that out to a few thousand endpoints without breaking anything is a project, and most organizations have never prioritized it because nobody put it in a pentest report with a critical severity. Start putting it in pentest reports with critical severity.
EAP-TLS with mutual certificate authentication is genuinely hard for an attacker to defeat — there's no password to steal, the client cert is machine-specific, and the handshake requires both sides to prove identity. If your client is still running EAP-PEAP-MSCHAPv2, that's not a configuration detail. That's a vulnerability.
Evil Twins Are Not What the Training Videos Show You
The Evil Twin scenario in most security awareness training is almost comically simplistic: attacker sets up open WiFi, victim connects, attacker does ARP spoofing, done. The actual technique is substantially more sophisticated and works against networks you'd think are protected.
hostapd-mana implements the Karma attack — responding to any directed probe request with a matching SSID. Your laptop's remembered network list is a list of SSIDs you'll connect to automatically. Modern Windows and macOS have gotten better about not broadcasting that list aggressively, but plenty of devices still do. IoT gear almost universally does. And on any network where clients are actively scanning, Karma will pick up connections without even needing to know the target SSID in advance.
The more targeted version uses known SSIDs — you find out what corporate SSIDs the target uses (this is trivially easy from LinkedIn job postings, Wigle.net, or just sitting outside the building), you configure hostapd-mana to respond to those specifically, and you position yourself near a conference room or parking structure where devices are at the edge of coverage. Combine that with a targeted deauth against the legitimate AP and you've got a reliable capture setup.
What makes detection hard: a decent rogue AP setup doesn't need to be on the same channel as the legitimate AP. It doesn't need to have the same BSSID. Clients will connect to the strongest signal, and if you're physically closer than the ceiling-mounted AP, you win on signal strength alone. Wireless IDS systems that rely on BSSID matching to identify rogues — and many of them do — won't flag this at all.
Kismet does a better job here. Its rogue AP detection correlates SSID, BSSID, encryption type, and beacon timing to identify APs that look like they're impersonating a known network even without a matching BSSID. But Kismet needs to be running, needs sensors in the right places, and needs someone paying attention to it. In most environments I've assessed, the wireless IDS is either not deployed or is generating so much noise that real alerts are getting buried.
Bluetooth Doesn't Show Up in Your Wireless Assessment and It Should
802.11 assessments are called "wireless assessments" but they almost never touch Bluetooth or BLE. That's a meaningful gap. BLESA (Bluetooth Low Energy Spoofing Attack) from the University of Purdue demonstrated that reconnection in BLE is fundamentally weaker than the initial pairing — the CVEs cover essentially every major BLE stack. BIAS (Bluetooth Impersonation AttackS) showed that Classic Bluetooth legacy authentication allows an attacker who knows a device's address to impersonate it to a paired device without knowing the link key.
In a corporate environment, Bluetooth matters for a few reasons. Wireless keyboards and mice using BLE are everywhere — and MouseJack-class vulnerabilities (Bastille Research, 2016) aren't fully addressed on older peripherals. Smart locks, badge readers, and HVAC controls using BLE for provisioning or management represent physical security bypass paths. Healthcare environments are swimming in BLE-connected medical devices that have never been assessed.
The proximity attack angle is underrated. If an attacker can trigger a BLE connection to a device that uses BLE for authentication or access control, physical presence alone creates an attack path that 802.11 monitoring completely misses. GATTacker and Wireshark with a Ubertooth One are the standard toolkit here. Neither shows up in a typical wireless assessment scope.
IoT Provisioning Is an Open Wound
The way most consumer and light commercial IoT devices provision to WiFi is genuinely terrible from a security standpoint. The SoftAP provisioning model — device stands up an open AP, you connect to it, you send it your PSK through an unencrypted or weakly encrypted channel — was documented as a problem years ago and is still in production firmware everywhere.
Some devices moved to Bluetooth provisioning, which trades one set of problems for another. Some use SmartConfig or similar "magic packet" broadcast schemes where the PSK is encoded in the length of broadcast packets — the encoding is documented and reversible. An attacker with passive capture during the provisioning window gets your PSK.
And then there's the device itself: once provisioned, IoT gear typically stores the PSK in flash in cleartext or with trivially weak obfuscation. Physical access to the device — pulling the flash chip, UART console, whatever — hands you the network credential. On a network where IoT devices share the main WiFi (not a separate VLAN, which is best practice but rarely universal), that's full network access.
This never makes it into wireless assessments because it requires looking at the provisioning process, not just the running network. It requires someone to actually buy the device, watch it provision, and capture the traffic. That's more work than running airodump for twenty minutes. It's also a much more realistic attack path against a building full of smart thermostats and badge readers than dictionary-attacking a WPA2 handshake.
What a Real Wireless Assessment Looks Like
It starts before you touch a radio. Review the supplicant configuration for every OS image in the environment. Check what EAP method is configured. Check whether server cert validation is enforced and what CA is pinned. Check the SSID list on a handful of endpoints to understand what a Karma attack surface looks like. None of that requires a single packet transmitted.
Then you do the RF work — but not just airodump. hcxdumptool running passively for the duration of the assessment, capturing PMKIDs. Mapping the physical RF environment against the logical AP deployment — are there coverage gaps where a rogue AP could operate without being in range of the WIDS sensors? Attempting WPA3 downgrades against SSIDs running transition mode. Attempting PMKID capture against networks that should be running SAE.
For 802.1X environments, actually test the Evil Twin path. Stand up hostapd-mana with a self-signed cert and confirm that clients either refuse to connect or that the WIDS catches it. If clients connect and the WIDS doesn't fire, that's a critical finding regardless of whether you captured any credentials.
The Bluetooth and BLE scope question should be answered explicitly in the assessment. If it's out of scope, that's a decision the client made. But they should make it consciously, not by default because nobody asked.
And document the provisioning process for any IoT devices on the network. Ask to observe a device being provisioned. Capture the traffic. If you can't do that during the assessment window, at minimum note that it hasn't been tested and explain what that gap means.
The checkbox assessment isn't wrong exactly — it's just answering a question nobody is actually asking. The question isn't "is WPA2 in use." The question is "can someone sitting in a car outside this building get onto the network in the next two hours." Those are different questions and they require different tests.
