Moving from a shared passphrase to 802.1X is the right decision, and it only helps if your devices check the certificate the network presents. When they do not, an attacker stands up an access point with your SSID, presents any certificate at all, and collects domain credentials from every laptop that connects automatically. The fix is a client-side setting, which is why it gets missed.
What goes wrong on the client
The weakness sits in the supplicant, not in the network. With PEAP and MSCHAPv2, the client is supposed to validate the RADIUS server’s certificate before sending credentials into the tunnel, which means checking that the certificate chains to a trusted root and that the server name matches what you expect. Windows profiles created by hand often leave the validation box unticked, and Android devices asked to join manually offer a Do not validate option that users pick because it works. NIST’s guidance on robust security networks in SP 800-97 describes mutual authentication as the foundation of 802.1X, and skipping the server half turns it back into a password prompt on an open network.
How the attack runs in practice
A tester parks within range and starts an access point advertising your SSID. Tools such as eaphammer or hostapd-wpe do the rest: they answer the authentication attempt, accept whatever the client offers, and log the username along with the MSCHAPv2 challenge and response. Cracking that offline is fast, and even when the password holds, the captured material can sometimes be relayed. The whole exercise needs one laptop, one wireless adapter and a car park. Nothing needs to be exploited, because the laptop volunteers the credentials.
“Clients tell me their wireless is fine because it uses certificates, and then we find the certificates only run in one direction. Ask your team to open the network profile on a standard laptop and show you the trusted root and the server name it expects. If either box is empty, your enterprise wireless is a password prompt with extra steps.”
William Fieldhouse, Director, Aardwolf Security Ltd
Fixing it across a managed estate
Push the wireless profile from your management platform rather than letting users create it. In Intune or group policy, specify the trusted root certification authority, set the expected RADIUS server name, and disable the prompt that lets a user accept a new server. Do the same for mobile devices through your MDM. For anything you cannot manage, such as personal phones on a bring your own device scheme, put those clients on a separate network that leads nowhere interesting. The stronger option is EAP-TLS with client certificates, which removes passwords from the exchange entirely and is worth planning if you are rebuilding the wireless estate anyway.
Checking the fix actually landed
Verify from the client side, because a controller configuration tells you nothing about what laptops believe. Pick devices from each build and each department, open the profile, and confirm the validation settings are populated and locked. Then test it properly: wireless penetration testing exists to prove that a rogue access point gets nothing, and it takes a couple of hours to confirm. Where credentials do get captured, follow the chain through internal network testing to see how far those credentials reach, since a helpdesk account with local administrator rights is a different problem from a marketing login.
Frequently asked questions about 802.1X
Two questions come up whenever an enterprise wireless rebuild is being planned.
Is EAP-TLS worth the extra work?
For most organisations with a working certificate infrastructure, yes. It removes the password from the exchange, so a rogue access point captures nothing usable, and it simplifies leaver management to revoking a certificate.
Does this affect guest networks?
Not directly, since guest networks rarely use 802.1X. It matters for any network where domain credentials are used to authenticate, which is where a captured password leads somewhere worth protecting.
