Evil Twin EAP-TLS

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

EAP-TLS は WPA2/3-Enterprise で一般的な「安全」な選択肢ですが、評価時に頻繁に現れる実用的な弱点が2つあります：

  • Unauthenticated identity leakage: outer EAP-Response/Identity は TLS トンネルが確立される前に平文で送信されるため、実際のドメインユーザー名が無線上でしばしば leak します。
  • Broken client server-validation: supplicant が RADIUS サーバー証明書を厳密に検証しない（あるいはユーザーが警告をクリックして先に進めることを許す）場合、self-signed cert を持つ rogue AP が victims を onboard でき、mutual TLS を one-way TLS にしてしまいます。

Unauthenticated EAP identity leakage / username enumeration

EAP は TLS が開始される 前に アイデンティティ交換を行います。クライアントが実際のドメインユーザー名を outer identity として使用している場合、RF 範囲内の誰でも認証なしにそれを harvest できます。

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]"

影響: 高速で認証不要のユーザー名収集 → password spraying、phishing、account correlation を助長する。ユーザー名がメールアドレスと一致する場合はさらに悪化する。

TLS 1.3 privacy vs downgrade games

TLS 1.3 はクライアント証明書とハンドシェイクのほとんどのメタデータを暗号化するため、supplicant が実際に TLS 1.3 をネゴシエートすると、Evil Twin は受動的にクライアント証明書／ID を取得できない。多くの企業スタックは互換性のために TLS 1.2 をまだ許可しており；RFC 9190 は rogue AP が TLS 1.2 の static-RSA スイートのみを提示してフォールバックを強制し、外側の ID（あるいはクライアント証明書）をクリアテキストの 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.

TLS 1.3 realities in 2024–2025

  • FreeRADIUS 3.0.23+ accepts EAP-TLS 1.3, but clients still break (Windows 11 has no EAP-TLS 1.3 session resumption, Android support varies), so many deployments pin tls_max_version = "1.2" for stability.
  • Windows 11 enables EAP-TLS 1.3 by default (22H2+), yet failed resumptions and flaky RADIUS stacks often force a fallback to TLS 1.2.
  • RSA key exchange for TLS 1.2 is being deprecated; OpenSSL 3.x drops static-RSA suites at security level ≥2, so a TLS 1.2 static-RSA rogue needs OpenSSL 1.1.1 with @SECLEVEL=0 or older.

Practical version steering during an engagement

  • Force TLS 1.2 on the rogue (to leak identities):
# hostapd-wpe.conf
ssl_ctx_flags=0
openssl_ciphers=RSA+AES:@SECLEVEL=0   # requires OpenSSL 1.1.1
disable_tlsv1_3=1
  • Probe client TLS intolerance: run two rogues – one advertising TLS 1.3-only (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1) and one TLS 1.2-only. Clients that only join the 1.2 BSS are downgradeable.
  • Watch for fallback in captures: filter in Wireshark for tls.handshake.version==0x0303 after an initial ClientHello with supported_versions containing 0x0304; victims that retry 0x0303 are leaking their outer ID again.

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の設定ミスによる落とし穴 (GUI/GPO)

Windows EAP-TLS プロファイルの主な設定項目:

  • Verify the server’s identity by validating the certificate
  • Checked → チェーンは信頼されている必要がある; unchecked → 任意の自己署名certが受け入れられる。
  • Connect to these servers
  • Empty → 信頼されたCAからの任意のcertが受け入れられる; CN/SANリストを設定して期待されるRADIUS名をピン留めする。
  • Don’t prompt user to authorise new servers or trusted certification authorities
  • Checked → ユーザーはクリックで先に進めない; unchecked → ユーザーは信頼されていないCA/certを信頼してrogue APに参加できる。

観察された結果:

  • Strict validation + no prompts → rogue certは拒否される; Windowsはイベントを記録し、TLSは失敗する（良い検知シグナル）。
  • Validation + user prompt → ユーザーの承認 = 成功した Evil Twin の接続。
  • No validation → 任意のcertでサイレントにEvil Twinに接続される。

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする