Introducción

Los equipos de seguridad detectaron una nueva familia de botnet en Linux, Evooo1Bot, que desde julio de 2024 compromete routers y gateways expuestos a internet para convertirlos en nodos de relé de tráfico SOCKS5. El malware, basado en el código fuente filtrado de Mirai, extiende sus capacidades con módulos para robo de credenciales, fuerza bruta por SSH y ataques DDoS, representando una amenaza multisectorial para infraestructuras de red, entornos cloud y dispositivos IoT.

La particularidad de Evooo1Bot radica en su diseño modular y su arsenal de exploits integrados, que incluyen vulnerabilidades en componentes críticos como Kubernetes ingress-nginx, Atlassian Confluence y firewalls Zyxel, lo que amplía su superficie de ataque más allá de los dispositivos embebidos tradicionales.

Qué ocurrió

Fortinet reportó que Evooo1Bot ha estado activo al menos desde julio, dirigiendo sus ataques contra dispositivos de fabricantes como Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare y D-Link en múltiples regiones. El vector de infección inicial explotan vulnerabilidades conocidas en estos equipos, muchas de las cuales tienen parches disponibles desde hace meses o años.

En versiones más recientes del malware, los operadores incorporaron un módulo de explotación separado que apunta a un rango más amplio de objetivos, incluyendo:

  • Cámaras Hikvision (vulnerabilidades no especificadas en el informe)
  • Atlassian Confluence (probablemente CVE-2022-26116, RCE en instancias no parcheadas)
  • Firewalls Zyxel (CVE-2023-1389, RCE en dispositivos con firmware < ZLD5.30)
  • Routers TP-Link
  • Dispositivos NAS D-Link
  • Productos WSO2 (posiblemente CVE-2022-22965, RCE en Multiple Products)
  • Kubernetes ingress-nginx (CVE-2021-25741, RCE en versiones < 0.41.0)
  • Servidores con PHP-CGI vulnerable (CVE-2021-41773)

Aunque el malware hereda el motor de DDoS de Mirai, Fortinet destacó que algunos de los exploits integrados están mal implementados, lo que en la práctica reduce su tasa de éxito. Sin embargo, cuando la explotación es exitosa, un script descarga una de las 12 variantes del binario (compiladas para arquitecturas x86, ARM, MIPS, etc.), borra el historial de Bash (history -c) para ocultar rastro y ejecuta el payload.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

El principal riesgo de Evooo1Bot para los equipos de infraestructura es la exfiltración de tráfico malicioso a través de redes legítimas. El módulo SOCKS5 del malware permite a los atacantes:

  • Ocultar el origen de actividades maliciosas (spam, fraude, attacks a terceros) tras IPs de dispositivos comprometidos.
  • Eludir restricciones geográficas (geoblocking) en servicios o aplicaciones.
  • Acceder a redes internas desde un dispositivo infectado en la perimeter, si la configuración de la red lo permite.

Para entornos cloud, el impacto potencial incluye:

  • Abuso de recursos: Instancias de Kubernetes o VMs Linux comprometidas pueden ser usadas para lanzar ataques DDoS (16 métodos implementados, incluyendo HTTP floods personalizables).
  • Compromiso de credenciales: El módulo sniffer monitorea /proc/net/tcp y captura headers de autenticación HTTP Basic y cookies, lo que podría permitir movimiento lateral.
  • Persistencia en clusters: En Kubernetes, si el malware logra comprometer un pod, podría usar el mecanismo de systemd para mantenerse activo incluso después de reinicios.

El informe de Fortinet no quantifica el tamaño actual del botnet, pero la diversidad de objetivos y la capacidad de monetización (mediante servicios de proxies residenciales) sugiere que los operadores buscan escalar la red. El CVSS base score de las vulnerabilidades explotadas varía entre 7.5 (CVE-2023-1389 en Zyxel) y 9.8 (CVE-2021-25741 en ingress-nginx).

Detalles técnicos

Evooo1Bot emplea múltiples técnicas para evadir detección y mantener la persistencia:

Comunicación con C2:

  • Usa puertos 443 (HTTPS) para el tráfico de comando y control.
  • Los mensajes están encriptados (algoritmo custom, no especificado en el informe).
  • Incluye checks anti-analysis para detectar:

– Depuradores (ptrace, gdb)

– Herramientas de seguridad (como lsof, netstat, top)

– Entornos de sandbox, VMs (VMware, VirtualBox) y contenedores (Docker)

– Honeypots (mediante comportamientos post-explotación)

Persistencia:

  • systemd: Crea un service (ejemplo: /etc/systemd/system/nginx.service) que ejecuta el binario malicioso.
  • SysV init: Instala scripts en /etc/init.d/.
  • Shell profiles: Añade comandos a ~/.bashrc, ~/.profile o /etc/profile.
  • rc.local: Agrega entradas en /etc/rc.local.
  • Cron: Programa un job que descarga el payload cada 5 minutos (*/5 * * * *).

Capacidades adicionales:

  • Shell interactiva: Los operadores pueden ejecutar comandos arbitrarios en hosts comprometidos.
  • Transferencia de archivos: Comandos para subir/bajar archivos desde/to el dispositivo infectado.
  • SSH brute-force: Usa un diccionario de 150 combinaciones de usuario/contraseña orientadas a cuentas de empresa (ej: admin, root, support, user con passwords como admin, password, 123456).
  • DDoS: 16 métodos, incluyendo:

– UDP flood

– DNS flood

– SYN flood

– ACK flood

– GRE flood

– TCP fragmentado

– HTTP flood (con requests personalizables)

Estructura del binario:

# Ejemplo de comandos integrados en Evooo1Bot (extraídos del análisis de Fortinet)
ATK, SCAN, KILLER, SOCKS5, HARVESTER, REVERSE, BIND, LOader, LOGIN

El módulo HARVESTER corresponde al sniffer de credenciales, mientras que LOader se encarga de descargar actualizaciones o payloads adicionales.

Qué deberían hacer los administradores y equipos técnicos

Mitigación en dispositivos de red:

  • Actualizar firmware: Aplicar los parches para las vulnerabilidades conocidas en routers y gateways de los fabricantes mencionados. Por ejemplo:
  • – Zyxel: actualizar a ZLD5.30 o superior.

    – Kubernetes ingress-nginx: actualizar a v0.41.0 o posterior.

    – Atlassian Confluence: parchar CVE-2022-26116 (versiones afectadas: < 7.18.0).

  • Cambiar credenciales: Reemplazar contraseñas por defecto en todos los dispositivos expuestos, usando contraseñas complejas (mínimo 12 caracteres, mix de mayúsculas, minúsculas, números y símbolos).
  • Deshabilitar acceso remoto: Si no es estrictamente necesario, disable:
  • – UPnP

    – Remote management (WAN access)

    – Telnet (usar SSH exclusively)

  • Segmentar la red: Aislar los dispositivos IoT y routers en una VLAN dedicada, con reglas de firewall que restrinjan el tráfico saliente (ej: bloquear puertos 443 hacia IPs conocidas de C2, si se dispone de IOCs).
  • Monitorizar conexiones salientes: Usar herramientas como Zeek (Bro) o Suricata para detectar tráfico SOCKS5 o patrones de DDoS (ej: flujos con alto volumen de paquetes UDP).
  • Protección en entornos cloud:

  • Escaneos de vulnerabilidades: Usar herramientas como Trivy o OpenVAS para detectar instancias de Kubernetes o servicios expuestos con vulnerabilidades conocidas:
  • trivy image –severity CRITICAL, HIGH ingress-nginx/controller:v0.40.0

  • Restricciones de red:
  • – En clusters de EKS/AKS/GKE, aplicar Network Policies para limitar el tráfico entre pods.

    – Usar Security Groups o Firewall Rules para bloquear el acceso a puertos de management (ej: 22, 8080) desde internet.

  • Detección de comportamientos sospechosos:
  • – Monitorear procesos en busca de binarios con nombres legítimos (ej: nginx, java) pero hashes no coincidentes con los paquetes oficial.

    – Alertar sobre conexiones SSH desde IPs no esperadas o múltiples intentos de autenticación fallidos.

    – Usar Falco o Sysdig para detectar actividades como:

    – rule: Unusual Network Connection
    condition: evtype=connect and not (fd.name in /usr/share/ca-certificates/ and fd.name in /etc/ssl/certs/) and not suser in (root, systemd-network, systemd-resolve)
    output: «Outbound connection to %fd.name (%evt.arg.addr) by user %user»

    Respuesta a incidentes:

  • Aislar sistemas comprometidos: Desconectar de la red los dispositivos infectados.
  • Eliminar el malware:
  • – Identificar y kill los procesos maliciosos (ej: pkill -f «nginx» && pkill -f «Evooo1Bot»).

    – Eliminar binarios y scripts asociados (ubiciones comunes: /tmp/, /var/tmp/, /home/).

    – Revertir los cambios de persistencia:

    rm -f /etc/systemd/system/nginx.service
    rm -f /etc/init.d/nginx
    sed -i ‘/Evooo1Bot/d’ /etc/crontab /var/spool/cron/* /etc/bash* /etc/profile

  • Rotar credenciales: Cambiar todas las contraseñas y claves SSH en los sistemas afectados y en cualquier sistema accesible desde ellos.
  • Analizar logs: Revisar:
  • – /var/log/auth.log (intentos de SSH)

    – /var/log/syslog (ejecución de comandos)

    – journalctl (actividad de systemd)

    Buscar IOCs como:

    – Conexiones a IPs de C2 (ver informe de Fortinet para la lista).

    – Descargas de binarios desde URLs sospechosas (ej: hxxp://185.141.63[.]120/).

    Conclusión

    Evooo1Bot exemplifica la evolución de los botnets IoT hacia objetivos más estratégicos, como infraestructura de red y componentes cloud. Su combinación de exploits para vulnerabilidades específicas, módulos de robo de credenciales y proxy SOCKS5 lo convierte en una herramienta versátil para actividades criminales, desde fraude hasta espionaje. La mejor defensa es una combinación de actualización proactiva, configuración segura y monitoreo continuo, focalizado en los vectores de ataque conocidos. Para equipos de DevOps y SRE, integrar estos controles en los pipelines de CI/CD y las políticas de IaC (Infrastructure as Code) reduce significativamente el riesgo de compromise.

    Fuentes

    • https://www.bleepingcomputer.com/news/security/new-evooo1bot-linux-botnet-turns-routers-into-traffic-relay-nodes/
    • https://www.elastic.co/blog/category/security

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *