Wireless Penetration Testing: WPA3, Enterprise Wi-Fi and the Evil Twin That Still Works

Offensive Security

Your wireless network does not stop at the office wall. Anyone in the car park, the lobby or the floor above can receive it, and none of them need a network cable to start an attack. A wireless penetration test checks what such a person can actually do: crack the passphrase, harvest domain credentials through a fake access point, or step from the guest network into systems that should be out of reach.

What a wireless penetration test covers

A wireless test looks at the radio side of your network the way an attacker in range would. It sits alongside an internal network penetration test, which starts from a device already on the network: the wireless test asks how that device got there.

Bluetooth, BLE and access-card technologies such as RFID and NFC have their own attack surface and can be included in the same engagement. This article concentrates on Wi-Fi, where most of the findings are.

What a tester uses, and what it shows

Wireless testing needs dedicated hardware: adapters that support monitor mode and packet injection, and directional antennas to measure how far the signal reaches. The software is mostly open source and well known. That is the point: an attacker in your car park has the same tools.

WPA2-Personal: the passphrase is the whole defence

On a WPA2-Personal network every device uses the same pre-shared passphrase. An attacker in range can capture the four-way handshake when a device connects, or force one by briefly disconnecting a client. Since August 2018, there has been an easier route: the PMKID attack, published by Jens Steube of the hashcat project, retrieves a crackable value from a single frame that many access points send, with no connected client needed.

Either way the attacker ends up with material they can attack offline, at whatever speed their hardware allows, with no lockout and no log entry on your side. Whether that succeeds depends entirely on the passphrase. A long random passphrase holds; a company name followed by a year does not.

The passphrase is also hard to keep secret. It is on every device, it is often written on the meeting-room whiteboard, and leavers take it with them. If it has not changed in years, assume people outside the company know it.

How strong is strong enough? The Wi-Fi Alliance's guidance is a "non-dictionary, high entropy" passphrase of between 8 and 63 characters. In practice that means a long random string or several randomly chosen words, not a phrase someone thought of, because cracking tools try dictionary words, names, dates and common substitutions first. Some enterprise wireless platforms can also issue a separate pre-shared key per device or group, so one lost device does not mean changing the key for everyone.

• Use a long, random passphrase for any network that must stay on a pre-shared key, and change it when people leave.
• Keep corporate devices off pre-shared key networks altogether. Use 802.1X with certificates for anything that reaches internal systems.
• Where a shared key is unavoidable, for example for some IoT devices, put that network on its own segment with access only to what those devices need.

WPA3-Personal: stronger, with a transition-mode catch

WPA3-Personal replaces the pre-shared key exchange with Simultaneous Authentication of Equals (SAE). The Wi-Fi Alliance, which introduced WPA3 in June 2018, explains the gain: an attacker who records a WPA3-Personal connection cannot take it away and try every password offline, because "the adversary gets only one guess at the password per attack." WPA3 also makes Protected Management Frames mandatory, which stops the forged disconnect messages attackers use to force reconnections.

The catch is transition mode, which lets WPA2 and WPA3 devices share one network name and passphrase while older devices are replaced. In April 2019, researchers Mathy Vanhoef and Eyal Ronen published Dragonblood, a set of attacks that included downgrading WPA3-capable devices in transition mode and side-channel leaks in early SAE implementations. The Wi-Fi Alliance's own deployment guide states the underlying risk directly: "the common password of a WPA3-Personal Transition Mode network can be determined by attacking a WPA2-Personal device using a simple offline dictionary attack." In other words, a transition-mode network is only as strong as WPA2 with the same passphrase.

• Run WPA3-only on networks where every device supports it, and put the remaining WPA2 devices on a separate network with a different passphrase.
• Keep access point and client firmware current, because the early SAE implementation flaws were fixed in updates.
• Use the protections WPA3 added for this. Transition Disable lets a network tell devices that support WPA3 to stop falling back to WPA2, and in the 6 GHz band WPA3 is mandatory: WPA2-Personal cannot be configured there at all.

WPA3 modes at a glance

WPA3 is a family of modes rather than one setting, and choosing the right one for each network matters more than switching on "WPA3" in general.

The Wi-Fi Alliance's deployment guidance expects WPA3-Personal networks deployed after 31 December 2027 to default to WPA3-only mode, so plan for transition mode to be temporary.

Enterprise Wi-Fi: where domain credentials leak

WPA2-Enterprise and WPA3-Enterprise use 802.1X: each user or device authenticates individually to a RADIUS server, usually against Active Directory. That removes the shared passphrase, but it introduces the most damaging wireless finding we see.

Many networks use PEAP with MSCHAPv2, where the user's domain username and password are checked inside a TLS tunnel to the RADIUS server. The tunnel only protects anything if the device checks that it is talking to your RADIUS server. If it does not, an attacker can broadcast the same network name, present any certificate, and the device will complete the exchange with them. MSCHAPv2 is cryptographically weak: researchers showed at DEF CON in 2012 that a captured exchange reduces to cracking a single DES key. Microsoft's 2013 security advisory on PEAP-MSCHAPv2 described exactly this scenario, warning that a system posing as a known Wi-Fi access point could exploit those weaknesses "to obtain the victim's domain credentials", and advised organisations to "require a certificate verifying a wireless access point before starting an authentication process."

Server validation fails in predictable ways: it was never configured, the setting lets users accept an unknown certificate with one tap, the list of trusted servers is missing, or personal devices joined with whatever settings the user chose. A single misconfigured device is enough.

• Move to EAP-TLS, where devices authenticate with certificates instead of passwords. There is no password exchange to capture. Microsoft recommends "moving away from MSCHAPv2-based connections (for example, PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (for example, PEAP-TLS or EAP-TLS)". Credential Guard, on by default from Windows 11 22H2 on eligible domain-joined devices, also blocks single sign-on to MSCHAPv2-based Wi-Fi, so many organisations meet this problem during an upgrade.
• Until then, enforce server validation centrally through Group Policy or device management: validate the certificate, trust only the issuing certificate authority, name the specific RADIUS servers, and do not let users approve new servers.
• Keep personal devices off the corporate network, or onboard them through a process that sets these values for them.

Because the credential is a domain account, this finding connects directly to Active Directory security: what one stolen password reaches inside the network is the subject of the internal test, and an Active Directory security assessment shows how far it goes.

Evil twins, open networks and captive portals

An evil twin is an access point that imitates a legitimate one. MITRE ATT&CK gave it its own technique, T1557.004 (Adversary-in-the-Middle: Evil Twin), in October 2024. Beyond enterprise credentials, a look-alike access point can imitate the guest network or a public hotspot that devices remember, then present a captive portal asking users to "sign in again" with their email password. Testing shows whether devices join automatically, whether users enter credentials, and whether anything on your side notices a second access point broadcasting your network name.

Guest and IoT networks: is the isolation real?

Guest networks are meant to give visitors the internet and nothing else. In testing, they often give a little more: a route to an internal address range, DNS or DHCP served by an internal server, the wireless controller's admin page, or other guests' devices because client isolation is off. IoT networks for cameras, printers and building systems have the same problems and usually weaker devices on them.

The test is simple to describe: join the guest or IoT network as an ordinary user and try to reach anything that is not the internet. Every success is a segmentation gap, and a network architecture review is the place to fix it properly, together with a firewall review of the rules between segments.

From the guest or IoT network, a tester typically tries to:

• Sweep the private address ranges (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16), and IPv6, which isolation rules often forget.
• Check whether DNS resolves internal names and whether DHCP hands out internal servers.
• Reach the wireless controller, access point or switch management interfaces.
• Reach other clients on the same network, which client isolation should block.
• Get past the captive portal, for example by copying the hardware address of a device that has already signed in.

Rogue access points

A rogue access point is one connected to your network without approval: a cheap router plugged in for better meeting-room coverage, or a device left deliberately by an intruder. It bypasses every control on your managed wireless network. If you handle card data, PCI DSS requirement 11.2.1 requires that "the presence of wireless (Wi-Fi) access points is tested for" and that authorised and unauthorised access points are detected and identified at least once every three months. A wireless test checks for them over the air and confirms whether any is actually connected to the wired network, which is what makes it dangerous.

Detecting them. Most enterprise wireless platforms include wireless intrusion detection that can flag an unknown access point broadcasting one of your network names, or a new device bridging onto the wired network. Those alerts only help if someone sees them, so send them to the same place as your other security alerts. On the wired side, 802.1X or network access control on switch ports stops an unapproved device getting network access at all.

Legacy settings still worth checking

• Wi-Fi Protected Setup (WPS). A design flaw disclosed in December 2011 means the eight-digit WPS PIN is checked in two halves, cutting the attempts needed from a hundred million to about 11,000, few enough to try them all. Disable it on anything that still offers it.
• WEP and TKIP. Both are broken. They still appear on networks kept alive for old handheld scanners, payment terminals or medical and industrial devices.
• Unpatched clients and access points. The KRACK attacks published in October 2017 targeted the WPA2 handshake itself and needed patches on both clients and access points. Devices that never received those patches remain exposed, which is one more reason to retire legacy equipment or isolate it.

How a wireless penetration test runs

A wireless security test is planned around your sites and networks: larger estates need more time on site, and cracking and reporting continue after the testers leave.

What a good wireless test report contains

A wireless finding is only useful if the team that fixes it can reproduce it and confirm the fix. For each finding, expect:

• The affected network name, access point and the location where the issue was reproduced.
• Evidence: the capture, the type of material recovered and how long it took to crack, or the device that joined the evil twin.
• What the access reached, so the finding is rated by impact.
• The exact fix, down to the setting or policy that needs to change.
• A retest result once the fix is in place.

The report should also include a map of where your signal can be received from outside the building. It is often the finding that changes how people think about wireless risk.

Preparing for a wireless penetration test

• A list of the sites, buildings and floors in scope, and the network names you own.
• Written authorisation, including for testing from car parks or shared areas you do not control.
• A test laptop and phone set up the way staff devices are, so enterprise authentication is tested against real configurations.
• Contacts in IT and facilities for the test days, and any times to avoid.
• Confirmation that networks belonging to neighbours and other tenants are out of scope, even though they are in range.

A wireless hardening checklist

Frequently Asked Questions

Click any question to expand the answer.

Related reading

For what happens after a device is on the network, see what an internal network penetration test finds. For the directory those credentials belong to, Active Directory security: hardening against modern attacks. For when to use a penetration test and when a red team, red team vs penetration testing.

Sources