Basado en el malware Mirai, el NoaBot autorreplicante instala una aplicación de minería de criptomonedas en los dispositivos infectados.
El gusano es una versión personalizada de Mirai, el malware botnet que infecta servidores basados en Linux, routers, cámaras web y otros dispositivos del llamado Internet de las Cosas. Mirai salió a la luz en 2016, cuando se utilizó para realizar ataques distribuidos de denegación de servicio sin precedentes que paralizaron partes clave de Internet ese año.
Sus creadores no tardaron en publicar el código fuente subyacente, lo que permitió a una gran variedad de grupos delictivos de todo el mundo incorporar Mirai a sus propias campañas de ataque. Una vez que se apodera de un dispositivo Linux, Mirai lo utiliza como plataforma para infectar otros dispositivos vulnerables, un diseño que lo convierte en un gusano, es decir, que se autorreplica.
Una docena de malware con un toque especial
Tradicionalmente, Mirai y sus numerosas variantes se han propagado cuando un dispositivo infectado rastrea Internet en busca de otros dispositivos que acepten conexiones Telnet. A continuación, los dispositivos infectados intentan descifrar la contraseña de Telnet adivinando los pares de credenciales predeterminados y de uso común. Cuando tienen éxito, los nuevos dispositivos infectados atacan a otros dispositivos utilizando la misma técnica. Mirai se ha utilizado principalmente para realizar ataques DDoS. Dada la gran cantidad de ancho de banda disponible para muchos de estos dispositivos, las avalanchas de tráfico basura suelen ser enormes, lo que confiere a la red de bots en su conjunto una enorme potencia.
El miércoles, investigadores de la empresa de seguridad y fiabilidad de redes Akamai revelaron que una red basada en Mirai previamente desconocida a la que apodaron NoaBot ha estado atacando dispositivos Linux desde al menos el pasado mes de enero. En lugar de atacar las contraseñas débiles de telnet, NoaBot ataca las contraseñas débiles que conectan conexiones SSH. Otra novedad: en lugar de realizar ataques DDoS, la nueva botnet instala software de minería de criptomonedas, que permite a los atacantes generar monedas digitales utilizando los recursos informáticos, la electricidad y el ancho de banda de las víctimas. El criptominero es una versión modificada de XMRig, otro malware de código abierto. Más recientemente, NoaBot se ha utilizado también para distribuir P2PInfect, un gusano independiente que los investigadores de Palo Alto Networks revelaron el pasado mes de julio.
Akamai ha estado monitorizando NoaBot durante los últimos 12 meses en un honeypot que imita dispositivos Linux reales para rastrear diversos ataques que circulan en la naturaleza. Hasta la fecha, los ataques se han originado desde 849 direcciones IP distintas, casi todas ellas probablemente alojando un dispositivo que ya está infectado. La siguiente figura muestra el número de ataques enviados al honeypot a lo largo del año pasado.
A primera vista, NoaBot no es una campaña muy sofisticada: es "solo" una variante de Mirai y un cryptominer XMRig, y hoy en día hay de todo", escribió Stiv Kupchik, investigador principal de seguridad de Akamai, en un informe publicado el miércoles. "Sin embargo, las ofuscaciones añadidas al malware y las adiciones al código fuente original pintan una imagen muy diferente de las capacidades de los actores de la amenaza."
La capacidad más avanzada es la forma en que NoaBot instala la variante XMRig. Normalmente, cuando se instalan los mineros de criptomonedas, los fondos de las carteras se distribuyen a se especifican en los ajustes de configuración entregados en una línea de comandos emitida al dispositivo infectado. Este método ha supuesto durante mucho tiempo un riesgo para los actores de amenazas, ya que permite a los investigadores rastrear dónde se alojan los monederos y cuánto dinero ha entrado en ellos.
NoaBot utiliza una técnica novedosa para evitar esta detección. En lugar de enviar los parámetros de configuración a través de una línea de comandos, la red de bots los almacena cifrados u ofuscados y los descifra sólo después de cargar XMRig en la memoria. La botnet sustituye entonces la variable interna que normalmente contendría los parámetros de configuración de la línea de comandos y pasa el control al código fuente de XMRig.
Kupchik ofreció una descripción más técnica y detallada:
En el código fuente abierto de XMRig, los mineros pueden aceptar configuraciones de dos maneras: a través de la línea de comandos o mediante variables de entorno. En nuestro caso, los actores de la amenaza optaron por no modificar el código original de XMRig y, en su lugar, añadieron partes antes de la función principal. Para eludir la necesidad de argumentos en la línea de comandos (que puede ser un indicador de compromiso IOC y alertar a los defensores), los actores de la amenaza hicieron que el minero sustituyera su propia línea de comandos (en términos técnicos, sustituir argv) con argumentos más "significativos" antes de pasar el control al código XMRig. La botnet ejecuta el minero con (como máximo) un argumento que le indica que imprima sus registros. Sin embargo, antes de reemplazar su línea de comandos, el minero tiene que construir su configuración. En primer lugar, copia los argumentos básicos que se almacenan en texto plano: la bandera rig-id, que identifica al minero con tres letras aleatorias, las banderas de los hilos y un marcador de posición para la dirección IP del pool.
A continuación, el minero descifra el nombre de dominio del pool. El nombre de dominio se almacena, cifrado, en unos bloques de datos que se descifran mediante operaciones XOR. Aunque XMRig puede trabajar con un nombre de dominio, los atacantes decidieron dar un paso más e implementaron su propia función de resolución DNS propia. 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 está cifrada 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 se parece a esto:
-o --rig-id --threads -pass espana*tea
¿Notas que falta algo? Sí, no hay dirección de cartera.
Creemos que los actores de la amenaza eligieron ejecutar su propio pool privado en lugar de uno público, eliminando así la necesidad de especificar un monedero (¡su pool, sus reglas!). Sin embargo, en nuestras muestras, observamos que los dominios de los mineros no se resolvían con los DNS de Google, por lo que realmente no podemos probar nuestra teoría ni recopilar más datos del pool, ya que los dominios que tenemos ya no son resolubles. No hemos visto ningún incidente reciente que deje caer el minero, por lo que también podría ser que los actores de la amenaza decidieran marcharse a pastos más verdes.
Fuente: somoslibres
