BIPI
BIPI

Bypassing 802.1X Enterprise WiFi (and Defending It)

Cybersecurity

Evil twin attacks against WPA2/3 Enterprise still work in 2026 when client supplicants skip certificate validation. The fix is policy, not awareness training.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 28, 2025 · 7 min read

#wifi#802.1x#pentest

Corporate WiFi is usually 802.1X with PEAP-MSCHAPv2 or EAP-TLS. The first is bypassable when clients fail to validate the RADIUS server certificate. The second is robust if the private key stays on the device. Pentesters target the gap between policy and supplicant configuration.

Methodology

Stand up an evil twin with eaphammer or hostapd-wpe broadcasting the same SSID as the corporate network. Configure it to accept any EAP method. When a client roams or auto-connects, the supplicant sends NetNTLMv2-equivalent challenge-response inside MSCHAPv2. eaphammer captures it; you crack it offline.

  • eaphammer --cert-wizard: generate a self-signed RADIUS cert with the corp domain in CN.
  • eaphammer -i wlan0 --essid CORP-WIFI --auth wpa-eap --creds: launch the attack and log credentials.
  • hashcat -m 5500 hashes.txt rockyou.txt: crack PEAP-MSCHAPv2 challenge-response.
  • asleap or chapcrack for offline MSCHAPv2 brute force when you have a known plaintext.

Why certificate validation gets skipped

Three reasons we see in audits. First, the network admin shipped a self-signed CA without distributing it to clients, so users were trained to click through warnings. Second, the GPO sets 'Validate server certificate' but does not specify the trusted root or the RADIUS server name. Third, BYOD devices were enrolled manually without enforcement and skip validation entirely. Any one of these makes the evil twin attack succeed.

WPA3-Enterprise and 192-bit mode

WPA3-Enterprise in 192-bit mode mandates EAP-TLS with strong ciphers and removes MSCHAPv2 from the menu. It is not a default; it must be configured. Most enterprise rollouts label themselves 'WPA3' but run transition mode with PEAP still allowed, leaving the same evil twin path open.

Detection

Wireless IDS like Cisco WIDS, Aruba RFProtect, or open-source Kismet flags rogue APs broadcasting your SSID with a different BSSID. Look for client deauths followed by a re-association to a new BSSID with weaker signal. RADIUS server logs show authentication attempts that never reach you, which is itself a signal: a client is talking to something that is not your authenticator.

Remediation

  1. Enforce 'Validate server certificate' in the supplicant profile via GPO, MDM (Intune, Jamf), or wpa_supplicant config. Pin the trusted root CA and the RADIUS server names.
  2. Migrate from PEAP-MSCHAPv2 to EAP-TLS with client certificates issued from your internal CA. Bind certs to device identity, not user identity, where possible.
  3. Run a wireless IDS. Cisco, Aruba, and Mist all detect rogue APs spoofing your SSIDs. Open-source Kismet works for smaller environments.
  4. Disable WiFi auto-connect for corporate SSIDs on personal devices. Use a separate guest SSID with internet-only access.
  5. If you must stay on PEAP, deploy long, random user passwords (15+ chars) and pair with MFA at the network access control layer.
  6. Periodically run an authorized eaphammer test from your own SOC to validate that supplicants reject the bad cert.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.