Evil Twin EAP-TLS
Tip
Вивчайте та практикуйте AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.
EAP-TLS — загальний «безпечний» вибір для WPA2/3-Enterprise, але під час оцінок регулярно виявляються дві практичні вразливості:
- Unauthenticated identity leakage: Зовнішній EAP-Response/Identity відправляється у cleartext перед тим, як будується будь-який TLS-тунель, тож реальні доменні імена користувачів часто leak по повітрю.
- Broken client server-validation: Якщо supplicant не перевіряє суворо RADIUS server certificate (або дозволяє користувачам натискати через попередження), rogue AP із self-signed cert все одно може onboard victims — перетворюючи mutual TLS на one-way TLS.
Unauthenticated EAP identity leakage / username enumeration
EAP ініціює обмін identity перед початком TLS. Якщо клієнт використовує реальний доменний ім’я користувача як свою зовнішню identity, будь-хто в RF діапазоні може зібрати його без аутентифікації.
Пасивний сценарій збору
# 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: швидкий збір імен користувачів без автентифікації → підживлює password spraying, phishing та кореляцію облікових записів. Гірше, коли імена користувачів збігаються з email-адресами.
TLS 1.3 — приватність проти атак із пониженням версії
TLS 1.3 шифрує client certs та більшість метаданих handshake, тож коли supplicant фактично узгоджує TLS 1.3, Evil Twin не може пасивно дізнатися client certificate/identity. Багато корпоративних стеків досі дозволяють TLS 1.2 для сумісності; RFC 9190 попереджає, що rogue AP може пропонувати лише TLS 1.2 static-RSA suites, щоб примусити fallback і повторно виставити outer identity (або навіть client cert) у cleartext EAP-TLS.
Атакувальний план (пониження до leak ID):
- Скомпілювати hostapd-wpe з увімкненими лише TLS 1.2 static RSA шифрами і з TLS 1.3 вимкненим у
openssl_ciphersuite/ssl_ctx_flags. - Рекламувати корпоративний SSID; коли жертва ініціює TLS 1.3, відповісти TLS alert і перезапустити handshake, щоб peer повторно спробував TLS 1.2, в результаті чого його реальна identity виявиться до виконання перевірки сертифіката.
- Поєднати це з
force_authorized=1в hostapd-wpe, щоб 4-way handshake завершився навіть якщо client-auth не вдається, даючи DHCP/DNS-рівневий трафік для phish або portal.
Захисна опція (на що звертати увагу під час оцінювання):
- hostapd/wpa_supplicant 2.10 додали підтримку EAP-TLS як на стороні server, так і peer для TLS 1.3, але постачаються вимкненими за замовчуванням; увімкнення на клієнтах через
phase1="tls_disable_tlsv1_3=0"усуває вікно для пониження версії.
Реалії TLS 1.3 у 2024–2025
- FreeRADIUS 3.0.23+ підтримує EAP-TLS 1.3, але клієнти все ще ламаються (Windows 11 не має EAP-TLS 1.3 session resumption, підтримка Android варіюється), тож багато розгортань фіксують
tls_max_version = "1.2"задля стабільності. - Windows 11 вмикає EAP-TLS 1.3 за замовчуванням (22H2+), але невдалі resumption-и та ненадійні RADIUS-стеки часто змушують fallback до TLS 1.2.
- RSA key exchange для TLS 1.2 поступово застаріває; OpenSSL 3.x видаляє static-RSA suites при security level ≥2, тому rogue TLS 1.2 static-RSA потребує OpenSSL 1.1.1 з
@SECLEVEL=0або старішої версії.
Практичне керування версією під час engagement
- Примусити rogue використовувати TLS 1.2 (щоб leak identities):
# hostapd-wpe.conf
ssl_ctx_flags=0
openssl_ciphers=RSA+AES:@SECLEVEL=0 # requires OpenSSL 1.1.1
disable_tlsv1_3=1
- Перевірити нетерпимість клієнта до TLS: запустіть два rogue — один, що рекламує тільки TLS 1.3 (
disable_tlsv1=1,disable_tlsv1_1=1,disable_tlsv1_2=1) і один тільки TLS 1.2. Клієнти, які приєднуються лише до BSS 1.2, вразливі до пониження версії. - Слідкувати за fallback у захопленнях: фільтруйте у Wireshark за
tls.handshake.version==0x0303після початковогоClientHelloзsupported_versions, що містить 0x0304; жертви, які повторно пробують 0x0303, знову розкривають свою outer ID.
Evil Twin через зламану валідацію сервера (“mTLS?”)
Rogue APs, що транслюють корпоративний SSID, можуть пред’явити будь-який certificate. Якщо клієнт:
- не валідовує server cert, або
- питає користувача й дозволяє override untrusted CAs/self-signed certs,
то EAP-TLS перестає бути mutual. Модифікований hostapd/hostapd-wpe, який пропускає валідацію client-cert (наприклад,
SSL_set_verify(..., 0)), достатній для підняття Evil Twin.
Швидка нотатка щодо rogue інфраструктури
На сучасному Kali скомпілюйте hostapd-wpe, використовуючи hostapd-2.6 (з https://w1.fi/releases/) і спочатку встановіть legacy OpenSSL headers:
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
- Увімкнено → chain must be trusted; вимкнено → any self-signed cert is accepted.
- Connect to these servers
- Порожнє → 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
- Увімкнено → користувачі не можуть click through; вимкнено → користувач може довірити an untrusted CA/cert і приєднатися до rogue AP.
Спостережувані результати:
- Strict validation + no prompts → rogue cert rejected; Windows logs an event and TLS fails (добрий сигнал для виявлення).
- Validation + user prompt → user acceptance = successful Evil Twin association.
- No validation → silent Evil Twin association with any cert.
References
- EAP-TLS: The most secure option? (NCC Group)
- EAP-TLS: бездротова інфраструктура (Versprite hostapd bypass)
- RFC 4282 - Ідентифікатор доступу до мережі
- Microsoft ServerValidationParameters (WLAN profile)
- RFC 9190 – EAP-TLS 1.3
- hostapd/wpa_supplicant 2.10 release notes (TLS 1.3 EAP-TLS support)
- FreeRADIUS TLS 1.3 support thread (Nov 2024)
- Windows 11 enabling TLS 1.3 for EAP (SecurityBoulevard, Jan 2024)
- draft-ietf-tls-deprecate-obsolete-kex
Tip
Вивчайте та практикуйте AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.


