GETOVERX FORUM Community Support
BOTNET – Mirai - Printable Version

+- GETOVERX FORUM Community Support (https://forum.getoverx.com)
+-- Forum: Malware Docs (https://forum.getoverx.com/forumdisplay.php?fid=12)
+--- Forum: Botnets / Bots (https://forum.getoverx.com/forumdisplay.php?fid=22)
+--- Thread: BOTNET – Mirai (/showthread.php?tid=33)

BOTNET – Mirai - mrwebfeeder - 11-29-2025

Nombre: Mirai
(indica el nombre del malware, incluir alias si los tiene)

Categoría: IoT Botnet
(ej.: Ransomware, Infostealer, Troyano bancario, RAT, Loader/Downloader, etc.)

Fecha de descubrimiento: 2016

Comportamiento (lo que hace y archivos que infecta):
- Botnet orientada a dispositivos IoT (cámaras IP, DVR/NVR, routers SOHO, CPEs, etc.).
- Infecta dispositivos principalmente mediante:
- Escaneo masivo de Internet en busca de servicios expuestos (Telnet, SSH, HTTP de administración).
- Uso de credenciales por defecto o muy débiles para iniciar sesión y desplegar el binario.
- Una vez que compromete el dispositivo:
- Descarga y ejecuta un binario adaptado a la arquitectura (ARM, MIPS, etc.).
- Registra el dispositivo como un nodo más de la botnet Mirai.
- Ataques DDoS masivos:
- Utiliza los dispositivos infectados para lanzar ataques de denegación de servicio distribuida (DDoS) contra objetivos definidos por los operadores.
- Soporta múltiples vectores (UDP floods, TCP SYN floods, HTTP floods, etc.).
- Escaneo en Telnet/SSH:
- Los bots escanean direcciones IP aleatorias o listas específicas en busca de nuevos dispositivos vulnerables.
- Intentan autenticarse con listas de usuarios/contraseñas por defecto para propagarse.
- “Archivos que infecta”:
- En muchos dispositivos IoT, el binario se ejecuta en memoria o se descarga a directorios temporales (por ejemplo
Code:
/tmp
).
- No cifra ni modifica archivos del usuario; su foco es el control del dispositivo y la participación en DDoS.

Persistencia:
- Describe cómo se mantiene en el sistema:
- En muchas variantes clásicas:
- El malware reside principalmente en memoria; al reiniciar el dispositivo, la infección se pierde.
- Sin embargo, el mismo dispositivo puede ser reinfectado rápidamente mientras siga:
- Expuesto a Internet.
- Usando credenciales por defecto.
- Variantes más recientes pueden:
- Escribir scripts o entradas en el sistema embebido para relanzar el binario tras un reinicio (según capacidades del firmware).
- Modificar parámetros de arranque o archivos de inicio para mantener la ejecución del bot.
- El mecanismo de “persistencia real” de Mirai a nivel de red es:
- La reinfectación constante desde otros nodos de la botnet si no se corrige la causa raíz (exposición, claves débiles, firmware sin parches).

Hash real de referencia (SHA-256):
- Añade un hash SHA-256 real de una muestra pública conocida del malware.
- Ejemplo de formato:
Code:
SHA256: 1c234e7eaf7c5751ec8f6a8abca096935ccebff98c582a289bc8123b7d57ed85

Mitigación con GetOverX Shield v3.0.2.0:
Describe los pasos recomendados usando los módulos de GetOverX Shield:
  • Antivirus:
    Explica cómo usar el motor AV para detectar y eliminar el ejecutable principal y sus droppers.
    - En servidores Linux o equipos que gestionen firmware/imagenes de dispositivos:
    - Ejecutar escaneos sobre binarios ELF descargados (especialmente en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    y repositorios de firmware).
    - Mantener firmas y reglas YARA enfocadas a variantes Mirai/Mirai-like.
    - En gateways o appliances monitorizados por GetOverX Shield:
    - Escanear regularmente ficheros sospechosos asociados a herramientas de administración remota y scripts de despliegue.

  • Firewall:
    Indica qué tipo de tráfico debe bloquearse (C2, dominios sospechosos, puertos, etc.) y si es recomendable aislar el host.
    - Bloquear desde el perímetro:
    - Acceso Telnet (23/TCP) y SSH (22/TCP) desde Internet a dispositivos IoT siempre que no sea estrictamente necesario.
    - Exposición de paneles HTTP/HTTPS de administración de cámaras/DVR/routers a Internet.
    - Crear reglas específicas para:
    - Limitar conexiones salientes desde segmentos IoT hacia Internet a los servicios estrictamente necesarios.
    - Detectar y bloquear tráfico característico de DDoS (floods volumétricos provenientes de rangos IoT internos).
    - Aislar de la red (o limitar fuertemente el ancho de banda) a los dispositivos que muestren comportamiento típico de bot (tráfico de DDoS, escaneo agresivo).

  • HIPS/EDR:
    Detalla qué comportamiento debe vigilarse:
    - Creación masiva de archivos (ransomware)
    - Acceso masivo a almacenes de credenciales (stealers)
    - Uso anómalo de PowerShell / scripts
    - Movimiento lateral, enumeración de red, etc.
    Incluye si se debe configurar respuesta automática (matar proceso, bloquear hash, etc.).
    - En servidores y equipos de administración monitorizados:
    - Detectar procesos que:
    - Compilan, despliegan o ejecutan binarios ELF multi-arquitectura sin justificación clara.
    - Generan tráfico de escaneo de puertos a gran escala desde la red interna.
    - Respuesta recomendada:
    - Marcar como sospechosos los hosts que generen tráfico de escaneo o DDoS.
    - Registrar IPs internas implicadas para facilitar la localización física de los dispositivos IoT comprometidos.
    - Si el malware se ejecuta en un sistema administrado por GetOverX Shield, matar el proceso y bloquear el hash.

  • Sandbox:
    Explica cuándo es recomendable usar el módulo de Sandbox:
    - Antes de ejecutar adjuntos de correo
    - Antes de instalar software de procedencia dudosa
    - Para analizar muestras sospechosas en un entorno aislado
    - Analizar en la Sandbox:
    - Binarios ELF sospechosos destinados a IoT o servidores Linux.
    - Scripts que descargan ejecutables multiplaforma (ARM/MIPS/etc.).
    - Observar si:
    - El binario inicia rutinas de escaneo de puertos (Telnet/SSH) y de fuerza bruta de credenciales.
    - Establece conexiones con infraestructura de C2 típica de Mirai o lanza tráfico de prueba tipo DDoS.
    - Si se confirma comportamiento Mirai-like:
    - Bloquear la distribución de ese binario dentro de la red.
    - Marcarlo para uso como IOC en futuras detecciones.

  • Medidas posteriores al incidente:
    Indica acciones adicionales:
    - Restaurar desde copias de seguridad offline
    - Cambiar contraseñas
    - Revisar accesos a cuentas sensibles (banca, VPN, paneles de hosting)
    - Revisión de herramientas de administración remota abusadas
    - Para dispositivos IoT comprometidos:
    - Cambiar inmediatamente todas las credenciales por defecto por contraseñas robustas.
    - Actualizar el firmware a la última versión disponible.
    - Cuando sea posible, realizar un reset de fábrica y reconfigurar desde cero sin reutilizar configuraciones antiguas no confiables.
    - En la red:
    - Segmentar los dispositivos IoT en VLANs separadas con acceso muy limitado.
    - Revisar logs de firewall y de tráfico para confirmar que ya no se observan patrones de DDoS ni escaneos salientes.
    - Documentar:
    - Modelos de dispositivos afectados.
    - Versiones de firmware vulnerables.
    - Medidas tomadas, para prevenir futuras reinfecciones.

Notas opcionales:
- Mirai fue responsable de algunos de los ataques DDoS más grandes registrados públicamente en 2016, demostrando el impacto que puede tener una botnet basada en dispositivos IoT mal configurados.