Casos de ataques man in the middle reales: ¿cómo pasan?

Casos reales de ataques man-in-the-middle: Wi-Fi de hotel, certificados falsos, Superfish y secuestros DNS/BGP, con ejemplos y detalle clave.

Un ataque man-in-the-middle (MITM) no es un truco de feria ni una “cosa de hackers” para películas: es una forma muy concreta de colarse en una conversación digital y ocupar el asiento del medio, el que nadie mira. Tú crees que hablas con un servicio legítimo, el servicio cree que habla contigo, y entre ambos aparece un tercero que observa, copia, modifica o redirige. Lo inquietante es lo fácil que puede llegar a parecer todo normal: la web carga, el correo entra, el candado se enciende… y aun así la conexión está siendo interceptada.

Los casos reales que se han documentado en la última etapa de Internet moderna comparten una misma música de fondo, aunque cambien los instrumentos: redes Wi-Fi de hoteles usadas como trampolín, certificados digitales falsos que permiten “ser” Google sin serlo, software preinstalado que reescribe la seguridad desde dentro del propio portátil, y golpes de infraestructura (DNS y rutas BGP) que doblan el mapa para llevarte a un sitio que se parece al auténtico. No es un único ataque, es una familia. Y lo que se rompe, casi siempre, es la confianza: en la red, en el candado, en el camino.

El patrón común detrás del hombre en medio

En la jerga, “estar en medio” suena abstracto, pero en los incidentes de verdad se ve con nitidez, como una huella en barro. Primero aparece un punto donde alguien puede controlar algo: el punto de acceso, el router, el DNS, el certificado raíz, el proxy corporativo, incluso una aplicación que se atribuye permisos que no debería. Después llega el engaño suave, el de no levantar sospechas: un portal cautivo de hotel, una actualización “recomendada”, una ventana de certificado que el usuario no entiende, una página clonada con el mismo aspecto, o una ruta por Internet que, durante un rato, pasa por manos ajenas. Y por último, el objetivo: credenciales, cookies de sesión, contenido de correo, tráfico de banca, datos internos de empresa, o directamente dinero si hay un monedero de criptomonedas de por medio.

En los incidentes más finos, el atacante no necesita romper el cifrado. Al revés: se apoya en él. Si consigue que tu dispositivo confíe en su certificado, o que tu navegador acepte una autoridad intermediaria, la conexión sigue siendo HTTPS, pero el que tiene las llaves ya no es solo el sitio legítimo. Es una idea incómoda porque desmonta el consuelo rápido del candado: el candado no garantiza que nadie mire, garantiza que solo miran quienes tienen la llave correcta. Y ahí está el filo: ¿quién tiene la llave?

También hay MITM sin candado, por puro oportunismo: redes abiertas donde alguien hace ARP spoofing (suplantación dentro de la red local) para que el tráfico pase por su máquina, puntos de acceso “gemelos” que imitan el nombre del Wi-Fi auténtico, ataques de degradación en los que se fuerza a la víctima a caer en HTTP o en versiones menos seguras del protocolo. Suena técnico, pero en la práctica es mundano: conectas donde no debes, aceptas lo que no entiendes, y el camino cambia bajo tus pies.

Cuando el candado miente: DigiNotar, Comodo y compañía

Si hay un capítulo que convirtió el MITM en una noticia global de seguridad, fue el de los certificados fraudulentos emitidos por fallos en autoridades certificadoras, las piezas que hacen posible que un navegador confíe en que “este sitio es quien dice ser”. En el caso de DigiNotar, una autoridad de certificación con base en Países Bajos, se detectó la emisión de certificados falsos para servicios muy conocidos, incluidos dominios asociados a Google. El asunto no era solo técnico; tenía un eco político y social porque se vinculó a intentos de interceptación que afectaban a usuarios en entornos sensibles. El mensaje que dejó fue duro: si alguien logra introducir un certificado “válido” a ojos del navegador, puede montar un MITM con traje de gala, sin alertas, sin chirridos, con la interfaz sonriendo.

Algo parecido, con matices distintos, ocurrió con el incidente de Comodo, donde se emitieron certificados fraudulentos para dominios de alto perfil. En estos episodios, lo relevante no es recrearse en el inventario, sino entender la palanca: el atacante no necesita tomar el control de tu dispositivo si consigue engañar a la cadena de confianza que tu dispositivo ya trae de fábrica. El navegador está diseñado para creer, y creer rápido. Cuando esa creencia se contamina, el MITM deja de ser “un tío en el Wi-Fi del bar” y se convierte en una posibilidad a escala masiva.

Luego están los casos de autoridades intermedias, los famosos sub-CAs, que son como un poder delegado: no son la raíz última, pero pueden emitir certificados como si lo fueran para muchos propósitos. Ahí se encuadra el episodio de TURKTRUST, donde se detectó el uso de un certificado para un dominio de Google asociado a una autoridad subordinada. La parte jugosa no es el nombre del país ni la marca del certificado; es la idea de que un error, una mala custodia o una fuga en un eslabón “intermedio” puede abrir una puerta enorme. Parecía una incidencia burocrática, pero el efecto práctico se parecía demasiado a una herramienta para interceptar tráfico.

También se habló de certificados indebidos ligados a estructuras estatales o semiestatales en Francia, con el nombre de ANSSI apareciendo en análisis técnicos que describían el uso de certificados no autorizados para dominios de Google dentro de redes internas. Ese detalle —“red interna”— importa, porque muestra una variante habitual: no siempre se espía a todo el mundo; a veces el MITM se usa para vigilar dentro de una organización, para inspeccionar tráfico corporativo, para controlar accesos. La frontera entre “seguridad” e “intercepción” se vuelve borrosa, y la tecnología es la misma.

El certificado “nacional” y la interceptación a gran escala

Hay un caso que no necesita florituras porque es casi literal: el intento de imponer un certificado de seguridad “nacional” para interceptar tráfico cifrado. En Kazajistán se documentó la distribución de un certificado raíz que, si se instalaba, permitía a la infraestructura controlada por el país descifrar y volver a cifrar conexiones HTTPS. Dicho de forma llana: el Estado podía ponerse en medio de cualquier visita web, con capacidad de leer y modificar. Lo que convirtió aquel episodio en noticia internacional fue la reacción coordinada de navegadores y plataformas —Chrome, Firefox, Safari— que bloquearon ese certificado incluso cuando el usuario lo hubiera instalado manualmente. Es un punto clave: la batalla por el MITM no solo se libra con malware y delincuencia, también con decisiones de producto y con quién decide qué certificados merecen confianza.

Este tipo de intervención deja otra lección: el MITM puede presentarse como “inspección”, “seguridad”, “control de amenazas”. La tecnología funciona igual; cambian las etiquetas. Y cuando el debate se enreda, el dato desnudo es siempre el mismo: un certificado raíz instalado en el dispositivo equivale a una llave maestra. Si esa llave la controla un tercero, el tercero tiene el poder de mirar el tráfico cifrado como si estuviera en la habitación.

El hotel como trampolín: DarkHotel y la red que decide

En el imaginario popular, el MITM es un tipo con capucha en una cafetería. La realidad ha sido más sofisticada y, por momentos, más elegante: hoteles de lujo convertidos en plataforma de ataques dirigidos. Ahí aparece DarkHotel, un grupo o campaña (según el análisis de distintas firmas) que se hizo famoso por comprometer redes de hoteles y servir malware a huéspedes concretos, no a todos. Esa selectividad es importante porque delata intención: se buscaba a ejecutivos, perfiles con acceso a información sensible, gente que viaja con portátil corporativo y contraseñas de trabajo en la cabeza.

El modo de operar descrito en esos análisis tiene un punto teatral: el huésped entra en el Wi-Fi, aparece un portal, se sugiere instalar una actualización o un componente “necesario”, y lo que llega no es lo que promete. La red del hotel, que debería ser un servicio neutral, actúa como intermediario activo. En un MITM así, la infraestructura no es solo el escenario, es un actor. Y el atacante no necesita disparar a ciegas: espera a que la víctima haga lo lógico, conectarse para trabajar, y le ofrece una mano envenenada.

Aquí encaja la idea del punto de acceso gemelo (evil twin), una técnica tan vieja como efectiva: crear un Wi-Fi con el mismo nombre que el legítimo, una potencia de señal atractiva, y dejar que los dispositivos se conecten “por costumbre”. No hace falta magia, hace falta oportunismo. Una vez dentro, el atacante puede forzar rutas, manipular DNS local, capturar sesiones si hay tráfico sin cifrar, o empujar a la víctima hacia páginas falsas con una naturalidad que asusta. En hoteles y aeropuertos, el problema no es que sean sitios “malos”, es que son lugares donde el usuario está cansado, con prisa, y donde la red es un bien común con demasiadas manos cerca.

También hay un matiz menos vistoso, más de taller: el ARP spoofing dentro de una red local. El atacante se hace pasar por el router, el router por el atacante, y el tráfico empieza a circular por un equipo interpuesto. Esto puede servir para espiar, pero también para manipular descargas, sustituir paquetes, inyectar scripts, o intentar degradar conexiones. A veces el ataque falla y se nota; otras veces, no. En incidentes reales, la diferencia la marca un detalle feo: cuánto control tenía el atacante sobre el punto central de la red y cuánta disciplina de cifrado había en los servicios que la víctima usa.

Un certificado dentro del portátil: Superfish en Lenovo

Pocas historias ilustran mejor la crueldad doméstica del MITM que Superfish, el software publicitario que apareció preinstalado en determinados portátiles de Lenovo y que terminó siendo señalado por su capacidad de interceptar tráfico HTTPS. La mecánica, simplificada sin perder lo esencial, era esta: para insertar publicidad en páginas cifradas, el software instalaba un certificado raíz propio en el sistema. Con eso, podía presentar al navegador certificados “válidos” generados al vuelo y actuar como un proxy que descifra, lee, modifica y vuelve a cifrar. En otras palabras, un MITM local, con apariencia de función comercial.

Lo más grave no era solo la existencia del proxy, sino cómo estaba gestionada la confianza: se habló de certificados no únicos, de claves privadas expuestas o recuperables, de un diseño que, por sí mismo, abría la puerta a que cualquier atacante en la misma red pudiera suplantar sitios con facilidad si conseguía aprovechar esa debilidad. Es el tipo de problema que da vértigo porque rompe la intuición: el usuario cree que el riesgo está “fuera”, en Internet; aquí el intermediario está dentro, en el sistema operativo, en la tienda de certificados, en la base misma de la seguridad del navegador.

Superfish no fue un caso aislado en espíritu. Se identificaron otros productos y módulos (a menudo asociados a componentes de interceptación publicitaria) con patrones parecidos: instalar un certificado raíz, interceptar HTTPS, justificarlo como “optimización” o “seguridad”, y dejar un agujero que no debería existir. El nombre de Lenovo quedó pegado al caso por visibilidad, pero la lección es más amplia: cualquier software con capacidad de instalar una autoridad de certificación en tu equipo puede convertir tu navegador en un cómplice involuntario. Y eso es, por definición, un hombre en medio con carnet de residente.

En estos casos, la noticia no es solo “hubo un fallo”, sino el choque cultural: fabricantes y distribuidores descubriendo que la publicidad insertada “a lo bruto” no es un tema de marketing, es un tema de criptografía aplicada. El MITM deja de ser una amenaza externa y se vuelve un problema de cadena de suministro, de decisiones de producto, de controles de calidad. Un portátil nuevo, recién sacado de caja, podía traer consigo una forma de interceptación que normalmente asociamos a ataques.

El mapa de Internet se dobla: Route 53 y MyEtherWallet

Hay ataques MITM que no se apoyan en Wi-Fi ni en certificados locales, sino en infraestructura global: manipulan el camino. Aquí entran DNS y BGP. DNS traduce nombres a direcciones; BGP decide por dónde se enruta el tráfico entre redes. Si alguien secuestra una ruta BGP o consigue que un conjunto de resolvers entregue direcciones falsas durante un tiempo, puede redirigir a usuarios a servidores controlados por el atacante. A ojos de la víctima, todo parece normal: escribe la dirección de siempre. La diferencia es que el nombre ya no apunta al lugar correcto.

El caso más citado en este terreno es el incidente vinculado a MyEtherWallet, donde se describió un ataque que combinaba secuestro de rutas y manipulación de DNS a través de infraestructura asociada a un servicio de resolución ampliamente usado, como Route 53. El objetivo, sin rodeos, era económico: robar fondos de usuarios que entraban en una web popular para gestionar activos. El atacante no necesitó hackear el servicio legítimo; le bastó con crear una copia convincente, ponerla en el camino y esperar. Eso también es MITM, aunque el resultado se parezca a phishing: la clave está en que la víctima no “se equivoca” voluntariamente, la red la lleva.

La parte interesante de este tipo de incidentes es su temporalidad: suelen durar lo suficiente para hacer daño, y luego desaparecen, como una marea. Los informes técnicos hablan de ventanas de tiempo, de rutas anunciadas desde sistemas autónomos inesperados, de tráfico que de pronto toma un desvío raro. Es un MITM de carretera: no te cambian el coche, te cambian la autopista. Y mientras el mapa se corrige, el atacante ya ha cobrado.

Este capítulo también explica por qué, en ciberseguridad, hay historias que suenan “demasiado grandes” y sin embargo son terrenalmente ciertas. BGP nació en una Internet más confiada y ha ido arrastrando esa herencia: no siempre hay verificación fuerte de quién puede anunciar qué rutas. Cuando un actor malicioso aprovecha esa debilidad, puede construir un intermediario a escala regional. No es un ataque que se haga desde un portátil en un bar; es un movimiento que toca operadores, carriers, acuerdos entre redes. Y por eso, cuando ocurre, el relato tiene nombres propios de empresas, de proveedores y de piezas de infraestructura que normalmente nadie mira.

Qué falló en estos casos y qué cambió después

Mirados en conjunto, estos casos de ataques manin the middle reales dejan un mapa de fallos recurrentes, sin necesidad de convertirlo en manual ni en sermón. Uno: la confianza depositada en autoridades certificadoras que, cuando fallan, fallan a lo grande. DigiNotar, Comodo, TURKTRUST, incidentes con intermediarias asociadas a organismos estatales… cada uno con su historia, pero con el mismo efecto: si un certificado indebido entra en el sistema, el MITM se vuelve elegante, casi invisible. Dos: la instalación de certificados raíz en equipos de usuario —por adware, por inspección corporativa mal diseñada, por presión institucional— que convierte el dispositivo en territorio colonizado. Superfish es el ejemplo más famoso porque era tangible: el intermediario viajaba con el portátil. Tres: la infraestructura de nombres y rutas, DNS y BGP, que puede ser manipulada para redirigir tráfico sin tocar el servidor legítimo; lo de MyEtherWallet mostró esa posibilidad con un coste real y con un actor que pensó como delincuente práctico, no como investigador.

A partir de ahí, se han visto cambios que, sin ser una varita mágica, han estrechado el margen del atacante. Navegadores y sistemas han endurecido la reacción ante certificados sospechosos, han incorporado listas de bloqueo, han acelerado la retirada de confianza a CAs que no cumplan estándares, y han empujado tecnologías como HSTS para reducir los ataques de degradación a HTTP. También ha crecido la cultura de la transparencia en certificados y la vigilancia comunitaria, porque el problema no se resuelve solo con buenas intenciones: se resuelve detectando rápido cuando alguien intenta “ser” quien no es.

En redes públicas, el cifrado se ha extendido y eso ha cerrado la puerta a muchas interceptaciones triviales de sesiones, aquellas épocas en que capturar cookies en un Wi-Fi abierto era una posibilidad realista para un atacante mediocre. Pero el MITM no desaparece; se desplaza hacia capas donde el control sigue siendo posible: el certificado raíz, el punto de acceso comprometido, la ruta manipulada, la app que no valida bien. En seguridad ocurre a menudo: cuando se refuerza una puerta, se prueba otra. Y por eso, cuando se habla de MITM con seriedad, lo que importa no es repetir la definición, sino mirar los hechos con nombres propios: DigiNotar como símbolo del colapso de confianza en una CA, DarkHotel como ejemplo de infraestructura “de servicio” convertida en plataforma de espionaje selectivo, Superfish como recordatorio de que el enemigo puede venir preinstalado, Route 53 y MyEtherWallet como demostración de que el mapa de Internet también se puede falsificar.

El hilo que los une es incómodo precisamente porque es cotidiano: muchas de estas historias no empiezan con un fallo espectacular, sino con algo que el usuario hace cada día. Conectarse a un Wi-Fi, aceptar un certificado, abrir una web conocida, comprar un portátil. El intermediario, cuando aparece, no lleva cartel. Lleva rutina. Y esa es la razón por la que, pese a los avances, los MITM siguen siendo noticia cuando explotan: porque atacan la parte más humana de la tecnología, la que da por hecho que el camino es el de siempre y que el candado significa lo que creemos que significa.

🔎 Contenido Verificado ✔️

Este artículo ha sido redactado basándose en información procedente de fuentes oficiales y confiables, garantizando su precisión y actualidad. Fuentes consultadas: INCIBE, CCN-CERT, Google Security Blog, Mozilla Security Blog, CISA, Kaspersky, ThousandEyes, Internet Society, ENISA.