Evil Twin EAP-TLS

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

EAP-TLS is the common “secure” choice for WPA2/3-Enterprise, but two practical weaknesses regularly show up during assessments:

  • Unauthenticated identity leakage: the outer EAP-Response/Identity is sent in cleartext before any TLS tunnel is built, so real domain usernames often leak over the air.
  • Broken client server-validation: if the supplicant doesn’t strictly verify the RADIUS server certificate (or allows users to click through warnings), a rogue AP with a self-signed cert can still onboard victims – turning mutual TLS into one-way TLS.

Unauthenticated EAP identity leakage / username enumeration

EAP drives an identity exchange before TLS starts. If the client uses the real domain username as its outer identity, anyone in RF range can harvest it without authenticating.

Passive harvest workflow

# 1) Park on the right channel/BSSID
airodump-ng -i $IFACE -c $CHAN --bssid $BSSID

# 2) Decode EAP frames and extract identities
# Trigger a client connection (e.g., your phone) to see the leak
tshark -i "$IFACE" -Y eap -V | grep "Identity: *[a-z]\|*[A-Z]\|*[0-9]"

Impact: fast, no-auth username collection → fuels password spraying, phishing, account correlation. Worse when usernames match email addresses.

TLS 1.3 privacy vs downgrade games

TLS 1.3 encrypts client certs and most handshake metadata, so when a supplicant actually negotiates TLS 1.3, an Evil Twin cannot passively learn the client certificate/identity. Many enterprise stacks still allow TLS 1.2 for compatibility; RFC 9190 warns that a rogue AP can offer only TLS 1.2 static-RSA suites to force a fallback and re-expose the outer identity (or even the client cert) in cleartext EAP-TLS.

Offensive playbook (downgrade to leak ID):

  • Compile hostapd-wpe with only TLS 1.2 static RSA ciphers enabled and TLS 1.3 disabled in openssl_ciphersuite / ssl_ctx_flags.
  • Advertise the corporate SSID; when the victim initiates TLS 1.3, respond with a TLS alert and restart the handshake so the peer retries with TLS 1.2, revealing its real identity before cert validation succeeds.
  • Pair this with force_authorized=1 in hostapd-wpe so the 4-way handshake completes even if client-auth fails, giving you DHCP/DNS-level traffic to phish or portal.

Defensive toggle (what to look for during an assessment):

  • hostapd/wpa_supplicant 2.10 added EAP-TLS server and peer support for TLS 1.3 but ships it disabled by default; enabling it on clients with phase1="tls_disable_tlsv1_3=0" removes the downgrade window.

Evil Twin via broken server validation (“mTLS?”)

Rogue APs broadcasting the corporate SSID can present any certificate. If the client:

  • doesn’t validate the server cert, or
  • prompts the user and allows override of untrusted CAs/self-signed certs, then EAP-TLS stops being mutual. A modified hostapd/hostapd-wpe that skips client-cert validation (e.g., SSL_set_verify(..., 0)) is enough to stand up the Evil Twin.

Rogue infra quick note

On recent Kali, compile hostapd-wpe using hostapd-2.6 (from https://w1.fi/releases/) and install the legacy OpenSSL headers first:

apt-get install libssl1.0-dev
# patch hostapd-wpe to set verify_peer=0 in SSL_set_verify to accept any client cert

Windows supplicant misconfig pitfalls (GUI/GPO)

Key knobs from the Windows EAP-TLS profile:

  • Verify the server’s identity by validating the certificate
    • Checked → chain must be trusted; unchecked → any self-signed cert is accepted.
  • Connect to these servers
    • Empty → any cert from a trusted CA is accepted; set CN/SAN list to pin expected RADIUS names.
  • Don’t prompt user to authorise new servers or trusted certification authorities
    • Checked → users cannot click through; unchecked → user can trust an untrusted CA/cert and join the rogue AP.

Observed outcomes:

  • Strict validation + no prompts → rogue cert rejected; Windows logs an event and TLS fails (good detection signal).
  • Validation + user prompt → user acceptance = successful Evil Twin association.
  • No validation → silent Evil Twin association with any cert.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks