Mirai y el Ataque a la IoT (2016)
En 2016, tres estudiantes universitarios de 21 años crearon Mirai para atacar servidores de Minecraft. Su botnet de dispositivos IoT con credenciales por defecto generó el DDoS más devastador de la historia: 1,2 Tbps contra Dyn, dejando sin servicio a Twitter, Netflix, Reddit y GitHub durante horas.
Septiembre de 2016: un periodista se queda sin web
El 20 de septiembre de 2016, el sitio KrebsOnSecurity.com recibió un ataque DDoS de 620 Gbps. Brian Krebs, el periodista de ciberseguridad más conocido del mundo, llevaba años investigando y exponiendo a cibercriminales. Su blog estaba protegido por Akamai, uno de los mayores proveedores de CDN del planeta, que ofrecía el servicio pro bono como gesto de apoyo al periodismo.
620 Gbps era una cifra sin precedentes. El mayor ataque DDoS documentado hasta ese momento había sido de unos 300 Gbps. Akamai absorbió el tráfico durante unos días, pero la empresa calculó que mantener la protección le costaría millones de dólares. Tomaron una decisión empresarial: retiraron la protección gratuita de Krebs.
Un periodista que investigaba cibercriminales se quedó sin sitio web porque ningún proveedor comercial podía absorber el volumen de ataque. Google intervino con su programa Project Shield, diseñado específicamente para proteger a periodistas y organizaciones de derechos humanos contra censura mediante DDoS. Krebs volvió a estar online.
Pero la pregunta quedaba abierta: ¿de dónde salían 620 Gbps de tráfico de ataque?
La respuesta era absurda. Cámaras de seguridad. Grabadores de vídeo. Routers domésticos. Cientos de miles de dispositivos "inteligentes" que nadie había protegido con una contraseña decente.
El Internet de las Cosas (sin seguridad)
Para entender Mirai hay que entender el estado de la IoT en 2016. La industria de dispositivos conectados llevaba años en expansión acelerada. Gartner estimaba 6.400 millones de dispositivos IoT conectados ese año, con proyecciones de 20.000 millones para 2020. Cámaras IP, termostatos, monitores de bebé, routers, frigoríficos, bombillas, cerraduras, todo se conectaba a Internet.
El problema era que la mayoría de estos dispositivos se fabricaban con una filosofía de "conectar y olvidar". Los fabricantes priorizaban el coste y la velocidad de comercialización sobre la seguridad. El resultado era predecible:
| Problema de seguridad IoT | Prevalencia en 2016 |
|---|---|
| Credenciales por defecto (admin/admin, root/root) | Prácticamente universal |
| Telnet abierto al exterior (puerto 23) | Millones de dispositivos |
| Sin mecanismo de actualización de firmware | Mayoría de dispositivos baratos |
| Sin cifrado en comunicaciones | Común en cámaras IP y DVRs |
| Mismas credenciales hardcodeadas en todo el modelo | Estándar en fabricantes chinos de bajo coste |
| Sin firewall ni segmentación de red | Conectados directamente a Internet |
El fabricante que mejor ilustra el problema era XiongMai Technologies, una empresa china cuyos componentes (placas, firmware, software) se integraban en cámaras IP y DVRs de decenas de marcas diferentes. Todos los dispositivos con componentes XiongMai compartían las mismas credenciales por defecto hardcodeadas en el firmware. Incluso si el usuario cambiaba la contraseña desde la interfaz web, las credenciales de telnet seguían siendo las originales.
Millones de dispositivos. Misma contraseña. Accesibles desde Internet. Era cuestión de tiempo.
Los creadores: tres estudiantes y una guerra de Minecraft
La historia de quién creó Mirai es uno de los giros más irónicos de la ciberseguridad. El botnet que provocaría el mayor ataque DDoS de la historia no fue obra de un grupo APT estatal, ni de una organización criminal sofisticada, ni de hacktivistas con agenda política.
Fue obra de tres estudiantes universitarios de 21 años obsesionados con Minecraft.
Paras Jha estudiaba informática en Rutgers University (New Jersey). Operaba un servidor de Minecraft y ofrecía servicios de protección anti-DDoS bajo el nombre de ProTraf Solutions. Josiah White era su socio, experto en escaneo de redes y desarrollo de malware. Dalton Norman completaba el trío, especializado en la identificación de vulnerabilidades zero-day en dispositivos IoT.
El mercado de servidores de Minecraft en 2016 movía cantidades sorprendentes de dinero. Los servidores populares facturaban decenas de miles de dólares mensuales por donaciones y compras in-game. Los ataques DDoS entre operadores rivales eran habituales: si tumbabas el servidor competidor, sus jugadores migraban al tuyo. Era una guerra comercial digital a pequeña escala.
Jha, White y Norman construyeron Mirai como herramienta para esa guerra. La lógica era doble: atacar servidores rivales para robar jugadores, y simultáneamente vender servicios de "protección DDoS" a los mismos servidores que ellos atacaban. Un esquema de extorsión clásico disfrazado de servicio legítimo.
Lo que no anticiparon fue la escala que alcanzaría su herramienta.
Anatomía técnica de Mirai
Mirai era elegante en su simplicidad. No explotaba vulnerabilidades sofisticadas ni usaba técnicas de evasión avanzadas. Su poder residía en la escala de dispositivos vulnerables y en la eficiencia de su código.
Fase 1: escaneo y fuerza bruta
Mirai escaneaba Internet en busca de dispositivos con el puerto 23 (telnet) abierto. Cuando encontraba uno, intentaba autenticarse usando una tabla de 62 pares de usuario/contraseña, todos credenciales por defecto de fabricantes de dispositivos IoT.
| Usuario | Contraseña | Dispositivos afectados |
|---|---|---|
| root | xc3511 | Cámaras IP XiongMai |
| root | vizxv | Cámaras IP Dahua |
| admin | admin | Routers genéricos |
| root | default | Varios fabricantes |
| root | juantech | DVRs específicos |
| root | 123456 | Routers domésticos |
| root | password | Dispositivos genéricos |
| admin | (vacío) | Routers Linksys/Netgear |
| root | root | Dispositivos Linux genéricos |
| guest | guest | DVRs y NVRs |
La tabla completa incluía credenciales para cámaras Dahua, Hikvision, Samsung, routers ZTE, Huawei, ZyXEL y docenas de fabricantes más. Sesenta y dos combinaciones cubrían la inmensa mayoría de dispositivos IoT expuestos en Internet.
Fase 2: infección
Una vez autenticado, Mirai determinaba la arquitectura del procesador del dispositivo (ARM, MIPS, x86, PowerPC, SuperH, SPARC) y descargaba el binario correspondiente. El malware estaba compilado para múltiples arquitecturas porque los dispositivos IoT usan procesadores diversos, a diferencia de los PCs que son casi exclusivamente x86/x64.
El proceso de infección seguía estos pasos:
- Autenticación por telnet con credenciales por defecto
- Detección de arquitectura del procesador (
cat /proc/cpuinfo) - Descarga del payload desde un servidor de distribución
- Ejecución del binario en memoria
- Eliminación del binario del disco (para dificultar el análisis forense)
- Cierre del puerto telnet (para evitar que otro botnet infectara el mismo dispositivo)
El último punto era revelador: Mirai competía activamente con otros botnets IoT. Al cerrar telnet tras infectar un dispositivo, impedía que competidores como BASHLITE o Hajime pudieran reclamar la misma máquina.
Fase 3: persistencia (o falta de ella)
Un detalle técnico importante: Mirai no tenía persistencia. El malware se ejecutaba solo en memoria RAM. Un simple reinicio del dispositivo lo eliminaba. Pero como el escaneo de Mirai era continuo, un dispositivo reiniciado se reinfectaba en minutos. La única forma de proteger un dispositivo era cambiar las credenciales por defecto o desconectarlo de Internet.
Fase 4: comando y control
Los bots infectados se conectaban a un servidor C2 centralizado controlado por los operadores. Desde allí, Jha y sus socios podían dirigir ataques DDoS usando múltiples vectores:
| Vector de ataque | Protocolo | Descripción |
|---|---|---|
| UDP flood | UDP | Inundación masiva de paquetes UDP |
| SYN flood | TCP | Saturación de conexiones TCP half-open |
| ACK flood | TCP | Abuso del handshake TCP |
| GRE flood | GRE | Encapsulación de tráfico para amplificación |
| DNS water torture | DNS | Consultas aleatorias a subdominios inexistentes |
| HTTP flood | HTTP | Peticiones GET/POST legítimas a alta velocidad |
| VSE query | UDP | Explotación del protocolo Valve Source Engine (juegos) |
El vector VSE era particularmente relevante: estaba diseñado específicamente para atacar servidores de juegos, confirmando el origen del malware en la guerra de Minecraft.
Los tres ataques que cambiaron Internet
Ataque 1: OVH (septiembre de 2016)
El 19 de septiembre de 2016, Mirai lanzó un ataque masivo contra OVH, el mayor proveedor de hosting de Francia y uno de los más grandes de Europa. El ataque alcanzó un pico de 1,1 Tbps (terabits por segundo), el mayor registrado hasta entonces.
El objetivo no era OVH como empresa. El objetivo era un cliente específico de OVH que operaba un servicio anti-DDoS para servidores de Minecraft. Octave Klaba, fundador de OVH, publicó en Twitter los datos del ataque en tiempo real, mostrando cómo 145.607 cámaras IP y DVRs generaban tráfico de ataque.
Ataque 2: KrebsOnSecurity (septiembre de 2016)
Al día siguiente, 20 de septiembre, Mirai atacó KrebsOnSecurity.com con 620 Gbps. Krebs había publicado investigaciones sobre servicios de DDoS-for-hire (vDOS, entre otros), y el ataque fue una represalia directa. La escala del ataque obligó a Akamai a retirar su protección, y solo la intervención de Google Project Shield mantuvo el sitio online.
Krebs, con su tenacidad habitual, no se detuvo. Siguió investigando y fue fundamental para la identificación posterior de los autores de Mirai.
Ataque 3: Dyn (21 de octubre de 2016)
El 21 de octubre de 2016, Mirai atacó Dyn (ahora parte de Oracle), uno de los principales proveedores de DNS gestionado de Estados Unidos. Este ataque fue diferente a los anteriores en escala y en impacto.
Dyn proporcionaba resolución DNS para centenares de sitios web de primer nivel. Al atacar la infraestructura DNS en lugar de un sitio individual, Mirai provocó un efecto cascada que dejó inaccesibles a decenas de servicios durante horas.
| Servicio afectado | Tipo | Duración de la interrupción |
|---|---|---|
| Red social | Varias horas | |
| Netflix | Streaming | Varias horas |
| Agregador | Varias horas | |
| GitHub | Desarrollo | Varias horas |
| Spotify | Música | Varias horas |
| CNN | Noticias | Varias horas |
| The New York Times | Noticias | Varias horas |
| PayPal | Pagos | Varias horas |
| Amazon (parcial) | E-commerce | Intermitente |
| Airbnb | Turismo | Varias horas |
El ataque se produjo en tres oleadas a lo largo del día, con aproximadamente 100.000 bots IoT generando un volumen estimado de 1,2 Tbps. El Departamento de Seguridad Nacional de Estados Unidos (DHS) y el FBI abrieron investigaciones inmediatas. Brevemente se especuló con la posibilidad de un ataque de estado-nación contra la infraestructura de Internet estadounidense.
La realidad era más prosaica. Para cuando Dyn fue atacado, el código fuente de Mirai ya se había publicado online, y múltiples actores estaban operando sus propias instancias del botnet. La atribución exacta del ataque a Dyn nunca se estableció de forma concluyente, aunque las investigaciones apuntaron a un grupo que operaba bajo el pseudónimo "BackConnect".
La liberación del código fuente
El 30 de septiembre de 2016, diez días después de los ataques contra OVH y Krebs, un usuario llamado "Anna-senpai" publicó el código fuente completo de Mirai en el foro HackForums. Anna-senpai era Paras Jha.
La publicación del código fue una decisión calculada. Jha sabía que las investigaciones se estaban acercando (Krebs estaba publicando artículos cada vez más detallados sobre la infraestructura de Mirai). Al liberar el código, Jha pretendía crear "ruido": si cientos de personas podían operar Mirai, atribuir los ataques originales a una persona específica se volvía mucho más difícil.
El post de Anna-senpai en HackForums decía:
"With Mirai, I usually pull max 380k bots from telnet alone. However, after the Kreb DDoS, ISPs been slowly shutting down and cleaning up their act. Today, max pull is about 300k bots, and dropping."
La publicación incluía el código fuente del bot (C), del servidor C2 (Go), de la base de datos de credenciales y de las herramientas de escaneo. Era un paquete completo listo para compilar y desplegar.
El efecto fue inmediato. En las semanas siguientes, docenas de variantes de Mirai aparecieron en Internet:
| Variante | Año | Mejora principal |
|---|---|---|
| Satori | 2017 | Explotación de vulnerabilidades en routers Huawei (CVE-2017-17215) |
| Okiru | 2018 | Enfocado en procesadores ARC (dispositivos industriales) |
| Masuta | 2018 | Exploit de routers D-Link (HNAP) |
| OMG | 2018 | Convierte dispositivos en servidores proxy |
| Wicked | 2018 | Cadena de múltiples exploits IoT |
| Hakai | 2018 | Enfocado en routers Realtek y Huawei |
| Mozi | 2019 | Protocolo DHT (BitTorrent) para C2 descentralizado |
| Echobot | 2019 | Más de 70 exploits integrados |
| Dark Nexus | 2020 | Sistema de puntuación de bots por rendimiento |
| BotenaGo | 2021 | Escrito en Go, 30+ exploits |
La ironía de la situación era evidente. Lo que empezó como una herramienta para guerras de Minecraft se convirtió en la plantilla para una generación entera de botnets IoT. Cada variante añadía nuevas vulnerabilidades, nuevos vectores de ataque y nuevas técnicas de evasión, pero el núcleo del código seguía siendo el que tres estudiantes universitarios habían escrito en sus dormitorios.
La investigación y la caída
Brian Krebs fue el primero en conectar los puntos. En enero de 2017, publicó un artículo titulado "Who is Anna-Senpai, the Mirai Worm Author?" donde identificaba a Paras Jha como el probable autor. La investigación se basaba en patrones de actividad online, conexiones entre pseudónimos, registros de dominios y la relación con ProTraf Solutions.
El FBI, liderado por el agente especial Elliott Peterson (el mismo que había investigado el caso GameOver Zeus), ya estaba siguiendo la misma pista. La cooperación entre Krebs, investigadores de seguridad de Akamai, Cloudflare, Google y Flashpoint Intelligence, y el FBI, permitió construir un caso sólido.
En diciembre de 2017, Paras Jha, Josiah White y Dalton Norman se declararon culpables ante un tribunal federal en Alaska de cargos de fraude informático bajo el Computer Fraud and Abuse Act (CFAA). Los tres habían cooperado extensivamente con el FBI desde su identificación, proporcionando información técnica sobre otras amenazas cibernéticas.
La sentencia fue sorprendentemente leve:
| Acusado | Sentencia | Servicio comunitario | Multa |
|---|---|---|---|
| Paras Jha | 5 años de libertad condicional | 2.500 horas | 127.000 USD |
| Josiah White | 5 años de libertad condicional | 2.500 horas | 127.000 USD |
| Dalton Norman | 5 años de libertad condicional | 2.500 horas | 127.000 USD |
Ninguno fue a prisión. La cooperación con el FBI fue el factor determinante. Los tres trabajaron con las autoridades para identificar y mitigar otras amenazas, lo que el tribunal consideró un atenuante significativo.
Jha también se declaró culpable por separado de realizar ataques DDoS contra la red de Rutgers University entre 2014 y 2016, ataques que habían interrumpido los sistemas de registro y exámenes de la universidad. Por estos cargos recibió seis meses adicionales de arresto domiciliario.
Técnicas MITRE ATT&CK
Mirai utilizaba un conjunto reducido pero eficaz de técnicas que mapeaban directamente al framework MITRE ATT&CK:
| Técnica | ID MITRE | Uso en Mirai |
|---|---|---|
| Brute Force: Password Guessing | T1110.001 | Tabla de 62 credenciales por defecto contra telnet |
| Network Denial of Service: Direct Network Flood | T1498.001 | UDP flood, SYN flood, ACK flood, GRE flood |
| Network Denial of Service: Reflection Amplification | T1498.002 | DNS water torture contra servidores recursivos |
| Botnet | T1583.005 | Red de 300.000-600.000 dispositivos IoT comprometidos |
| Exploit Public-Facing Application | T1190 | Telnet expuesto en dispositivos IoT (variantes posteriores) |
| System Information Discovery | T1082 | Detección de arquitectura del procesador antes de descargar payload |
La simplicidad de las técnicas era parte de la lección. Mirai no necesitaba zero-days ni exploits sofisticados. Las credenciales por defecto eran suficientes para construir el arma DDoS más poderosa de la historia.
El legado: un antes y un después para la IoT
Mirai fue el punto de inflexión que obligó a la industria, los gobiernos y los consumidores a tomarse en serio la seguridad de los dispositivos conectados.
Respuesta regulatoria
La primera ley directamente inspirada por Mirai fue la SB-327 de California (firmada en septiembre de 2018, efectiva desde enero de 2020). Esta ley exigía que todos los dispositivos IoT vendidos en California incorporaran medidas de seguridad "razonables", incluyendo la obligación de que cada dispositivo tuviera una contraseña única de fábrica o requiriera al usuario configurar una contraseña en el primer uso. Se acabaron los admin/admin compartidos entre millones de unidades.
A nivel internacional, la respuesta regulatoria fue más lenta pero más ambiciosa:
| Regulación | Jurisdicción | Año | Requisito principal |
|---|---|---|---|
| SB-327 | California, EE.UU. | 2018 | Contraseñas únicas por dispositivo |
| PSTI Act | Reino Unido | 2022 | Prohibición de credenciales por defecto, divulgación de vulnerabilidades |
| ETSI EN 303 645 | Europa (estándar) | 2020 | 13 requisitos de seguridad IoT |
| Cyber Resilience Act | Unión Europea | 2024 | Seguridad obligatoria en todo el ciclo de vida del producto |
| NIST IoT Framework | EE.UU. (federal) | 2020 | Directrices de seguridad para fabricantes IoT |
Respuesta de la industria
Los fabricantes de dispositivos IoT (al menos los más reputados) comenzaron a implementar cambios:
- Contraseñas únicas por dispositivo impresas en etiquetas físicas, como ya hacían los routers de ISPs europeos
- Actualizaciones automáticas de firmware sin intervención del usuario
- Deshabilitación de telnet por defecto, priorizando SSH o interfaces web con HTTPS
- Programas de divulgación de vulnerabilidades con recompensas para investigadores
- Segmentación de red recomendada en manuales y guías de instalación
Sin embargo, el problema estructural persistía en 2026. Millones de dispositivos baratos fabricados antes de 2018 seguían conectados a Internet sin posibilidad de actualización. El ciclo de vida de una cámara de seguridad o un DVR es de 5 a 10 años. Los dispositivos vulnerables a Mirai seguían operativos una década después, y las variantes del botnet seguían explotándolos.
La ironía final
Lo más revelador de Mirai no es la sofisticación del ataque, sino la trivialidad de su origen. El DDoS más devastador de la historia, el que dejó sin servicio a Twitter, Netflix, Reddit, GitHub y decenas de servicios más, el que provocó investigaciones del DHS y el FBI, el que inspiró legislación en medio mundo, nació de una pelea entre adolescentes por servidores de Minecraft.
Tres estudiantes de 21 años, con conocimientos técnicos moderados pero con acceso a millones de dispositivos protegidos con "admin/admin", demostraron que la infraestructura crítica de Internet era tan fuerte como su eslabón más débil. Y ese eslabón era una cámara de seguridad china con la contraseña "xc3511".
Mirai no explotó una vulnerabilidad en el sentido técnico del término. Explotó la negligencia sistemática de una industria entera que consideraba la seguridad como un coste innecesario en la carrera por conectar todo a Internet lo más rápido y barato posible.
Mirai en el contexto de la serie
Mirai representa la convergencia de dos tendencias que habíamos visto evolucionar por separado en capítulos anteriores. Por un lado, los botnets: desde las redes IRC primitivas de los años 2000, pasando por Storm Worm y su arquitectura P2P, hasta Conficker y su resiliencia contra takedowns. Por otro, la explosión de dispositivos conectados sin seguridad, un problema que Mirai convirtió en crisis visible.
Si Stuxnet demostró que el malware podía causar destrucción física, Mirai demostró algo diferente pero igualmente importante: que dispositivos aparentemente inofensivos (cámaras, routers, grabadores de vídeo) podían convertirse en armas capaces de interrumpir servicios fundamentales de Internet. No hacía falta un estado-nación con recursos ilimitados. Bastaban tres estudiantes y una tabla de contraseñas.
El siguiente capítulo de la serie abordará WannaCry y NotPetya (2017), dos ataques que llevarían el concepto de disrución masiva a un nivel completamente nuevo, con hospitales paralizados, fábricas detenidas y miles de millones de dólares en pérdidas.
Preguntas frecuentes
Libros recomendados
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.