Botnet Tengu reinicia dispositivos Linux comprometidos y Android TV

Una nueva botnet derivada de Mirai, llamada Tengu, puede usar el mecanismo de vigilancia de hardware de un dispositivo Linux comprometido para provocar un reinicio cuando los defensores finalizan su proceso principal.

Nozomi Networks Labs observó que el dropper accedía a sus honeypots mediante un ataque de fuerza bruta de credenciales Telnet. 

Tengu admite 25 métodos de denegación de servicio distribuido (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 obtener cargas útiles adicionales en formato ELF (Executable and Linkable Format) o paquetes de Android (APK). Nozomi evaluó que la ruta del APK probablemente apunta a dispositivos Android TV o similares con poca seguridad, pero no documentó víctimas Android confirmadas.

Nozomi publicó muestras específicas para arquitecturas como i386, amd64, MIPS, ARM, PowerPC y m68k. El informe no identifica a ningún proveedor ni modelo de dispositivo en particular. Tampoco menciona operadores, número de infecciones ni víctimas reales de ataques DDoS. Muestra las capacidades de Tengu, pero no su alcance.

Los responsables de la seguridad deben comenzar por eliminar la exposición a Internet de Telnet y otros servicios administrativos innecesarios, y reemplazar 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 de shell y las rutas relacionadas con cron antes de volver a poner en servicio un dispositivo sospechoso.

Nozomi Networks Labs publicó su análisis el 27 de julio de 2026 y afirmó que la persistencia y el código de autodefensa de Tengu lo distinguen de las muestras derivadas de Mirai que analiza. "La mayoría de las variantes de Mirai implementan pocas, o ninguna, de estas capacidades de autodefensa", señalaron los investigadores.

Una vez en ejecución, el bot crea un proceso secundario que supervisa el proceso principal del malware cada 60 segundos y reinicia el binario instalado si este se detiene. También puede crear un servicio systemd falso, añadir scripts de inicio y RC, modificar archivos de inicio de shell y marcar su binario instalado como inmutable. Incluye una rutina de persistencia basada en cron, pero Nozomi indicó que su referencia a /proc/self/exe parece estar incompleta o defectuosa.

Un segundo mecanismo abusa del sistema de vigilancia de hardware del dispositivo. Un proceso en segundo plano, que se hace pasar por [kworker/0:0], vuelve a abrir el sistema de vigilancia si está disponible, lo configura con un tiempo de espera de aproximadamente 30 segundos y envía señales de mantenimiento de conexión solo mientras el proceso principal del malware permanezca activo. Si se finaliza el proceso, el sistema de vigilancia deja de recibir información, lo que permite reiniciar el dispositivo. Los demás mecanismos de persistencia de Tengu pueden entonces intentar reiniciarlo.

Tengu también incluye una lista predefinida de utilidades de reinicio y apagado. Sobrescribe las cabeceras ELF con la cadena ELFOOD, lo que puede interferir con los comandos habituales que los defensores utilizan para reiniciar o apagar de forma segura un dispositivo comprometido.

La muestra analizada estaba configurada 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 latido y la salida de comandos se envían en texto plano, mientras que los comandos y las 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 el C2 desde una puerta de enlace del Sistema de Archivos Interplanetario (IPFS) en el mismo servidor, validar el resultado como un archivo ELF o APK, y ejecutarlo o instalarlo.

URLhaus registró 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 detectaron 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. El 28 de julio, ninguno de los hashes SHA-256 que figuraban en su registro de host coincidía con el hash de muestra publicado por Nozomi. Por lo tanto, su telemetría confirma únicamente el alojamiento de malware relacionado con Mirai en esa dirección.

Fuente: THN

Suscríbete a nuestro Boletín