// OPERACIÓN: Wireshark - El analizador estándar de paquetes de red
// Kit para analistas: Anatomía de la captura de red
0x00 — WIRESHARK ES COMPLEJO
Wireshark no es difícil yo diría que es honesto.
Te pone delante cada bit que viaja por tu tarjeta de red sin filtros ni mentiras.
La clave para dominarlo es entender que la información está organizada en capas, como una cebolla.
Este post documenta la metodología completa de análisis pasivo de red utilizando mi Wireshark, cubriendo desde reconocimiento básico hasta diagnóstico avanzado de MTU, PMTUD y retransmisiones TCP.
CONTEXTO OPERATIVO
Hardware: ESP32 Marauder y paquetes de mi red Wifi
Técnica: Passive Sniffing (Modo Promiscuo) - Sin inyección de paquetes
Datasets: ap_sta_0.pcap, wifi.pcapng, wifi.csv
Objetivo: Reconocimiento pasivo, mapeo de infraestructura IoT, auditoría de tráfico
0x01 — LA INTERFAZ: LOS TRES PANELES
Wireshark divide tu pantalla en tres zonas de combate. Cada una tiene un propósito específico en la cadena de análisis.
A. El Panel de Lista (Superior)
Cada línea es un paquete, por ejemplo una captura típica de WiFi, verás principalmente Beacon frames.
Eso es básicamente el router gritando cada 0.1 segundos:
B. El Panel de Detalles (Central) - La Parte Clave
Aquí es donde Wireshark desglosa el paquete en capas.
Las tres pestañas críticas que debes dominar:
| Sección | Qué Contiene | Para Qué Sirve |
|---|---|---|
| IEEE 802.11 Beacon frame | Direcciones MAC (Receiver, Transmitter) | Identificar quién está hablando |
| Fixed Parameters | Beacon Interval (el "latido" del router) | Ver cada cuánto emite la señal (normalmente 102.4 ms) |
| Tagged Parameters | SSID, RSN Information, Vendor Specific | CRÍTICO - Aquí están los "candados" (WPA2/WPA3/AES) |
C. El Panel de Bytes (Inferior)
A la izquierda ves hexadecimal, a la derecha ASCII.
A veces, entre puntos y símbolos raros, verás el nombre de la red escrito directamente.
Es la forma más rápida de identificar un SSID sin abrir carpetas.
0x02 — EJERCICIO DE FAMILIARIZACIÓN: MODO OBSERVADOR
Flujo operativo básico para captura pasiva con ESP32 Marauder:
PROCEDIMIENTO DE CAPTURA
- En Marauder: WiFi → Sniffers → Beacon Sniff (30 segundos de captura)
- Guardar: Stop → Verificar guardado en SD
- En PC: Abrir archivo .pcap en Wireshark
- Filtro 1:
wlan.fc.type_subtype == 0x08(Solo Beacons) - Filtro 2:
wlan.addr == [MAC_DE_TU_MOVIL](Probe Requests)
0x03 — SECURITAS DIRECT ALARM PANEL
Análisis de dispositivo IoT capturado en modo pasivo.
El "DNI" del Dispositivo (Capa Física y Enlace)
| Campo | Valor | Análisis |
|---|---|---|
| Fabricante (OUI) | 58:b5:68 | Securitas Direct - Panel de Alarma o nodo central de seguridad |
| SSID | qaiuoVZVPVkpLf33IBrM9cbePincW4XZ | 32 caracteres aleatorios - Seguridad por Oscuridad |
| AKM (Auth Key Management) | WPA (1) | 802.1X (WPA Enterprise) - Autenticación basada en certificados/Radius |
| MFP (Management Frame Protection) | Capable | Marauder no podrá desautenticarlo fácilmente si el cliente también es capaz |
| Country Code | DE (Alemania) | Módulos WiFi configurados en fábrica con estándares alemanes/europeos |
| Potencia de Transmisión | 17 dBm | Potencia estándar - Tiempo de llegada: 16.96 segundos desde inicio de captura |
RESUMEN
- Alarma Securitas Direct en las proximidades
- Seguridad Enterprise (más robusta que router doméstico)
- Sensores/cámaras probablemente en Canal 1
- Sin enviar ni un solo bit - Modo sigiloso total
0x04 — EL DELTA TIME
En el mundo de las redes inalámbricas, el tiempo no es solo un número.
Es un indicador de salud y de identidad.
¿Por qué 102.4 ms y no 100 ms? (La matemática oculta)
El estándar IEEE 802.11 usa una unidad llamada TU (Time Unit):
1 TU = 1024 μs (microsegundos)
Intervalo por defecto = 100 TU
100 × 1024 = 102.400 μs = 102,4 milisegundos
Diagnóstico por Delta Time
| Delta Observado | Interpretación | Acción |
|---|---|---|
| 102 ms constantes | Captura perfecta - Mismo canal, sin interferencias | Posición ideal para ataque posterior |
| 204 ms o 306 ms | Marauder perdió paquetes (saltó un "latido") | Acercarse, cambiar canal, reducir interferencias |
| 5ms, 10ms, 80ms (aleatorios) | Filtro incorrecto - Paquetes de diferentes redes mezclados | Aplicar filtro por MAC específica |
| 101-103 ms (oscilante) | Jitter - Router espera microsegundos cuando el canal está ocupado | Comportamiento normal - Monitorear si aumenta |
Configurar Delta Time como Columna Principal
PROCEDIMIENTO
- Clic derecho en cabecera de columnas (Time, Source, Destination)
- Column Preferences
- Añadir columna: Title:
Delta - Type:
Delta time display(NO "Captured")
0x05 — FILTROS PROFESIONALES DE WIRESHARK
Tabla de referencia de filtros críticos para auditoría WiFi y diagnóstico de red.
| Filtro | Propósito |
|---|---|
wlan.fc.type_subtype == 0x08 | Beacons - Identificar routers y capacidades (WPA2, WPA3, Canales) |
wlan.fc.type_subtype == 0x04 | Probe Requests - Ver qué redes buscan los móviles de la gente |
wlan.addr == [MAC] | Aislamiento - Ver todo el tráfico de un dispositivo específico |
wlan.ssid == "" | Redes Ocultas - Detectar APs que no anuncian su nombre |
eapol | Handshake - Buscar intentos de inicio de sesión (Clave para cracking) |
ip.addr == 192.168.1.130 && !quic && !ssdp && !mdns | Antirruido - Eliminar tráfico de Google/YouTube y anuncios de impresoras/altavoces |
dns || tls.handshake.type == 1 | Chivato - Ver a qué webs vas (DNS + TLS Client Hello) |
tcp.flags.reset == 1 | Reset - Conexiones cerradas bruscamente (portazos) |
frame.len > 1350 | Paquetes grandes - Para análisis de MTU |
ip.len > 1350 && ip.flags.df == 1 | Simulación de fallo MTU - Paquetes que Mumbai descartaría |
tcp.analysis.retransmission | Retransmisiones - Paquetes perdidos (interferencias o MTU bloqueado) |
tcp.analysis.initial_rtt > 0.1 | Latencias altas - Saludos TCP que tardan más de 100ms |
0x06 — COLORES DE WIRESHARK
Wireshark usa colores para resaltar el estado de salud de la red y el tipo de protocolo.
Aquí una guía de interpretación de como viene por defecto:
| Fondo / Letra | Significado Técnico | Qué Está Pasando |
|---|---|---|
| Negro / Rojo | TCP Bad Quality | Paquetes perdidos, fuera de orden o retransmisiones - Conexión inestable |
| Gris oscuro / Blanco | TCP Control | Paquetes administrativos (ACKs) - Dicen "recibido" pero no llevan datos |
| Azul muy claro / Negro | UDP / DNS | Consultas a servidores DNS (gemini.google.com, etc.) |
| Púrpura claro / Negro | TCP / TLS | Tráfico web cifrado (HTTPS) - Lo más común en capturas modernas |
| Verde claro / Negro | HTTP | Tráfico web SIN cifrar - El contenido es legible |
| Amarillo / Negro | ARP / Control | "Gritos" de la red local - ¿Quién tiene la IP tal? ¿Dónde está el router? |
0x07 — LA CEBOLLA Y LAS CAPAS DEL MODELO OSI EN WIRESHARK
Cuando abres un paquete en la ventana de detalles (la del medio), estás viendo capas.
Cuanto más abajo bajas, más "dentro" del chip WiFi estás mirando.
| Capa | Qué Mirar | Campo Clave |
|---|---|---|
| 5. Frame (Superficie) | Metadatos: peso del paquete y hora exacta | Delta Time (Δt = tn - tn-1) |
| 4. IEEE 802.11 (Enlace) | El "quién es quién" | Type/Subtype, MACs (Receiver/Transmitter), Flags (Retry, PWR MGT) |
| 3. Wireless Management | El cerebro - Donde el router confiesa secretos | Fixed Parameters (Beacon Interval 102.4ms), Tagged Parameters (SSID, DS Parameter, RSN Info) |
| 2. IP Layer (Red) | Direcciones IP, TTL, Flags | Total Length, Don't Fragment bit, TTL (128=Windows, 64=Linux) |
| 1. TCP/UDP (Transporte) | Puertos y control de flujo | Ports (443=HTTPS, 53=DNS), Flags (SYN, ACK, PSH, RST, FIN), MSS |
| 0. Application (Aplicación) | El "qué" se están enviando | DNS (nombre de web), TLS (Encrypted Application Data), HTTP (contenido legible) |
0x08 — PAQUETE DE DATOS CIFRADO (FRAME 18)
Análisis completo de un paquete de datos WiFi protegido con WPA2.
Este es el tipo de tráfico que NO puedes leer sin la contraseña de la red.
Frame 18: Packet, 115 bytes
METADATOS DE CAPTURA
Arrival Time: Jan 1, 1970 01:00:17 (ESP32 sin RTC - Reloj empieza en 1970)
Delta Time: 204.817 ms (Intervalo alto para datos - Ráfagas espaciadas)
Frame Length: 115 bytes (920 bits)
Direccionamiento (¿Quién habla con quién?)
| Rol | MAC Address | Interpretación |
|---|---|---|
| Transmitter/BSSID | d4:f8:29:a7:17:b0 | SagemcomBroa (El router dispara la señal) |
| Source | bc:7e:8b:eb:42:0d | SamsungElect (El teléfono Samsung es el dueño original de los datos) |
| Destination/Receiver | 01:00:5e:7f:ff:fa | IPv4mcast (Multicast - "¡Hola! ¿Hay alguna TV o impresora por aquí?") |
CCMP Parameters (El candado WPA2/AES)
Como el paquete está protegido (Protected flag: Data is protected), aparece esta capa de cifrado:
- Initialization Vector (IV):
0x00001618C- Número que cambia en cada paquete para que el cifrado no sea siempre igual - Key Index:
1- Indica qué llave de la red se está usando
Data (El contenido secreto - 83 bytes)
¿Por qué son así estos bytes?
Porque sin la contraseña de la red y sin haber capturado el 4-Way Handshake (EAPOL), Wireshark no tiene la "llave" para convertir ese hexadecimal en texto legible.
0x09 — LA COLUMNA INFO
Mientras que la columna Protocol te dice qué idioma están hablando (TCP, TLS, QUIC), la columna Info te cuenta qué se están diciendo exactamente.
Fase 1: El Saludo TCP (Three-Way Handshake)
| Protocol | Info | Traducción "para humanos" |
|---|---|---|
| TCP | [SYN] | PC: "Hola, ¿podemos hablar? Mi MSS es 1460" |
| TCP | [SYN, ACK] | Servidor: "¡Hola! He recibido tu saludo. Yo también quiero hablar" |
| TCP | [ACK] | PC: "Perfecto, trato hecho. Empecemos" |
Fase 2: El Acuerdo TLS Handshake
- Client Hello: PC envía lista de "candados" (Cipher Suites) que sabe usar
- Server Hello: Servidor elige un candado y envía su certificado (DNI digital)
- Change Cipher Spec / Encrypted Handshake Message: A partir de aquí, todo será ilegible para el vecino
Fase 3: Intercambio de Carga (Data & Flags)
| Flag en Info | Significado |
|---|---|
[SYN] | "Hola, ¿hablamos?" (Inicio de sesión) |
[ACK] | "Recibido, todo ok". Es el 90% de tu tráfico |
[PSH, ACK] | "¡Aquí van datos de verdad! Pásalos a la aplicación" - El camión descargando mercancía |
[FIN] | Finalizar (Cerrar suavemente - Despedida educada) |
[RST] | Reset (Cerrar a lo bruto - Portazo en la cara. Puerto cerrado o firewall activo) |
Application Data | Contenido cifrado (TLS) |
QUIC Initial/Handshake/Protected Payload | Google usa esto en lugar de TCP+TLS - Más moderno y rápido |
0x0A — MTU
El caso de estudio de anteriores post hablé del incidente MTU, sostenido bajo mi humilde hipótesis.
Esto viene mucho a colación así que le damos un repaso en este post.
¿Te sabes la metáfora del camión que no cabe por el túnel?
La Autopista Estándar (Tu casa)
- MTU (1500): Gálibo (altura máxima) de los puentes de la autopista nacional
- El Camión (Paquete IP): Envías camiones de exactamente 15 metros para aprovechar espacio al máximo
- La Carga (MSS - 1460): Dentro del camión de 15 metros, los últimos 14,6 metros son datos. Los otros 0,4 metros son cabeceras TCP/IP
- Resultado: Todo fluye. Los camiones pasan sin rozar el techo
El Túnel de Seguridad (La VPN)
- El Problema: El túnel VPN es más estrecho porque tiene paredes reforzadas de acero (Cifrado/Seguridad)
- Gálibo del Túnel (MTU 1350): El techo está a solo 13,5 metros
- El Overhead (150 bytes): El blindaje del remolque VPN ocupa 1,5 metros de grosor
- El Desastre: Camión de 15 metros + Blindaje de 1,5 metros = 16,5 metros (NO CABE)
La Pegatina de "No Tocar" (Bit DF - Don't Fragment)
Los paquetes de VDI llevan una pegatina roja: DF = 1 (PROHIBIDO DESMONTAR)
Cuando el camión llega a la entrada del túnel VPN, el guardia ve que mide 16,5 metros y el túnel solo 13,5 metros.
Podría desmontar la carga en cajas pequeñas, pero ve la pegatina "PROHIBIDO DESMONTAR".
Acción del guardia: Tira el camión por un barranco. El paquete se pierde.
PMTUD fallido
Normalmente, el guardia del túnel debería llamarte y decirte: "Oye, el camión no cabe, mándamelos más pequeños". (Esto es el aviso ICMP Type 3, Code 4)
La incidencia dice: "El primer salto bloquea el tráfico ICMP"
- La Metáfora: El guardia intenta llamarte, pero la línea telefónica está cortada
- Consecuencia: No sabes que el camión ha sido destruido. Como no recibes el “recibido”, mandas otro camión igual de grande. Y otro. Y otro.
- Resultado: Tu sesión de VDI se congela porque estás enviando camiones a un barranco en Mumbai
MSS Clamping
Como no puedes subir el techo del túnel (el MTU de la red corporativa), tienes que convencer al PC del usuario de que use camiones más pequeños desde el principio.
MSS CLAMPING
Es como poner un policía en la puerta de tu casa justo cuando estás cargando el camión.
Tú vas a cargar 14,6 metros de cajas, pero el policía te dice: "Oye, que el túnel de adelante es bajo. Carga solo 12 metros".
Ahora: La carga mide 12 metros + 1,5 de blindaje = 13,5 metros
El camión pasa rozando el techo del túnel pero llega a su destino.
0x0B — LATENCIA: EL iRTT (INITIAL ROUND TRIP TIME)
En mi archivo wifi.csv, Frame 573 y 574 muestran una conversación con weathermapdata.blob.core.windows.net donde el camión tarda 157 milisegundos en ir y volver.
Cómo verlo en la "Cebolla"
Si abres el Frame 574 en Wireshark:
- Despliega Transmission Control Protocol (TCP)
- Busca la sección
[SEQ/ACK analysis](entre corchetes porque es un cálculo que hace Wireshark) - Localiza el campo
iRTT: 0.157352000 seconds
Diferenciando Latencia de Red vs Latencia de Aplicación
| Escenario | iRTT | Interpretación |
|---|---|---|
| Casa (weathermapdata) | 157 ms | Latencia de red - Distancia física ("Efecto Mumbai") |
| Trabajo (VDI Incidencia) | 6 ms | El saludo es rápido (paquete pequeño), pero el "camión grande" (MTU 1500) choca. El congelamiento es latencia de aplicación, NO de red |
Filtro para cazar latencias en tu trabajo:
Esto mostrará solo los saludos que tardan más de 100ms.
Si el iRTT es bajo pero la red va mal, confirma que el problema NO es la distancia, sino el MTU.
0x0C — KEEP-ALIVE Y LAS RETRANSMISIONES
Dos tipos de paquetes críticos para diagnosticar fallos de red: el Keep-Alive (la llamada de control) y la Retransmission (el camión que choca y vuelve a intentarlo).
Llamada de Control (Frame 306 y 308)
- Tamaño:
1 byte- Paquete casi vacío - Propósito: Mantener la conexión "viva" para que el servidor no la cierre por inactividad
- Time Delta típico: 30 segundos (el PC no ha enviado nada, pero manda este "toque")
- En tu incidencia: Si los camiones grandes (datos de VDI) no pasan por el túnel, el PC intentará enviar estos Keep-Alives pequeños (que sí caben) para que la sesión no se muera del todo
La "Retransmision" y el Bucle Infinito (Frame 313)
- Envío 1: El servidor manda un camión de 1500 metros (MTU 1500)
- El Choque: El camión choca con el túnel de la VPN (1350 metros). El camión explota
- El Silencio: El PC nunca ve el camión, así que no dice nada
- La Retransmisión: El servidor piensa: "Igual se ha perdido por un bache", y envía EL MISMO CAMIÓN de 1500 metros
- El Bucle Infinito: El camión vuelve a chocar. El servidor reintenta otra vez. Tu pantalla de PC se congela porque no llega ni una caja de mercancía
Cómo localizarlo en la Cebolla
Si pinchas en un frame de retransmisión en Wireshark:
- Despliega Transmission Control Protocol (TCP)
- Busca la sección
[SEQ/ACK analysis] - Verás que Wireshark te avisa:
This frame is a (suspected) retransmission - Mira la Capa IP →
Total Length. Si este número es 1500 ya tienes al culpable.
Spurious Retransmission (Frame 956)
¿Qué es esto? Cuando el servidor envía el camión otra vez, pero el primer camión SÍ había llegado, solo que el mensaje de "recibido" (ACK) tardó un poco más de la cuenta.
Es como si tu madre te llama dos veces seguidas porque en la primera llamada no le contestaste lo suficientemente rápido.
Es impaciencia del protocolo.
Resumen de Diagnóstico
| Si ves en Wireshark... | Significa que... | En tu incidencia de VDI... |
|---|---|---|
| Keep-Alive | Hay silencio pero la conexión sigue abierta | El túnel está libre pero no hay trabajo |
| Retransmission | Un paquete se ha perdido | ¡BINGO! El camión de 1500m ha chocado contra el túnel de 1350m |
| Spurious Retransmission | Impaciencia de respuesta | ACK tardó un poco - No crítico |
| RST (Reset) | Alguien ha dado un portazo | La paciencia se ha agotado y la sesión ha muerto |
0x0D — QUIC Y CRIPTOGRAFÍA POST-CUÁNTICA (FRAME 68)
Análisis del Frame 68 de la captura WiFi.
Este no es un Client Hello ordinario...será el futuro
La Capa de Enlace y Red (Capa 2 y 3): El Rastro del Hardware
- Ethernet II: Tarjeta Intel (
94:e6:f7:2d:65:59) hablando con router ZTE (2c:70:4f:0c:f8:0b) - IP Flags:
0x2 (Don't Fragment)- Si un nodo intermedio no puede manejar sus 1292 bytes, el paquete será incinerado - TTL:
128- Valor alto y redondo confirma que el sistema operativo es Windows (Linux usa 64)
Capa 4: UDP
No hay puertos TCP. QUIC utiliza UDP puerto 443.
- QUIC IETF: No es un simple flujo de datos. Es una conexión persistente
- Initial Packet: El primer grito en la oscuridad. El campo Token es una prueba de "liveness" para evitar ataques de amplificación
TLS 1.3 y Criptografía Post-Cuántica
| Campo | Valor | Traducción del Aether |
|---|---|---|
| SNI (Server Name Indication) | gemini.google.com | A pesar del cifrado, el nombre del sitio es visible - Talón de Aquiles de la privacidad actual |
| Supported Groups | X25519MLKEM768 | Algoritmos diseñados para resistir ataques de ordenadores cuánticos futuros - Vanguardia de defensa digital |
| Encrypted Client Hello | ECH | Solo navegadores modernos - Última capa de protección contra vigilancia |
0x0E — CONCLUSIONES
Wireshark es complejo porque te muestra todo.
No oculta, no miente, no filtra por ti.
Te pone delante la realidad cruda del tráfico de red.
COSAS A TENER EN CUENTA
- El Delta Time es tu mejor indicador de salud de red (102.4 ms = perfecto)
- Los colores son tu primer diagnóstico (Negro/Rojo = problema, Púrpura = HTTPS normal)
- Los filtros son tu bisturí - Desde
wlan.fc.type_subtype == 0x08para WiFi hastatcp.analysis.retransmissionpara diagnóstico avanzado - El iRTT te dice si el problema es distancia física o aplicación bloqueada
- Los Keep-Alive mantienen viva la sesión, las Retransmisiones delatan el punto de fallo
Con reconocimiento pasivo utilizando ESP32 Marauder y de mi wifi he conseguido básicamente:
- Identificación de Panel de Alarma Securitas Direct con seguridad Enterprise (802.1X)
- Mapeo de dispositivos IoT por OUI (Samsung, Sagemcom, Espressif)
- Análisis de robustez de seguridad (WPA2/WPA3, MFP, AES/CCMP)
- Detección de criptografía post-cuántica (X25519MLKEM768) en tráfico a Gemini
¿Ahora sabes más sobre esta herramienta?
Podrás encontrar mi guía en la documentación.
[EOF] "You don't know what's under the onion until you peel it"