Un ataque man-in-the-middle es, en palabras de NIST, "un ataque en el que un atacante se posiciona entre dos partes que se comunican para interceptar o alterar los datos que viajan entre ellas". Los dos extremos siguen funcionando con normalidad y ninguno ve al tercero en el cable.
En 2011, unos atacantes compromised a la autoridad certificadora holandesa DigiNotar. ENISA reportó que "se crearon certificados falsos para cientos de sitios web, incluidos Google y Skype" y que "durante dos meses se usaron certificados falsos para espiar a usuarios en Irán". Todas esas sesiones estaban cifradas y todos los navegadores mostraban un candado. Eso es lo que ve la víctima de un ataque man-in-the-middle: nada.
Esta página explica qué es un ataque man-in-the-middle, cómo se posiciona el atacante, qué controles rompen cada técnica, cuáles son más débiles de lo que su reputación sugiere y cómo Fluid Attacks evalúa las debilidades que hacen posible la interceptación.
¿Qué es un ataque man-in-the-middle?
Un ataque man-in-the-middle, o ataque MITM, coloca al atacante en la ruta de comunicación entre dos extremos que creen estar hablando directamente entre sí. Desde ahí puede leer el tráfico, modificarlo, retransmitirlo o retenerlo. MITRE ATT&CK cataloga el comportamiento como Adversary-in-the-Middle (T1557) y describe a los adversarios posicionándose entre dos o más dispositivos en red.
La posición es lo que convierte esto en un ataque man-in-the-middle. Lo que el atacante haga desde ahí es otra pregunta, y es donde la mayoría de las explicaciones se equivocan.
Estar en la ruta no significa leer el contenido. Un atacante que retransmite tráfico TLS sin romper el canal ve tamaños de paquete, tiempos y destinos, no texto claro. Un ataque man-in-the-middle que lee o modifica contenido protegido necesita que el cliente acepte una identidad que debería rechazar: un certificado de una autoridad comprometida, un certificado que la aplicación nunca valida o una conexión que el navegador permitió degradar a HTTP. El problema es de autenticación más que de cifrado.
Hay tres cosas que se confunden con un ataque man-in-the-middle. Escucha pasiva: en un canal sin cifrar basta el acceso, no hace falta interponerse. Suplantación: falsifica una identidad, pero puede no retransmitir nada. Extremo comprometido: ve texto claro porque es una de las dos partes, que no es lo mismo que estar en medio.
Cómo funciona un ataque man-in-the-middle
Todo ataque man-in-the-middle tiene dos etapas: entrar en la ruta y después hacer algo con el tráfico. Son independientes, y un atacante puede lograr la primera y fallar en la segunda. Frente a una conexión TLS bien configurada, ese es el desenlace normal de un ataque man-in-the-middle.
Etapa uno: posicionarse. El atacante manipula un protocolo que decide a dónde va el tráfico: resolución de direcciones, resolución de nombres, asignación de direcciones o asociación inalámbrica. Ninguno se diseñó con autenticación, y por eso siguen sosteniendo un ataque man-in-the-middle décadas después de que el problema se describiera por primera vez.
Etapa dos: actuar sobre el tráfico. El desenlace depende de cómo se autentiquen los extremos entre sí. Frente a protocolos en texto claro, el atacante lee y reescribe a voluntad. El requisito 181, Transmit data using secure protocols de Fluid Attacks nombra HTTP, FTP, POP3 y Telnet como ejemplos, y mapea a CAPEC-94, CWE-319, PCI DSS 4.2.1 y NIST SP 800-115. Frente a TLS, el atacante necesita una falla de validación. Frente a TLS más un cliente que fija certificados o presenta el suyo, normalmente necesita ejecución de código en el dispositivo.
Los controles que detienen cada etapa son distintos. Las organizaciones compran el primer conjunto y dejan el segundo sin examinar, y así es como un ataque man-in-the-middle atraviesa una red que parece defendida.
Tipos de ataques man-in-the-middle
Las técnicas siguientes son las que se ven en redes reales. MITRE clasifica cuatro como subtécnicas de T1557. El SSL stripping y el man-in-the-browser quedan fuera porque atacan el transporte y el extremo, no el enrutamiento.
Técnica | ID de MITRE | Qué obtiene el atacante |
ARP poisoning | T1557.002 | Tráfico de cualquier host del segmento local |
DHCP spoofing | T1557.003 | La puerta de enlace y el servidor DNS que elija |
Envenenamiento de LLMNR y NBT-NS | T1557.001 | Material de autenticación NTLM de equipos Windows |
Evil twin de Wi-Fi | T1557.004 | Todo lo que envíe la víctima tras asociarse |
SSL stripping y HTTP spoofing | — | Texto claro, al impedir el paso a HTTPS |
Man-in-the-browser | — | Contenido de sesión después de que TLS terminó |
Técnicas que habilitan un ataque man-in-the-middle, con su clasificación en MITRE ATT&CK.
ARP poisoning
El atacante responde solicitudes ARP en un segmento local y asocia su propia dirección MAC con la dirección IP de un host legítimo, normalmente la puerta de enlace. El tráfico dirigido a ese host llega al atacante. ARP no tiene autenticación, así que gana la última respuesta.
DNS spoofing
El atacante devuelve respuestas falsas a las consultas de nombres y envía a la víctima a infraestructura que él controla. Eso es redirección, no interceptación, y la distinción importa: el navegador de la víctima sigue validando el certificado en el destino. El DNS spoofing se vuelve un ataque man-in-the-middle completo solo cuando se combina con un certificado que la víctima acepte, que es justo lo que aportó el compromiso de DigiNotar.
SSL stripping y HTTP spoofing
El atacante intercepta la solicitud en texto claro que hace el navegador antes de cualquier redirección a HTTPS y le sirve a la víctima una copia sin cifrar del sitio, mientras mantiene una sesión HTTPS correcta con el servidor real. La víctima ve una página que funciona, sin candado. La debilidad 131 de Fluid Attacks cubre la condición del servidor que lo permite: una cabecera Strict-Transport-Security ausente o de vida corta.
Evil twin de Wi-Fi
El atacante emite un punto de acceso con el nombre de una red en la que el dispositivo de la víctima ya confía. El dispositivo se asocia automáticamente y todos los paquetes posteriores pasan por el equipo del atacante. Los pentesters de Fluid Attacks usan Aircrack-ng y bettercap para este tipo de evaluación inalámbrica.
Envenenamiento de LLMNR y retransmisión NTLM
Este es el ataque man-in-the-middle que más daño hace dentro de redes corporativas, y no tiene nada que ver con el wifi de una cafetería. Cuando Windows no logra resolver un nombre por DNS, recurre a Link-Local Multicast Name Resolution y NetBIOS Name Service, que difunden la consulta al segmento local. Un atacante responde, la víctima se autentica y el atacante recibe un hash NTLMv2 para romper sin conexión o retransmitir a otro host. La debilidad 388 de Fluid Attacks señala que NTLM "can be vulnerable to several security flaws, including Relay attacks, Man in the Middle" y fuerza bruta. El pentesting interno de Fluid Attacks cubre esta técnica, junto con el robo de tickets Kerberos y los ataques IPv6.
Man-in-the-browser
Malware o una extensión maliciosa opera dentro del navegador, después de que TLS terminó. El canal está intacto y el certificado es válido; el atacante lee y reescribe la página ya descifrada. Ningún control de transporte lo detiene, y por eso cuenta como compromiso del extremo.
IP spoofing
El atacante falsifica direcciones de origen para suplantar a un host de confianza. Por sí solo rara vez produce un ataque man-in-the-middle aprovechable en redes modernas, pero sostiene las técnicas anteriores.
Una nota sobre las herramientas: mitmproxy, Wireshark y OWASP ZAP interceptan tráfico, y ninguna es por naturaleza una herramienta de ataque. La autorización es lo que separa un ataque man-in-the-middle de una evaluación.
Ataques man-in-the-middle en Fluid Attacks
Fluid Attacks evalúa las condiciones que hacen posible un ataque man-in-the-middle: en aplicaciones, en infraestructura y en las redes que sus pentesters están autorizados a evaluar. Cada debilidad se cataloga, se le asigna una severidad y se verifica tras la remediación.
Qué evaluamos y bajo qué reglas
La evaluación de interceptación se delimita y se autoriza por escrito antes de instrumentar nada, y Fluid Attacks mantiene control total del canal de comunicación entre el pentester y el objeto de evaluación. Las herramientas que hacen realista una evaluación son las mismas que usan los atacantes: en la documentación de Fluid Attacks, OWASP ZAP se describe como un "man-in-the-middle proxy", porque reproducir un ataque man-in-the-middle en condiciones controladas es justo lo que un evaluador autorizado tiene que hacer.
Cómo se ve en la práctica
Superficie | Herramientas | Cómo se ve un hallazgo |
Transporte web y de API | mitmproxy, Burp Suite Professional, OWASP ZAP | Debilidad 016: se aceptan versiones inseguras de TLS |
Canales de aplicación y servicios | Revisión de código y configuración | Debilidad 332: "Intercept communication and steal or forge requests and responses" |
Cabeceras de respuesta HTTP | Debilidad 131: falta Strict-Transport-Security | |
Tráfico de apps móviles | Frida, Objection, Mobile Application Security Testing (MAST) | Regla SAST-NATDC: un TrustManager de Kotlin que acepta cualquier certificado |
Redes inalámbricas e internas | Aircrack-ng, bettercap, Wireshark | Debilidad 388: se usa autenticación NTLM |
Superficies donde es posible un ataque man-in-the-middle, las herramientas que usan los pentesters de Fluid Attacks en cada una y la debilidad catalogada a la que mapea un hallazgo.
La debilidad de HSTS como aparece en la base de datos de Fluid Attacks, con su remediación.
Qué encuentra la evaluación manual que los escáneres no ven
En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación con 1.201 vulnerabilidades sembradas, un pentester detectó el 89,6 % con 100 % de precisión. El escáner automatizado con mejor desempeño en ese ejercicio fue el propio de Fluid Attacks, con 22,7 % de recall, equivalente al 8,8 % de la exposición al riesgo total de la aplicación medida en CVSSF. El pentester encontró en exclusiva 743 vulnerabilidades, el 86,8 % de la exposición al riesgo total.
Las fallas detrás de un ataque man-in-the-middle se reparten limpiamente a lado y lado de esa brecha. Un escáner reporta con fiabilidad una cabecera ausente o una suite criptográfica débil. Establecer que una aplicación acepta un certificado que debería rechazar, en un flujo concreto y con un cliente concreto, exige que alguien lo haga.
Qué no te van a decir las pruebas de seguridad
Un escáner marca una cabecera Strict-Transport-Security ausente o un TrustManager que confía en todo. No te dice si alguien está en el cable ahora mismo. Detectar un ataque man-in-the-middle en curso es trabajo de telemetría de red y respuesta a incidentes, no de pruebas de seguridad de aplicaciones. Fluid Attacks reporta las condiciones que hacen viable la interceptación y verifica que se corrigieron.
La misma advertencia aplica a las defensas móviles. El análisis de Fluid Attacks sobre la protección dentro de la app sostiene que activar un control no es lo mismo que corregir la falla que hay debajo: la detección de proxies maliciosos y el certificate pinning son capas sobre una base que tiene que estar sana primero.
Cómo aseguramos nuestro propio transporte
Los controles documentados de Fluid Attacks aplican a sus propios sistemas las recomendaciones de esta página, y cierran una a una las etapas de un ataque man-in-the-middle. El dominio acepta únicamente TLSv1.3 de extremo a extremo. Los orígenes se autentican mediante Authenticated Origin Pulls, un esquema de TLS mutuo respaldado por una CA privada, de modo que la capa TLS rechaza los handshakes sin un certificado firmado por esa CA. Cada handshake público usa el intercambio de claves híbrido poscuántico X25519MLKEM768. Las tres zonas principales están en la lista de precarga embebida en los navegadores, así que estos rechazan HTTP en texto claro desde la primera solicitud. Los certificados de fluidattacks.com tienen una validez de 14 días.
Salto | TLS | Autenticación de origen |
Navegador → Cloudflare | TLS 1.3 | HSTS preload, primer contacto |
Cloudflare → ALB | TLS 1.3 | mTLS, CA privada |
Cloudflare → CloudFront | TLS 1.3 | mTLS, CA privada |
CloudFront → origen S3 | TLS, SigV4 | CloudFront OAC |
Ruta de datos pública de Fluid Attacks: cada salto lleva cifrado de transporte y una verificación de identidad en el extremo receptor.
Qué detiene de verdad un ataque man-in-the-middle
Cinco controles hacen casi todo el trabajo contra un ataque man-in-the-middle, y cada uno detiene una etapa distinta. Desplegarlos sin saber cuál es cuál es como las organizaciones terminan protegidas contra el ataque que no estaban enfrentando.
Control | Qué detiene | Qué no detiene |
Validación de certificados TLS | Cualquier atacante sin un certificado que el cliente acepte | Una CA comprometida o maliciosa en el almacén de confianza |
HSTS con precarga | La primera solicitud en texto claro, antes de que los datos salgan del dispositivo | La interceptación una vez establecida una sesión TLS válida |
Certificate pinning | Una CA fraudulenta, para una app contra un servidor | La instrumentación de la app en un dispositivo que el atacante controla |
TLS mutuo | Un servidor que no puede probar su identidad al cliente, y al revés | El tráfico después de que se compromete cualquiera de los extremos |
MFA resistente a phishing | El robo de credenciales y de sesión mediante un proxy AiTM | La interceptación de tráfico que no lleva credenciales |
Qué etapa de un ataque man-in-the-middle interrumpe cada control y dónde termina cada uno.
Validación de certificados TLS
Este es el control sobre el que descansa todo lo demás. TLS da confidencialidad, integridad y autenticación del servidor, y solo la tercera detiene un ataque man-in-the-middle. Un cliente que cifra hacia una parte no verificada ha cifrado hacia el atacante.
El mecanismo se ve mejor desde el lado ofensivo. Al describir cómo se monta un *proxy* de interceptación contra una app de Android, el security analyst de Fluid Attacks Jonathan Armas señala que el certificado del proxy tiene que llegar primero a la lista de confianza del dispositivo: "Without this, we cannot intercept secure channel traffic". Esa frase es la defensa, leída al revés: un ataque man-in-the-middle sobre TLS empieza por la confianza, no por la criptografía.
La falla común no es un certificado ausente, sino una verificación desactivada. La regla SAST-NATDC de Fluid Attacks detecta implementaciones de TrustManager en Kotlin que saltan la validación de certificados. La conexión es HTTPS. La validación ya no está.
Un `TrustManager` con el método de verificación vacío acepta cualquier certificado que se le presente; la versión corregida usa el almacén de confianza del sistema.
HSTS y la lista de precarga
El RFC 6797 define el HTTP Strict Transport Security (HSTS). Su cabecera Strict-Transport-Security le indica al navegador usar HTTPS para un dominio e impide que los usuarios pasen por alto las advertencias de certificado. Cierra el SSL stripping para todas las conexiones después de la primera.
La primera conexión es el hueco, y la precarga lo cierra. Los dominios de la lista de precarga quedan compilados dentro del navegador, así que el texto claro nunca sale del dispositivo. OWASP advierte que la directiva preload tiene consecuencias permanentes: un dominio en la lista no puede volver a HTTP con rapidez.
El certificate pinning es más estrecho que su reputación
La recomendación de fijar certificados por defecto está pendiente de corrección, y OWASP es directo: "There is almost no situation where you should consider pinning" y "If it is not a native mobile application, do not pin". El certificate pinning resuelve un problema, el de una autoridad certificadora en la que no confías, para un par cliente-servidor del que controlas ambos extremos. No sobrevive a un atacante con acceso de instrumentación al dispositivo y se rompe cada vez que un certificado rota de forma inesperada.
TLS mutuo
El TLS mutuo obliga a los dos lados a probar su identidad. Es el control adecuado para el tráfico entre servicios, donde un ataque man-in-the-middle dentro de un clúster es tan plausible como uno en una red pública. El requisito 088 de Fluid Attacks pide que los sistemas que manejan información crítica para el negocio exijan certificados de cliente, y mapea a NIST SP 800-63B 5.2.5 y OWASP Top 10 A07. Fluid Attacks lo recomienda para toda comunicación entre un cliente de Model Context Protocol y un servidor remoto.
MFA resistente a *phishing*
Los kits de phishing adversary-in-the-middle montan un proxy inverso entre la víctima y el proveedor de identidad real. La víctima introduce una contraseña y un código de un solo uso, el proxy reenvía ambos, captura la cookie de sesión que devuelve el servidor y la reproduce. Los códigos enviados por SMS o generados en una app no sobreviven a esta forma de ataque man-in-the-middle. CISA describe la MFA por SMS y voz como "Vulnerable to phishing, SS7, and SIM swap attacks" y llama a FIDO/WebAuthn "the only widely available phishing-resistant authentication". La razón es el vínculo con el origen: una credencial FIDO no firma un desafío para un dominio que no coincide con su origen registrado, así que el proxy no obtiene nada.
El SSL stripping clásico y un proxy AiTM moderno, con el punto donde HSTS preload y FIDO2 interrumpen cada uno. Elaboración propia.
Cómo detectar un ataque man-in-the-middle
La detección de un ataque man-in-the-middle es conductual. Se buscan los efectos secundarios de que alguien esté en la ruta, porque la interceptación en sí no levanta ninguna alerta. La estrategia de detección DET0296 de MITRE enumera qué vigilar ante un ataque man-in-the-middle: "suspicious DNS/ARP poisoning attempts, unauthorized modifications to registry/network configuration" y "abnormal TLS downgrade activity". Sus analíticas también cubren ediciones no autorizadas de /etc/hosts y /etc/resolv.conf, difusiones ARP sospechosas y cambios de configuración en dispositivos de red.
Hay tres señales que vale la pena instrumentar primero, porque son baratas y específicas: certificados que no coinciden con lo que tu monitoreo espera para un dominio, negociaciones de versión de TLS o de cifrado que caen por debajo de tu mínimo, y respuestas ARP o DNS que cambian el mapeo de un host que controlas.
Para los usuarios, el consejo que de verdad detecta un ataque man-in-the-middle es más estrecho que la lista habitual: nunca pasar por alto una advertencia de certificado. Un navegador que reporta un nombre de host que no coincide, un certificado vencido o un emisor no confiable está describiendo la condición exacta que un ataque man-in-the-middle necesita.
Cuando falla la cadena de confianza
Los dos casos siguientes terminaron con sesiones cifradas siendo leídas, y en ninguno se rompió el cifrado. Siguen siendo la evidencia pública más clara de que un ataque man-in-the-middle derrota a HTTPS por la vía de la confianza y no de la criptografía.
DigiNotar y Superfish
En 2011, unos atacantes comprometieron a la autoridad certificadora holandesa DigiNotar y emitieron certificados en los que confiaba toda la web, incluido uno para Google. El análisis de ENISA registra que se usaron certificados falsos "para espiar a usuarios en Irán" durante dos meses. Los navegadores retiraron la confianza en DigiNotar y la empresa quebró.
En 2015, portátiles de consumo de Lenovo salieron de fábrica con adware que ejecutaba un ataque man-in-the-middle por diseño: instalaba su propia autoridad certificadora raíz en el almacén de confianza de Windows para inyectar contenido en páginas HTTPS. La alerta TA15-051A de CISA advirtió que la falla le permitía a un atacante "successfully impersonate (spoof) any website".
Los dos se diferencian en dónde ocurrió la traición. DigiNotar rompió la jerarquía pública de confianza; Superfish rompió el almacén de confianza del dispositivo. Ambos produjeron un ataque man-in-the-middle que ninguna cantidad de cifrado habría evitado.
Conclusiones
Un ataque man-in-the-middle es un problema de autenticación disfrazado de cifrado. El cifrado sin identidad verificada no protege nada, que es lo que demostraron DigiNotar y Superfish sobre sesiones que se veían seguras en la barra de direcciones.
Los controles que funcionan contra un ataque man-in-the-middle son específicos: validar certificados y nunca desactivar la verificación, enviar HSTS y precargar el dominio, exigir TLS mutuo donde ambos extremos son tuyos, y mover la autenticación a FIDO2 donde el robo de sesión es el riesgo real. El pinning es una herramienta estrecha, no un valor por defecto.
Las pruebas te dicen cuáles de estos tienes de verdad. Las debilidades detrás de un ataque man-in-the-middle —canales inseguros, versiones obsoletas de TLS, cabeceras ausentes, trust managers permisivos, NTLM heredado— se pueden encontrar antes de que las encuentre un atacante, y un ataque man-in-the-middle es una de las pocas amenazas cuya lista de correcciones es así de corta y así de específica.
Preguntas frecuentes
¿HTTPS previene los ataques man-in-the-middle?
Solo cuando la validación de certificados funciona. HTTPS cifra el canal y autentica al servidor, y es la autenticación la que bloquea un ataque man-in-the-middle. Una aplicación que desactiva la verificación de certificados, confía en una CA fraudulenta o acepta un nombre de host que no coincide está cifrando su tráfico directo hacia el atacante. La regla SAST-NATDC de Fluid Attacks existe porque la validación desactivada dentro de código HTTPS por lo demás correcto es frecuente.
¿Cómo detiene HSTS el SSL stripping?
Elimina la solicitud en texto claro de la que depende el SSL stripping. La cabecera Strict-Transport-Security le indica al navegador usar HTTPS para un dominio y le impide dejar que los usuarios pasen por alto las advertencias de certificado. Protege todas las conexiones después de la primera. La precarga cierra también la primera, y por eso Fluid Attacks inscribió sus tres zonas principales en la lista de precarga.
¿El certificate pinning previene todos los ataques man-in-the-middle?
No. OWASP hoy desaconseja el pinning en la mayoría de los casos, y afirma que "there is almost no situation where you should consider pinning" y que las aplicaciones no nativas no deberían fijar certificados. El certificate pinning defiende a un par cliente-servidor frente a una autoridad no confiable. No detiene un ataque man-in-the-middle montado desde un dispositivo que el atacante puede instrumentar, y se rompe cuando los certificados rotan.
¿La autenticación de dos factores detiene un ataque adversary-in-the-middle?
No si el segundo factor es un SMS o un código generado en una app. Un proxy AiTM reenvía el código en tiempo real y roba la cookie de sesión autenticada, así que el ataque man-in-the-middle tiene éxito con el segundo factor puesto. CISA llama a FIDO/WebAuthn "the only widely available phishing-resistant authentication", porque una credencial FIDO se niega a firmar un desafío para un dominio que no coincide con su origen registrado.
¿Fluid Attacks evalúa debilidades de man-in-the-middle?
Sí, en código de aplicación, configuración de transporte, apps móviles y evaluaciones de red autorizadas, con cada hallazgo mapeado a una debilidad catalogada y verificado tras la remediación. En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación con 1.201 vulnerabilidades sembradas, un pentester alcanzó un 89,6 % de recall con 100 % de precisión, mientras que el mejor escáner automatizado llegó al 22,7 %. Las fallas detrás de un ataque man-in-the-middle caen a ambos lados de esa brecha: los escáneres encuentran la cabecera ausente, las personas encuentran el flujo que acepta un certificado que debería rechazar.
Pon a prueba los controles que crees tener
Nuestros pentesters y escáneres revisan tu configuración de transporte, tu validación de certificados y tu autenticación como lo haría un atacante que ejecuta un ataque man-in-the-middle, para que las debilidades que hacen posible la interceptación se corrijan antes de que alguien las use. Prueba gratuita · Contáctanos.
Empieza ya con la solución de seguridad de aplicaciones de Fluid Attacks
