Research Update Enhanced src/generic-methodologies-and-resou...

src/generic-methodologies-and-resources/pentesting-wifi/evil-twin-eap-tls.md

@@ -24,6 +24,18 @@ 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.
 
+### Managed-profile quick check (outer identity hygiene)
+
+Managed Android Enterprise deployments still need an explicit **outer identity** / privacy value for certificate-based Wi-Fi profiles. If MDM leaves that field blank (or sets it to the real UPN), the device will keep exposing a correlatable username in the first `EAP-Response/Identity` before TLS. During assessments, `anonymous` or `anonymous@realm` is what you want to observe over the air.
+
+```bash
+# Capture only EAP identity responses during reconnects
+tshark -i "$IFACE" -Y 'eap.code == 2 && eap.type == 1' \
+  -T fields -e frame.time -e wlan.sa -e eap.identity
+```
+
+If managed devices still emit mail-style identities while the org claims “EAP-TLS hides usernames”, the privacy knob was never enforced in the onboarding profile.
+
 ## 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.
@@ -63,13 +75,21 @@ then EAP-TLS stops being mutual. A modified **hostapd/hostapd-wpe** that skips c
 
 ### 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:
+For baseline testing on current Kali, the packaged `hostapd-wpe` is usually enough:
 
 ```bash
-apt-get install libssl1.0-dev
-# patch hostapd-wpe to set verify_peer=0 in SSL_set_verify to accept any client cert
+apt update
+apt install hostapd-wpe
+hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf
 ```
 
+Only rebuild/patch when you specifically need to:
+
+- disable client-cert validation for EAP-TLS MitM (`SSL_set_verify(..., 0)`-style patch), or
+- build a TLS 1.2 static-RSA-only downgrade lab with an older/OpenSSL-1.1.1 userspace and `@SECLEVEL=0`.
+
+That second case is increasingly lab-only: modern OpenSSL 3.x defaults make static-RSA downgrade setups fragile, so keeping a dedicated container/VM for the rogue RADIUS stack is usually easier than modifying your daily driver.
+
 ### Windows supplicant misconfig pitfalls (GUI/GPO)
 
 Key knobs from the Windows EAP-TLS profile:
@@ -85,6 +105,32 @@ Observed outcomes:
 - **Validation + user prompt** → user acceptance = successful Evil Twin association.
 - **No validation** → silent Evil Twin association with any cert.
 
+### Silent Evil Twin with a trusted cert (no prompt required)
+
+User-clickthrough is only one path. If the supplicant trusts a CA that the attacker can abuse (for example, by stealing the real NPS certificate or obtaining another **Server Authentication** cert from the same private PKI), the rogue can often become **promptless** instead of merely “click-through”.
+
+Practical implications on Windows profiles:
+
+- **Empty `Connect to these servers`** = any server certificate chaining to a trusted CA is acceptable.
+- **Windows 11 prefers SAN DNS matching over CN** when the certificate contains a SAN DNS entry, so stale CN-only pinning can behave differently than expected.
+- **Wildcard / broad name patterns** increase the blast radius if the org trusts an internal CA capable of issuing arbitrary RADIUS-like names.
+
+This is where Wi-Fi Evil Twin work starts to overlap with [AD Certificates](../../windows-hardening/active-directory-methodology/ad-certificates/README.md): once you can mint or steal a trusted server-auth cert, you are no longer betting on bad UX or user clicks.
+
+**Quick triage on a Windows endpoint**
+
+```powershell
+# Export the WLAN profile and inspect the server-validation block
+netsh wlan export profile name="CorpWiFi" folder=.
+Select-String -Path .\Wi-Fi-*.xml -Pattern 'ServerNames|TrustedRootCAHash|DisablePrompt'
+```
+
+Red flags:
+- empty `ServerNames`
+- more trusted roots than the deployment really needs
+- `DisablePrompt` absent/false on unmanaged endpoints
+- wildcard/regex-like server-name patterns broader than the real NPS farm
+
 ## References
 
 - [EAP-TLS: The most secure option? (NCC Group)](https://www.nccgroup.com/research-blog/eap-tls-the-most-secure-option/)
@@ -95,6 +141,8 @@ Observed outcomes:
 - [hostapd/wpa_supplicant 2.10 release notes (TLS 1.3 EAP-TLS support)](https://lists.infradead.org/pipermail/hostap/2022-February/040204.html)
 - [FreeRADIUS TLS 1.3 support thread (Nov 2024)](https://lists.freeradius.org/pipermail/freeradius-users/2024-November/104969.html)
 - [Windows 11 enabling TLS 1.3 for EAP (SecurityBoulevard, Jan 2024)](https://securityboulevard.com/2024/01/windows-11-changes-you-need-to-know/)
+- [EAP - What's changed in Windows 11 (Microsoft Learn)](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/windows-11-changes)
+- [Add Wi-Fi settings for Android devices in Microsoft Intune (Android Enterprise)](https://learn.microsoft.com/en-us/intune/device-configuration/templates/ref-wifi-settings-android-enterprise)
 - [draft-ietf-tls-deprecate-obsolete-kex](https://datatracker.ietf.org/doc/html/draft-ietf-tls-deprecate-obsolete-kex)
 
 {{#include ../../banners/hacktricks-training.md}}