Mirai y sus Variantes: La Botnet IoT que Cambió Internet

El nacimiento de una amenaza masiva

El 20 de septiembre de 2016, el blog de seguridad de Brian Krebs (KrebsOnSecurity) sufrió un ataque DDoS de 620 Gbps, uno de los mayores registrados hasta esa fecha. Akamai, que proporcionaba protección DDoS gratuita al blog, tuvo que retirarlo de su red porque el ataque saturaba su infraestructura. Pocas semanas después, el 21 de octubre, un ataque contra Dyn DNS alcanzó un volumen estimado de 1,2 Tbps, dejando inaccesibles durante horas servicios como Twitter, Netflix, Reddit, GitHub, PayPal y Spotify en la costa este de Estados Unidos.

Detrás de ambos ataques estaba Mirai, una botnet compuesta por cientos de miles de dispositivos IoT comprometidos: cámaras de seguridad, DVRs, routers domésticos. Dispositivos que sus propietarios ni siquiera sabían que estaban infectados.

Mirai no fue el primer malware IoT: Linux.Darlloz (2013), TheMoon (2014) y BASHLITE/Gafgyt/Lizkebab (2014) lo precedieron. Pero Mirai fue el primero en demostrar el poder destructivo de una botnet IoT a escala de internet, y su código fuente publicado generó un ecosistema de variantes que sigue activo una década después.

Los autores: tres universitarios

Mirai fue creado por Paras Jha (alias "Anna-senpai"), Josiah White y Dalton Norman, tres jóvenes estadounidenses que en 2016 tenían entre 18 y 20 años. Su motivación inicial no era política ni ideológica: operaban un servicio de protección DDoS para servidores de Minecraft. Crearon Mirai para atacar servidores de Minecraft competidores y para generar negocio para su propio servicio de mitigación.

El 30 de septiembre de 2016, Paras Jha publicó el código fuente de Mirai en el foro HackForums bajo el pseudónimo "Anna-senpai", en un intento de diluir la evidencia forense distribuyendo el código a otros actores. Esta decisión transformó Mirai de una amenaza controlada por un grupo pequeño a una plataforma de ataque disponible para cualquiera.

Los tres autores fueron arrestados en diciembre de 2017, se declararon culpables y fueron sentenciados a servicio comunitario y libertad condicional. También cooperaron con el FBI en investigaciones posteriores.

Mecanismo de infección

El método de infección de Mirai es brutalmente simple, lo que contribuyó a su efectividad masiva.

Fase 1: escaneo

Cada bot Mirai activo escanea internet de forma continua buscando dispositivos con puertos Telnet (23, 2323) o SSH abiertos. El escaneo es SYN stateless: envía paquetes SYN a IPs aleatorias y espera respuestas SYN-ACK, lo que permite un escaneo extremadamente rápido. Mirai excluye de su escaneo ciertas redes (DoD, IANA reserved, GE, HP, US Postal Service) para evitar atención de ciertos actores.

Fase 2: brute force de credenciales

Cuando encuentra un dispositivo con Telnet abierto, Mirai intenta autenticarse usando una tabla hardcodeada de 62 combinaciones de usuario y contraseña. Estas credenciales no son aleatorias: son las credenciales por defecto de fábrica de los dispositivos IoT más comunes.

Algunas de las credenciales de la tabla original de Mirai:

Usuario	Contraseña	Dispositivos típicos
root	xc3511	Cámaras Xiongmai/Dahua
root	vizxv	Cámaras Dahua
admin	admin	Genérico (routers, cámaras)
root	123456	Genérico
root	default	Cámaras Vivotek
admin	password	Routers domésticos
root	juantech	Routers TP-Link
root	realtek	Dispositivos con chip Realtek
admin	1111111	Cámaras Samsung
guest	12345	DVRs varios

La tabla incluye combinaciones para dispositivos de Xiongmai (XM), Dahua, Hikvision, ZTE, Huawei, D-Link, Netgear y otros fabricantes populares de IoT.

Fase 3: descarga del payload

Si el login es exitoso, Mirai determina la arquitectura del procesador del dispositivo (ARM, MIPS, MIPSEL, x86, x86_64, PowerPC, SPARC, SH4, Motorola 68k) y descarga el binario apropiado desde un servidor de distribución. El binario se descarga a /tmp/ o a la memoria, se ejecuta y, en muchos casos, elimina otros malware presentes en el dispositivo para monopolizar los recursos.

Fase 4: persistencia (limitada)

Mirai no sobrevive a un reinicio del dispositivo. La mayoría de los dispositivos IoT tienen sistemas de archivos de solo lectura, y Mirai se ejecuta desde la memoria. Sin embargo, dado que el dispositivo volverá a ser vulnerable tras el reinicio (las credenciales por defecto no cambian), la reinfección suele ocurrir en minutos.

Arquitectura de Mirai

El código fuente de Mirai, publicado en GitHub, revela una arquitectura modular con cuatro componentes principales.

Scanner (módulo de propagación)

El scanner es el componente responsable de la infección de nuevos dispositivos. Opera desde cada bot infectado, generando IPs aleatorias y probando credenciales Telnet/SSH. Cuando encuentra un dispositivo vulnerable, reporta la IP, puerto y credenciales al servidor de report, que centraliza los resultados.

Características del scanner:

• Escaneo SYN stateless (raw sockets) para máxima velocidad
• Exclusión de rangos IP específicos (DoD, GE, HP, IANA reserved)
• Resolución de arquitectura del dispositivo para seleccionar el binario correcto
• Rate limiting configurable para evitar detección por anomalías de tráfico

Loader (servidor de distribución)

El loader recibe los reportes de dispositivos vulnerables del scanner, se conecta al dispositivo comprometido via Telnet/SSH, y descarga el binario apropiado. El loader es un componente centralizado (no reside en cada bot), lo que lo convierte en un punto de infraestructura crítico para los operadores.

El proceso de carga:

1. Conecta al dispositivo usando las credenciales reportadas
2. Determina la arquitectura (cat /proc/cpuinfo o prueba/error con binarios)
3. Busca un directorio escribible (/tmp/, /var/run/, /dev/)
4. Descarga el payload via wget, tftp o echo con redirección
5. Cambia permisos (chmod 777) y ejecuta
6. El bot contacta al C2 y queda listo para recibir comandos

C2 (Command and Control)

El servidor C2 gestiona la botnet completa. Los operadores se conectan al C2 via una interfaz de línea de comandos que permite:

• Ver el número de bots online por arquitectura
• Lanzar ataques DDoS contra objetivos específicos
• Seleccionar el tipo de ataque (UDP flood, SYN flood, ACK flood, GRE flood, DNS amplification, HTTP flood, VSE query flood)
• Configurar duración y parámetros del ataque
• Gestionar múltiples "clientes" que alquilan capacidad de la botnet

El protocolo C2 es propietario, binario, y los bots envían heartbeats periódicos al servidor C2.

Bot (payload en el dispositivo)

El bot es el componente que se ejecuta en cada dispositivo infectado. Sus funciones:

• Contactar al C2 y registrarse como bot activo
• Ejecutar ataques DDoS según los comandos recibidos
• Ejecutar el módulo scanner para propagar la infección
• Eliminar otros malware del dispositivo ("killer module" que mata procesos de otros bots IoT como Qbot, Zollard, etc.)
• Ocultar su proceso (renombra su binario a cadenas aleatorias)

El ataque a Dyn: internet se tambalea

El 21 de octubre de 2016, Mirai lanzó el ataque que lo hizo mundialmente famoso. El objetivo fue Dyn (ahora Oracle Dyn), un proveedor de servicios DNS utilizado por miles de sitios web y servicios.

El ataque se desarrolló en tres oleadas:

• Primera oleada (11:10 UTC): ataque contra la infraestructura DNS de Dyn en la costa este de EE.UU. Duración: aproximadamente 2 horas.
• Segunda oleada (15:50 UTC): ataque más amplio contra data centers de Dyn a nivel global. Más intenso y distribuido.
• Tercera oleada (20:00 UTC): oleada final que fue mitigada antes de causar impacto significativo.

El volumen total estimado superó 1,2 Tbps. El ataque utilizó una combinación de técnicas: TCP SYN floods, UDP floods, DNS query floods y, probablemente, paquetes GRE. La cantidad de dispositivos IoT participantes se estimó en más de 100.000.

Servicios afectados: Twitter, Netflix, Reddit, GitHub, PayPal, Spotify, CNN, The New York Times, The Guardian, Pinterest, SoundCloud, Etsy, entre otros.

El impacto fue tan significativo que el Department of Homeland Security de EE.UU. emitió un comunicado oficial, y el incidente desencadenó debates en el Congreso sobre la seguridad de los dispositivos IoT.

Variantes: la evolución post-código fuente

La publicación del código fuente en septiembre de 2016 generó un ecosistema de variantes que sigue creciendo. Cada variante añade funcionalidades, explota nuevas vulnerabilidades o ataca nuevos tipos de dispositivos.

Satori/Okiru (2017)

Primera variante significativa. En lugar de usar brute force de credenciales, Satori explotaba vulnerabilidades específicas en routers Huawei (CVE-2017-17215) y Realtek SDK (CVE-2014-8361). Esto marcó un cambio importante: de credenciales por defecto a exploits como vector de infección. Llegó a infectar más de 280.000 dispositivos en 12 horas.

Mozi (2019 a 2023)

Mozi introdujo una innovación arquitectónica: reemplazó la comunicación centralizada C2 de Mirai por un protocolo P2P basado en DHT (Distributed Hash Table), similar al usado en BitTorrent. Esto eliminó el punto único de fallo del servidor C2 y hizo la botnet mucho más resiliente a takedowns.

Mozi llegó a representar el 90% del tráfico de IoT malicioso global según IBM X-Force en 2020. Se enfocaba en routers Netgear, D-Link y Huawei. En septiembre de 2023, se detectó un kill switch que desactivó los bots de Mozi, posiblemente desplegado por las autoridades chinas tras arrestar a sus operadores.

Echobot (2019)

Variante que incorporó más de 26 exploits para diferentes dispositivos y servicios, incluyendo vulnerabilidades en Oracle WebLogic, VMware SD-WAN y dispositivos Barracuda. Echobot demostró la tendencia hacia variantes "multi-exploit" que no dependen de un solo vector de entrada.

Dark Mirai (2021)

Se enfocó en routers domésticos TP-Link, explotando la vulnerabilidad CVE-2021-41653. Dark Mirai representó la especialización de variantes en fabricantes específicos con base instalada masiva.

RapperBot (2022)

Cambió de Telnet a SSH como protocolo de brute force principal. RapperBot implementó un cliente SSH completo y podía persistir añadiendo claves SSH autorizadas al dispositivo, lo que le daba persistencia entre reinicios (algo que Mirai original no tenía). Usado para lanzar ataques DDoS contra servidores de juegos.

InfectedSlurs (2023)

Descubierta por Akamai SIRT, esta variante explotaba dos vulnerabilidades zero-day en NVRs (Network Video Recorders) y routers Wi-Fi. El nombre proviene de los insultos raciales usados en los nombres de sus servidores C2 y canales. InfectedSlurs demostró que las variantes de Mirai siguen encontrando zero-days en dispositivos IoT para propagarse.

Pandora (2023)

Variante que infecta dispositivos Android TV y set-top boxes baratos, principalmente a través de actualizaciones de firmware maliciosas y aplicaciones troyanizadas distribuidas en sitios de streaming pirata. Pandora expandió el ecosistema Mirai más allá de routers y cámaras hacia dispositivos de entretenimiento.

NoaBot (2023 a 2024)

Variante que reescribió el código de Mirai desde cero en lugar de bifurcarlo, dificultando la detección por firmas. Usa SSH brute force con diccionarios personalizados y despliega un cryptominer en lugar de capacidades DDoS, marcando un cambio de motivación de DDoS-as-a-Service a cryptojacking.

Impacto en la industria IoT

Mirai tuvo consecuencias duraderas más allá de sus ataques directos:

Regulación. La Cyber Resilience Act de la UE (2024), el IoT Cybersecurity Improvement Act de EE.UU. (2020) y los estándares ETSI EN 303 645 para seguridad de IoT de consumo son respuestas directas al problema que Mirai visibilizó.

Diseño de dispositivos. Fabricantes como Hikvision, Dahua y TP-Link implementaron requisitos de cambio de contraseña en el primer uso, desactivación de Telnet por defecto y mecanismos de actualización automática de firmware.

DDoS mitigation. Los ataques de Mirai impulsaron la adopción de servicios de mitigación DDoS (Cloudflare, Akamai, AWS Shield) y la implementación de BCP38/BCP84 (filtrado de IP spoofing) por parte de ISPs.

Investigación. Mirai generó cientos de papers académicos y se convirtió en caso de estudio fundamental en cursos de ciberseguridad e IoT security.

Detección de infección por Mirai

Indicadores de red

• Tráfico Telnet saliente (puerto 23/2323) desde dispositivos IoT que no deberían iniciar conexiones Telnet
• Volumen anómalo de paquetes SYN a IPs aleatorias (escaneo)
• Conexiones a IPs conocidas de C2 de Mirai (listas actualizadas en repositorios como abuse.ch)
• Tráfico UDP/TCP masivo saliente durante ataques DDoS
• Resolución DNS de dominios C2 conocidos

Indicadores en el dispositivo

• Procesos con nombres aleatorios ejecutándose en /tmp/ o memoria
• Conexiones de red activas a puertos no estándar
• Uso de CPU anormalmente alto
• Otros procesos de malware eliminados (Mirai mata competidores)
• Archivos binarios en directorios temporales escribibles

Herramientas de detección

Herramienta	Función
Suricata/Snort	Reglas IDS/IPS para tráfico Mirai (SIDs específicos)
Zeek (Bro)	Análisis de protocolos y detección de anomalías de tráfico
Nmap	Escaneo de puertos Telnet/SSH abiertos en red interna
Shodan/Censys	Identificación de dispositivos IoT expuestos a internet
YARA	Reglas para identificar binarios de Mirai por firmas
Wireshark	Análisis manual de capturas de tráfico sospechoso

Prevención y mitigación

Para administradores de red

1. Cambiar credenciales por defecto. La medida más efectiva y simple. El 62 de las 62 credenciales en la tabla original de Mirai son credenciales de fábrica.
2. Desactivar Telnet. Si el dispositivo no requiere acceso Telnet, desactivar el servicio. Preferir SSH con autenticación por clave pública.
3. Segmentar la red IoT. Colocar dispositivos IoT en una VLAN dedicada sin acceso directo a internet ni a la red corporativa.
4. Filtrar tráfico saliente. Los dispositivos IoT raramente necesitan iniciar conexiones a internet. Aplicar reglas de firewall que bloqueen tráfico saliente no necesario.
5. Actualizar firmware. Muchos fabricantes han publicado actualizaciones que corrigen las vulnerabilidades explotadas por Mirai y sus variantes.
6. Monitorizar con IDS/IPS. Desplegar reglas Suricata/Snort específicas para tráfico Mirai en el perímetro de la red IoT.

Para fabricantes de IoT

1. Eliminar credenciales por defecto compartidas: cada dispositivo con una contraseña única de fábrica
2. Desactivar Telnet por defecto; ofrecer solo SSH o interfaces web sobre HTTPS
3. Implementar actualizaciones automáticas de firmware con firma digital
4. Diseñar para que el sistema de archivos raíz sea de solo lectura
5. Limitar las capacidades de red del dispositivo al mínimo necesario

Mapeo ATT&CK (MITRE ATT&CK for ICS y Enterprise)

Táctica	Técnica	Descripción en Mirai
Initial Access	T1078 Valid Accounts	Uso de credenciales por defecto
Initial Access	T1190 Exploit Public-Facing Application	Variantes con exploits (Satori, Echobot)
Execution	T1059.004 Unix Shell	Ejecución de comandos via Telnet/SSH shell
Persistence	T1098 Account Manipulation	RapperBot añade claves SSH
Defense Evasion	T1036 Masquerading	Renombra proceso a cadena aleatoria
Defense Evasion	T1070 Indicator Removal	Elimina binarios tras ejecución en memoria
Discovery	T1046 Network Service Discovery	Escaneo SYN de puertos 23/2323
Lateral Movement	T1021.004 Remote Services: SSH	Propagación via SSH brute force
Command and Control	T1071 Application Layer Protocol	Protocolo C2 propietario sobre TCP
Impact	T1498 Network Denial of Service	Ataques DDoS (UDP, SYN, ACK, GRE, HTTP flood)

Recursos

• Mirai Source Code (GitHub mirror) (análisis del código fuente publicado)
• Akamai: InfectedSlurs Botnet (investigación de la variante InfectedSlurs)
• CISA Alert: Mirai and IoT Botnets (alerta oficial)
• Krebs on Security: Who is Anna-Senpai? (investigación sobre los autores)
• IBM X-Force: Mozi Botnet (análisis de la variante P2P)
• Cloudflare: DDoS Threat Reports (tendencias de DDoS incluyendo tráfico Mirai)
• ENISA Threat Landscape for IoT (panorama europeo de amenazas IoT)