Tengu Botnet reinicia dispositivos Linux comprometidos cuando los defensores interrumpen su proceso – CYBERDEFENSA.MX
Una nueva botnet derivada de Mirai llamada Tengu puede utilizar el dispositivo de vigilancia de hardware de un dispositivo Linux comprometido para activar un reinicio cuando los defensores finalizan su proceso principal.
Si eso sucede, los otros mecanismos de persistencia de Tengu tendrán otra oportunidad de relanzarlo. Nozomi Networks Labs observó que el gotero llegaba a sus honeypots a través de la fuerza bruta de la credencial Telnet.
Tengu admite 25 métodos distribuidos de denegación de servicio (DDoS). También puede ejecutar un proxy SOCKS5, ejecutar comandos de shell y recopilar datos del sistema y de la red. El malware puede actualizarse y recuperar cargas útiles adicionales de formato ejecutable y vinculable (ELF) o paquete de Android (APK).
Nozomi enumeró ejemplos de arquitectura específica para i386, amd64, MIPS, ARM, PowerPC y m68k. El informe no identifica ningún proveedor o modelo de dispositivo específico. Tampoco nombra ningún operador, recuento de infecciones ni víctimas de DDoS del mundo real. Muestra lo que Tengu puede hacer, no hasta dónde se ha extendido.
Los defensores deberían comenzar eliminando la exposición a Internet de Telnet y otros servicios administrativos innecesarios y reemplazando las credenciales predeterminadas. Nozomi también recomienda actualizar el firmware, segmentar las redes de Internet de las cosas (IoT) y revisar los servicios systemd, los scripts de inicio, los archivos de inicio del shell y las rutas relacionadas con cron antes de devolver al servicio un dispositivo sospechoso.
Laboratorios de redes Nozomi publicó su análisis el 27 de julio de 2026. Nozomi dijo que la persistencia y el código de autodefensa de Tengu lo hicieron destacar entre las muestras derivadas de Mirai que rastrea. «La mayoría de las variantes de Mirai implementan pocas o ninguna de estas capacidades de autodefensa», dijeron los investigadores.
Una vez en ejecución, el bot bifurca un guardián independiente que verifica el proceso principal de malware cada 60 segundos y reinicia el binario instalado si se detiene. También puede crear un servicio systemd falso, agregar scripts init y RC, alterar los archivos de inicio del shell y marcar su binario instalado como inmutable. Hay una rutina de persistencia basada en cron, pero Nozomi dijo que su referencia a /proc/self/exe parece inacabada o rota.
Un segundo mecanismo abusa del mecanismo de vigilancia del hardware del dispositivo. Un trabajador de fondo se hace pasar por [kworker/0:0]vuelve a abrir el dispositivo de vigilancia si está disponible, lo activa con un tiempo de espera de aproximadamente 30 segundos y envía señales de mantenimiento de actividad solo mientras el proceso principal de malware permanece activo. Finalice el proceso y el perro guardián dejará de recibir alimentación, lo que permitirá que el dispositivo se reinicie. Los otros mecanismos de persistencia de Tengu pueden entonces intentar relanzarlo.
Tengu también incluye una lista codificada de utilidades de reinicio y apagado. Sobrescribe sus encabezados ELF con la cadena ELFOOD, lo que puede interferir con los comandos normales que los defensores pueden usar para reiniciar o apagar de forma segura un dispositivo comprometido.
La muestra analizada se configuró para comunicarse con un servidor de comando y control (C2) en 64[.]89.163.8 a través del puerto TCP 9931. El registro, el tráfico de latidos y la salida de comandos se envían en texto sin formato, mientras que los comandos y actualizaciones del servidor utilizan un esquema de cifrado autenticado personalizado similar a ChaCha20/Poly1305.
Tengu también puede obtener un identificador de contenido proporcionado por C2 desde una puerta de enlace del Sistema de archivos interplanetario (IPFS) en el mismo servidor, validar el resultado como ELF o APK y ejecutarlo o instalarlo.
Nozomi evaluó que la ruta APK probablemente apunta a dispositivos mal protegidos Cajas de TV con Android o dispositivos similares, pero no documentaron víctimas confirmadas de Android.
URLhaus grabado de forma independiente 17 URL de malware en 64[.]89.163.8 a partir del 17 de junio de 2026. Los registros incluían un script de shell, varios archivos ELF etiquetados como Mirai y un APK. Las entradas de carga útil más recientes de URLhaus se vieron por primera vez el 7 de julio y las 17 URL estaban fuera de línea el 28 de julio.
URLhaus no identifica los archivos como Tengu. Hasta el 28 de julio, ninguno de los hashes SHA-256 enumerados en su registro de host coincidía con el hash de muestra publicado por Nozomi. Por lo tanto, su telemetría solo confirma alojamiento malicioso relacionado con Mirai en la dirección.
The Hacker News se comunicó con Nozomi Networks para obtener detalles adicionales sobre la escala observada de Tengu, el estado de la infraestructura y el enlace de la muestra, y actualizará la historia con cualquier respuesta.
Ni Nozomi ni URLhaus establecen si se podía acceder al servicio C2 en el puerto 9931 o a la puerta de enlace IPFS en el puerto 8080. El estado de URLhaus se aplica únicamente a las URL de descarga enumeradas. Nozomi tampoco dice si el servidor C2 configurado en 64[.]89.163.8:9931 emitió algún comando.
