"Ya me tenías con el hola": la botnet NoaBot basada en Mirai entra en escena
Resumen ejecutivo
Los investigadores de seguridad de Akamai han descubierto una nueva campaña de criptominería que ha estado activa desde principios de 2023.
El malware se propaga a través del protocolo SSH mediante una botnet Mirai personalizada modificada por los atacantes.
Las capacidades de la nueva botnet, NoaBot, incluyen un autopropagador a modo de gusano y una puerta trasera de clave SSH para descargar y ejecutar binarios adicionales o propagarse a nuevas víctimas.
Como parte del ataque, se coloca una versión modificada de la minera XMRig. El minero oculta su configuración y también utiliza un pool de minería personalizado para evitar exponer la dirección de cartera utilizada por el minero.
Hemos visto pruebas que vinculan la botnet con el gusano P2PInfect, que fue descubierto por Unit 42 en julio de 2023.
La ocultación del malware y el código personalizado muestran un alto nivel de seguridad operativa, lo que suele ser indicativo de atacantes maduros, pero los nombres de los binarios del malware y algunas de sus cadenas incluidas son bastante infantiles. Esto complica la atribución.
En 2023, observamos más de 800 IP de ataque diferentes, repartidas de manera uniforme por todo el mundo.
Hemos publicado indicadores de compromiso (IOC), consultas, firmas y scripts que se pueden utilizar para comprobar si hay una infección.
Introducción
NoaBot es otra botnet basada en Mirai. La botnet Mirai es una botnet que se puede propagar como gusano y que tiene como objetivos los dispositivos de Internet de las cosas (IoT) basados en Linux. Se utiliza para ataques distribuidos de denegación de servicio (DDoS). La botnet Mirai original se identificó en 2016, pero su código fuente se ha hecho público, y en la actualidad se pueden ver muchas variantes.
Detectamos por primera vez la campaña NoaBot a principios de 2023. Desde entonces, hemos observado dos evoluciones del malware, que consisten en ocultaciones adicionales o un cambio de mando y control (C2) y dominios de pools de minería (Figura 1). También hemos observado varios incidentes que colocan muestras del gusano P2PInfect, que indica que las dos campañas están relacionadas.
Fig. 1: Actividad del malware Noabot a lo largo del tiempo
La botnet
La botnet NoaBot tiene la mayoría de las capacidades de la botnet Mirai original (como un módulo de analizador y un módulo de atacante, ocultando su nombre de proceso, etc.), pero también podemos ver muchas diferencias con el código fuente original de Mirai. En primer lugar, el propagador del malware está basado en SSH, no en Telnet como Mirai.
El analizador SSH parece estar personalizado y es bastante peculiar: una vez que se establece una conexión, la botnet simplemente envía la cadena "hi" y finaliza la conexión (Figura 2). Esta finalización rápida tiene sentido en el contexto de un analizador, ya que no necesita mantener la conexión abierta solo para verificar que existe. Entonces, ¿por qué se molesta en enviar "hi"? Es un misterio.
Fig. 2: Paquete SSH con la cadena "hi". No es un paquete SSH válido, por lo que Wireshark lo marca como mal formado.
Otra rareza del malware es que tenía una letra de canción incrustada. Muestras anteriores de la botnet tenían letras de la canción "Who's Ready for Tomorrow" de Rat Boy and IBDY (Figura 3). Todo lo que podemos decir es que esta letra no tenía ningún propósito. Las muestras posteriores no las incluían.
Fig. 3: Letra de canción incrustada que parece que no tiene ninguna finalidad.
Otros cambios con respecto a Mirai es que la botnet utiliza un diccionario de credenciales diferente para su analizador SSH e incluye muchas capacidades posteriores a la vulneración, como la instalación de una nueva clave autorizada SSH como puerta trasera para descargar y ejecutar binarios adicionales o propagarse a nuevas víctimas (Figura 4).
Fig. 4: Caso de cambio de comandos de la botnet
También a diferencia de Mirai, que suele compilarse con GCC (al menos de acuerdo con su código fuente y la guía del autor), NoaBot se compila con uClibc, lo que parece cambiar la forma en que los motores antivirus detectan el malware. Mientras que otras variantes de Mirai se suelen detectar con una firma de Mirai, las firmas de antivirus de NoaBot son de un analizador SSH o de un troyano genérico (Figura 5).
Además, el malware viene compilado estáticamente y despojado de cualquier símbolo. Esto, junto con el hecho de que es una compilación no estándar, hizo que la ingeniería inversa del malware fuera mucho más frustrante.
Por otro lado, las muestras más recientes de la botnet tenían su cadena oculta en lugar de guardada como texto sin formato. Esto dificultó la extracción de detalles del binario o la navegación por partes del desmontaje, pero la codificación en sí no era sofisticada y fue sencillo aplicar la ingeniería inversa.
También hemos observado la adición de argumentos de línea de comandos a lo largo del tiempo. El más interesante ha sido el indicador "noa", que hacía que la botnet instalara un método de persistencia en forma de una entrada de Crontab para que se ejecutara después de un reinicio.
Casualmente, parece que este indicador se ha utilizado ampliamente en el mundo real, ya que algunas de las detecciones antivirus de muestras de botnet tenían el prefijo "Noa-".
Las operaciones posteriores a la vulneración, que mostramos en la figura 4, tienen una evolución distinta. Estas no estaban presentes en las muestras anteriores que hemos investigado.
Fig. 5: Detecciones de NoaBot (izquierda) frente a otra variante de Mirai (derecha)
El minero y por qué no pudimos encontrar la dirección de su cartera
El minero en sí es mucho menos complicado. Se trata del minero XMRig estándar , aunque también era de compilación automática, y los atacantes agregaron le algo de código antes de su ejecución para extraer la configuración de minería en lugar de suministrarla a través de la línea de comandos o guardarla dentro del binario como texto sin formato (Figura 6).
Fig. 6: Función principal del minero
Podemos ver que hay otras llamadas a función antes de la llamada a función para crear la configuración de XMRig. Si falla, el minero finaliza; de lo contrario, pasa a la lógica del minero XMRig estándar. (Puede comparar la descompilación anterior con el código fuente de XMRigactual). ¿Por qué, como investigadores, nos preocupa la configuración de XMRig? Normalmente, contiene detalles sobre el pool de minería al que se conecta, así como la dirección de la cartera para recibir los pagos de minería. Al obtener la dirección de la cartera y realizar un seguimiento de los pagos (que suelen rastrear los pools públicos), podemos hacernos una idea de lo rentable que es la gig de criptominería.
En esta ocasión, sin embargo, los atacantes iban por delante de nosotros. Por ello, profundizaremos en la creación de la configuración. En el código abierto de XMRig, los mineros pueden aceptar configuraciones de dos maneras: mediante la línea de comandos o mediante variables de entorno. En nuestro caso, los atacantes decidieron no modificar el código original de XMRig y, a cambio, agregaron partes antes de la función principal. Para evitar la necesidad de utilizar argumentos de línea de comandos (que pueden ser un indicador de compromiso [IOC] y defensores de alertas), los atacantes hicieron que el minero sustituyera su propia línea de comandos (en términos técnicos, sustituyendo argv) por argumentos más "significativos" antes de pasar el control al código XMRig. La botnet ejecuta el minero con un argumento (como máximo) que le indica que imprima sus registros.
Sin embargo, antes de sustituir su línea de comandos, el minero tiene que crear su configuración. En primer lugar, copia los argumentos básicos que se almacenan en texto sin formato: el indicador rig-id, que identifica al minero con tres letras aleatorias, los indicadores threads y un marcador de posición para la dirección IP del pool (Figura 7).
Curiosamente, debido a que las configuraciones se cargan a través de los registros xmm, IDA en realidad pasa por alto los dos primeros argumentos cargados, que son el nombre de binario y el marcador de posición de la IP del pool.
Fig. 7: Copia de la configuración básica del minero
A continuación, el minero descifra el nombre de dominio del pool. El nombre de dominio se almacena, cifrado, en unos pocos bloques de datos que se descifran mediante operaciones XOR. Aunque XMRig puede trabajar con un nombre de dominio, los atacantes decidieron ir un paso más allá e implementaron su propia función de resolución de DNS. Se comunican directamente con el servidor DNS de Google (8,8.8,8) y analizan su respuesta para resolver el nombre de dominio en una dirección IP.
La última parte de la configuración también se cifra de forma similar y es la clave de acceso para que el minero se conecte al pool. En resumen, la configuración total del minero es similar a la siguiente:
<nombre_binario_minero> -o <ip_pool> --rig-id <id_aleatoria> --threads <cpu> –pass espana*tea |
¿Ha notado que falta algo? Sí, no hay una dirección de cartera.
Creemos que los atacantes decidieron ejecutar su propio pool privado en lugar de uno público, eliminando así la necesidad de especificar una cartera (su pool, sus reglas). Sin embargo, en nuestras muestras, observamos que los dominios de los mineros no se resolvían con el DNS de Google, por lo que en realidad no podemos probar nuestra teoría ni recopilar más datos del pool, ya que los dominios que tenemos ya no se pueden resolver. No hemos visto ningún incidente reciente que coloque el minero, así que también podría ser que los atacantes decidieran abandonar en busca de nuevas perspectivas.
Mirai es demasiado antiguo y ha desarrollado Rust
Los incidentes más recientes que hemos observado también tenían muestras de P2PInfect (un gusano que se replica de forma automática punto a punto escrito en Rust). Mientras que P2PInfect se vio por primera vez en julio de 2023, hemos detectado actividad de NoaBot desde enero de 2023, lo que significa que es solo un poco anterior a P2PInfect. ¿Por qué cambiar Mirai por otra cosa? ¿Por algo que incluso podría ser personalizado? No tenemos una respuesta clara, solo algunas conjeturas.
En primer lugar, es más difícil aplicar ingeniería inversa al código personalizado que al reutilizado porque se ha modificado. En segundo lugar, los atacantes parecen bastante expertos en tecnología, por lo que podría ser que estén intentando desarrollar malware por curiosidad o aburrimiento (o ambos). Por último, dado que P2PInfect tiene como objetivo los servidores Redis, podría tratarse simplemente de una cuestión de herramientas diferentes para diferentes fines.
¿Cómo sabemos que son los mismos atacantes, y no simplemente algún tipo de colaboración? No estamos al 100 % seguros, pero estamos cerca. Todo se reduce a la profesionalidad técnica del malware combinada con un nivel de madurez de un adolescente en lo que respecta a los chistes internos, incluida la inserción de groserías en nombre del minero, la incrustación de letras de canciones pop de juegos en binarios de malware y el envío de "hi" mientras se buscan puertos abiertos.
P2PInfect continúa esa tradición. Parece una herramienta sofisticada, pero utiliza un socket Unix y lo denomina "NunzombiE" (Figura 8). Y mientras NunzombiE está oculto y descodificado durante el tiempo de ejecución, el gusano también tiene cadenas incrustadas para "fast_vuln_file" y "slow_vuln_file" (cadenas perfectamente legítimas para contener un ejecutable, sin señales de alerta en este caso).
Fig. 8: strace del gusano P2PInfect que crea un socket Unix denominado NunzombiE
Victimología
Existen 849 direcciones IP de origen diferentes que han atacado nuestros cebos en 2023. Si observamos su geolocalización, podemos ver una distribución bastante uniforme de la actividad en todo el mundo. Esto tiene sentido, dado que el malware se puede propagar como gusano, por lo que cada nueva víctima se convierte en un atacante. Sin embargo, hay un único foco de actividad que destaca, y está en China. Representa casi el 10 % de todos los ataques que hemos visto en 2023 (es el punto más brillante de la Figura 9).
Fig. 9: Mapa de calor de geolocalización global de fuentes de ataque de NoaBot
Mitigación, detección, emulación
El método de movimiento lateral del malware se lleva a cabo mediante ataques simples de diccionario de credenciales SSH antiguos.
La restricción del acceso SSH arbitrario de Internet a su red disminuye en gran medida los riesgos de infección. Además, el uso de contraseñas seguras (no predeterminadas ni generadas aleatoriamente) también aumenta la seguridad de la red, ya que el malware utiliza una lista básica de contraseñas que se pueden adivinar. Hemos compartido los conjuntos de credenciales que utiliza el malware en nuestro Repositorio de GitHub.
No hay mucho que decir sobre la detección del malware, más allá que buscar sus nombres de binarios. Se ejecuta desde una carpeta que se genera de forma aleatoria en /lib, por lo que los nombres de proceso son probablemente el camino correcto. También debería ser posible detectar su trabajo Cron, si se ha instalado uno. Además, hay disponible un archivo CSV IOC en nuestro repositorio, así como algunas firmas de YARA para la mina.
En caso de que desee probar su entorno con el propagador SSH de la botnet, hemos creado un archivo de configuración para Infection Monkey, nuestra plataforma de emulación de adversarios de código abierto (hemos incluido una breve explicación sobre cómo utilizar Infection Monkey en el Apéndice). Tenga en cuenta que, dado que el malware utiliza un conjunto de credenciales muy grande, no sería práctico probarlas todas (al malware no le importan los costes de cálculo o tiempo, pero a nosotros sí). En su lugar, hemos optado por incluir solo las credenciales más comunes en la configuración. Si desea incluir más credenciales (o diferentes), no dude en desarrollar esta configuración e incluir sus propias modificaciones.
Esta configuración de Infection Monkey también agrega una cadena de enmascaramiento que hará que nuestras firmas de YARA se activen en la carga útil del agente Monkey, por lo que también podría utilizarla para probar esa detección.
Una vez que Infection Monkey haya terminado de probar su entorno, creará un informe de todas las máquinas que ha conseguido vulnerar. También puede utilizar su complemento de cryptojacking si desea llevar la simulación de ataque al siguiente nivel y probar credenciales más seguras.
Resumen
En la superficie, NoaBot no es una campaña muy sofisticada, es "simplemente" una variante de Mirai y una criptominería XMRig, que en la actualidad son muy comunes. Sin embargo, las ocultaciones agregadas al malware y las adiciones al código fuente original presentan una imagen muy diferente de las capacidades de los atacantes. A pesar de las competencias técnicas de los atacantes, parecen tener algunas convenciones de nomenclatura inmaduras (por ejemplo, un socket Unix llamado "NunzombiE") que se mantienen incluso en diferentes muestras y binarios de malware. Utilizamos esta característica para asociar NoaBot a P2PInfect, y quizás este indicio de detección se cumpla en futuras campañas de malware.
Apéndice: uso de Infection Monkey para probar su entorno
Instale Infection Monkey, según su sistema operativo:
Siga las instrucciones de configuración.
Descargue el complemento de explotación SSH de la página de complementos de la interfaz de usuario de Infection Monkey.
Fig. 10: Pantalla del complemento de Infection Monkey. Utilice la barra de búsqueda para buscar el complemento de explotación SSH y descargarlo.
Importe el archivo de configuración para emular NoaBot.
Fig. 11: Pantalla de configuración de Infection Monkey. Puede importar la configuración que proporcionamos pulsando el botón “Import config” (Importar configuración).
Configure los objetivos sobre los que intentar un ataque en la pestaña de "análisis de red" de la página de configuración.
Ejecute Monkey.
Vaya a la página de mapa para observar el ataque.
Si, en cualquier momento, desea detener la simulación, solo tiene que pulsar el botón para "detener todos los Monkeys" y finalizar el ataque.
