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 常见的“安全”选择，但在评估中经常出现两个实际弱点：

  • Unauthenticated identity leakage: 外层 EAP-Response/Identity 在任何 TLS 隧道建立之前以明文发送，因此真实的域用户名经常通过无线传输 leak。
  • Broken client server-validation: 如果 supplicant 不严格验证 RADIUS server certificate（或允许用户点击忽略警告），具有自签名证书的 rogue AP 仍然可以 onboard 受害者 —— 将 mutual TLS 变成单向 TLS。

未认证的 EAP 身份泄露 / 用户名枚举

EAP 在 TLS 开始之前驱动身份交换。如果客户端将真实的域用户名作为其外层身份，任何在 RF 范围内的人都可以在不进行认证的情况下收集它。

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 隐私 vs 降级博弈

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):

  • 在 openssl_ciphersuite / ssl_ctx_flags 中，仅启用 TLS 1.2 static RSA ciphers 并禁用 TLS 1.3，编译 hostapd-wpe。
  • 广播企业 SSID；当受害者发起 TLS 1.3 时，回复一个 TLS alert 并重启握手，使对端重试 TLS 1.2，从而在证书验证成功前暴露其真实身份。
  • 在 hostapd-wpe 中设置 force_authorized=1，即使 client-auth 失败也完成 4-way handshake，从而获取可用于 phish 或 portal 的 DHCP/DNS 级别流量。

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

  • hostapd/wpa_supplicant 2.10 为 EAP-TLS 同时添加了 server 和 peer 对 TLS 1.3 的支持，但默认 disabled by default；在客户端通过 phase1="tls_disable_tlsv1_3=0" 启用可消除降级窗口。

TLS 1.3 realities in 2024–2025

  • FreeRADIUS 3.0.23+ 接受 EAP-TLS 1.3，但客户端仍然会故障（Windows 11 不支持 EAP-TLS 1.3 的会话恢复，Android 支持差异较大），因此许多部署为稳定性将 tls_max_version = "1.2" 钉定。
  • Windows 11 默认启用 EAP-TLS 1.3（22H2+），但失败的会话恢复和不稳定的 RADIUS 栈常常导致回退到 TLS 1.2。
  • TLS 1.2 的 RSA 密钥交换正在被弃用；OpenSSL 3.x 在 security level ≥2 时移除了 static-RSA 套件，因此要搭建 TLS 1.2 static-RSA rogue 需要 OpenSSL 1.1.1 并使用 @SECLEVEL=0 或更旧版本。

Practical version steering during an engagement

  • 强制 rogue 使用 TLS 1.2 (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 配置文件的关键选项：

  • 通过验证证书来确认服务器身份
  • 选中 → 链必须受信任；未选中 → 接受任意自签名 cert。
  • 连接到这些服务器
  • 空 → 接受受信任 CA 的任何 cert；设置 CN/SAN 列表以固定预期的 RADIUS 名称。
  • 不要提示用户授权新的服务器或受信任的证书颁发机构
  • 选中 → 用户无法点击继续；未选中 → 用户可以信任未受信任的 CA/cert 并加入 rogue AP。

观察到的结果：

  • 严格验证 + 无提示 → 拒绝 rogue cert；Windows 记录事件且 TLS 失败（这是良好的检测信号）。
  • 验证 + 用户提示 → 用户接受 = 成功的 Evil Twin 关联。
  • 无验证 → 使用任意 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