En este artículo vamos a crackear WPA2 con el objetivo de obtener la credencial de una red Wi-Fi de la que no conocemos la contraseña. La idea es entender a bajo nivel por qué el ataque funciona: qué característica del protocolo estamos aprovechando y qué información necesitamos capturar exactamente para poder romper la contraseña de una red Wi-Fi.
Protocolo WPA/WPA2
WPA es un estándar desarrollado por la Wi-Fi Alliance para definir buenas prácticas de seguridad en redes Wi-Fi. Se apoya en gran parte del estándar 802.11i i en la autenticación 802.1x, TKIP y en un método de gestión dinámica de las claves de cifrado.
La diferencia principal entre WPA y WPA2 es el algoritmo de cifrado:
- WPA usa TKIP (basado en RC4).
- WPA2 incorpora CCMP, un modo de cifrado más robusto basado en AES para el cifrado y en CBC-MAC para el control de integridad de los mensajes.
En este artículo trabajamos con WPA/WPA2-Personal, es decir, la variante que usa una contraseña compartida (PSK) en lugar de un servidor de autenticación.
El 4-way handshake
El 4-way handshake es el proceso mediante el cual el AP (punto de acceso) y el cliente demuestran que poseen el mismo material criptográfico (PMK) y derivan las claves temporales que utilizarán durante la comunicación. Todo esto ocurre sin que la contraseña tenga que transmitirse por el aire.
Antes de ver como funciona este proceso, veamos las siguientes definiciones que serán importantes:
- PMK (Pairwise Master Key): en WPA/WPA2-Personal, es la clave maestra de 256 bits derivada de la contraseña y el SSID .
- ANonce: número aleatorio que envía el AP al cliente.
- SNonce: número aleatorio que envía el cliente al AP.
- AA (Authenticator Address): dirección MAC del AP.
- SA (Supplicant Address): dirección MAC del cliente.
Con estos cinco elementos, ambos extremos calculan de forma independiente la PTK (Pairwise Transient Key), que usaran para cifrar el tráfico unicast. En realidad, la PTK es un conjunto de material criptográfico del que se obtienen diferentes subclaves como la KCK (Key Confirmation Key), utilizada para calcular los MIC del handshake; la KEK (Key Encryption Key), utilizada para proteger material de claves; y la TK (Temporal Key), utilizada para proteger el tráfico unicast.
De forma simplificada la fórmula es:
PTK=PRF(PMK+ANonce+SNonce+AA+SA)
En realidad, el protocolo ordena las MAC y los nonces antes de introducirlos en la función de derivación, pero esta expresión nos permite entender de dónde procede la PTK
La clave del ataque está en que la PTK depende matemáticamente de la PMK, y la PMK depende de la contraseña. Todo lo demás (nonces y MACs) viaja en claro. Si capturamos esos valores, podemos probar contraseñas offline hasta encontrar una que permita reproducir el MIC observado en el handshake.
Para entender el concepto, veamos paso a paso cómo se realiza este 4-way handshake.
Mensaje 1 ( AP ->Cliente)
El AP envía un mensaje EAPOL con el ANonce. Con él, el cliente ya tiene todo lo necesario para calcular la PTK (conoce la PMK, su propio SNonce, ambas MACs y ahora el ANonce). En la captura vemos que la MAC de origen es la del AP (un TP-Link) enviando el paquete EAPOL (mensaje 1 de 4) al cliente.

Mensaje 2 ( Cliente -> AP)
El cliente ya ha calculado su PTK y responde con un EAPOL que contiene el SNonce. Este mensaje incluye un MIC (Message Integrity Code) un código de autenticación calculado utilizando la KCK, una de las subclaves derivadas de la PTK. Este MIC permite al AP comprobar la integridad del mensaje y verificar que el cliente posee el mismo material criptográfico. Al recibir el SNonce, el AP también puede calcular su PTK. Este mensaje 2 es el que más nos interesa como atacantes: contiene el SNonce y un MIC válido, que es exactamente lo que necesitamos para el ataque offline.

Mensaje 3 (AP -> Cliente)
El AP envía un EAPOL que contiene la GTK (Group Temporal Key), la clave que cifra el tráfico broadcast y multicast de la red. Aquí hay que dos matices importantes sobre la GTK.
La GTK viaja cifrada con la KEK, una porción de la PTK que ya se estableció en los mensajes anteriores. No va en claro. Esta clave ( la GTK) la genera solo el AP (la deriva de su GMK, Group Master Key), sin aportación del cliente. Tiene que ser así porque es una clave compartida por todos los clientes: el tráfico broadcast es el mismo para todos, así que el AP la fabrica de forma centralizada y la distribuye, a diferencia de la PTK, que es individual de cada cliente.

Mensaje 4 (Cliente -> AP)
El cliente envía un último EAPOL para confirmar que las claves se han instalado correctamente. A partir de aquí, la comunicación queda cifrada.

Nuestro objetivo como atacante, es interceptar el handshake para crackearlo offline. Una vez capturado (basta, en la práctica, con los mensajes 1 y 2, de donde salen los dos nonces, las MACs y el MIC), repetimos este bucle en nuestro propio equipo:
- Paso 1: Cogemos una contraseña del diccionario de contraseñas
- Paso 2: Calculamos el PTK usando la contraseña candiata, los nonces y las MACs capturadas.
- Paso 3: Con esa PTK calculamos la MIC que saldría.
- Paso 4: Si la MIC coincide con la que habíamos capturado, entonces hemos encontrado la contraseña.
Al tratarse de un ataque offline, no existe un contador de intentos del AP ni un mecanismo de bloqueo asociado a cada candidato probado. Su viabilidad depende principalmente de la entropía de la contraseña, el espacio de candidatos que tengamos que explorar y la capacidad de cómputo disponible. Una contraseña suficientemente larga, aleatoria y única puede hacer que este tipo de ataque resulte computacionalmente inviable
Paquetes de desautenticación.
Para capturar el handshake necesitamos que un cliente se autentique mientras estamos escuchando. Podemos esperar a que alguien se conecte por su cuenta, o forzarlo.
En el estándar 802.11 existen las tramas de desautenticación, pensadas para finalizar una sesión. En el estándar clásico estas tramas de gestión no están autenticadas, así que un atacante puede falsificarlas haciéndose pasar por el AP y expulsar a un cliente. Como los dispositivos se reconectan solos, al volver se genera un nuevo 4-way handshake que podemos capturar. Destacar que en el estándar 802.11w, las tramas de gestión van protegidas precisamente para prevenir este tipo de abusos.
Ataque paso a paso
Supongamos que tenemos un equipo auditor dentro de nuestro laboratorio y queremos capturar el handshake de la red Wi-Fi que estamos analizando. Disponemos de un adaptador Wi-Fi compatible con modo monitor y de una interfaz llamada wlan0
Con la herramienta airmon-ng podemos poner la interfaz en modo monitor, lo que permite capturar las tramas 802.11 que se transmiten por el canal aunque no estén dirigidas directamente a nuestro equipo
airmon-ng start wlan0
Una vez ejecutado, la interfaz pasa a llamarse wlan0mon, indicando que ya está en modo monitor. Con la interfaz en modo monitor, lanzamos airodump-ng para ver las redes de alrededor y, debajo de cada una, los clientes (STATION) conectados:
airodump-ng wlan0mon

De aquí sacamos lo que necesitamos para el ataque: el BSSID de la red objetivo, el canal en el que emite y la MAC de algún cliente que esté conectado.
Antes de tocar nada más, dejamos airodump-ng corriendo en una terminal aparte, esta vez fijado al canal del AP y volcando a un fichero, de esta manera evitamos que la antena siga saltando de canal.
airodump-ng -c 6 --bssid aa:aa:aa:aa:aa:aa -w captura wlan0mon
Con -c 6 fijamos el canal real del AP, con --bssid filtramos solo el objetivo para no llenar la captura de ruido, y con -w captura guardamos todo en captura-01.cap, que es donde acabará quedando el handshake.
Ahora en otra terminal, lanzamos el ataque de desautenticación para forzar que el cliente se reconecte:
aireplay-ng -0 10 -a aa:aa:aa:aa:aa:aa -c bb:bb:bb:bb:bb:bb wlan0mon
- -0 10 Indica que lanzaremos 10 paquetes de desautenticación
- -a : Es el BSSID de la red inalámbrica
- -c: Es la MAC del cliente que queremos atacar.
- wlan0mon: es la interfaz de la red inalámbrica desde la que lanzamos el ataque.
Cuando el cliente expulsado se reconecte, se disparará un nuevo 4-way handshake. Sabremos que lo hemos capturado porque airodump-ng lo indicará en la esquina superior derecha con un mensaje del tipo WPA handshake: AA:AA:AA:AA:AA:AA
Rompiendo 4-way Handskake.
Con el handshake ya en el .cap, pasamos a prepararlo para crackearlo. En este caso he volcado el tráfico en un fichero .cap para facilitar el análisis y extraer el handshake al formato hccap con aircrack-ng:
aircrack-ng -J handshake_raw + captura-01.cap
Donde:
- -J: Indica que queremos exportar el handshake en formato .hccap. El formato
.hccapes actualmente un formato legacy. Lo mantengo en este laboratorio porque es el flujo utilizado con John the Ripper, pero en workflows actuales con Hashcat se utiliza principalmente el formato22000, que sustituyó a los antiguos formatos.hccapy.hccapx - handshake_raw: Es el nombre del fichero generado
- captura-01.cap: Es el fichero donde está el handshake original
Una vez extraído, usamos hccap2john para convertir ese .hccap a un formato que John the Ripper pueda entender
hccap2john handshake_raw.hccap > hash.txt
Ya con el hash en un formato adecuado, solo queda lanzar el ataque de diccionario. Como es un laboratorio y la contraseña es débil, uso el diccionario RockYou; en un entorno real lo habitual es construir un diccionario a medida combinando el nombre de la empresa, patrones típicos, etc.
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
Y como resultado obtenemos la contraseña de la red.

Llegados aquí, una vez conocemos la contraseña podemos utilizarla junto con el SSID y el 4-way handshake capturado para que Wireshark derive las claves utilizadas durante esa sesión y descifre el tráfico 802.11. Para ello abrimos Edit → Preferences → Protocols → IEEE 802.11, marcamos Enable decryption y en Edit añadimos la clave en formato wpa-pwd como contraseña:SSID.

Una vez activado, Wireshark descifra y ya podemos ver el tráfico que la víctima intercambió con el punto de acceso. Eso sí, para que el descifrado funcione la captura debe contener el 4-way handshake completo de esa sesión, porque Wireshark lo necesita para reconstruir la PTK de cada cliente.
Conclusiones
Hemos visto cómo, aprovechando funcionalidades legítimas del protocolo Wi-Fi, es posible expulsar a un cliente con una trama de desautenticación, capturar el 4-way handshake cuando se reconecta, crackearlo offline y descifrar las comunicaciones.
La conclusión que podemos sacar de este ataque, es que la mayor debilidad de WPA/WPA2-Personal no está tanto en el cifrado sino en el factor humano: contraseñas débiles y presentes en diccionarios públicos. De ahí la importancia de usar contraseñas fuertes y, cuando sea posible migrar a WPA3-Personal, que sustituye el esquema PSK tradicional por SAE y hace obligatorio el uso de Protected Management Frames (PMF).
Recalcar que este articulo se ha llevado a cabo con un laboratorio de Wifi Challenge. En próximos artículos veremos más ataques a Wi-Fi usando este mismo entrono.