Los dispositivos Linux están siendo atacados por un gusano nunca antes visto

Durante el año pasado, un malware autorreplicante previamente desconocido ha estado comprometiendo dispositivos Linux en todo el mundo e instalando malware de criptominería que toma medidas inusuales para ocultar su funcionamiento interno, dijeron los investigadores.

El gusano es una versión personalizada de Mirai, el malware botnet que infecta servidores, enrutadores, cámaras web y otros dispositivos de Internet de las cosas basados ​​en Linux. Mirai salió a la luz en 2016 cuando se utilizó para realizar ataques distribuidos de denegación de servicio que batieron récords y paralizaron partes clave de Internet ese año. Los creadores pronto publicaron el código fuente subyacente, una medida que permitió a una amplia gama de grupos criminales de todo el mundo incorporar a Mirai en 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 programas maliciosos con un toque especial

Tradicionalmente, Mirai y sus numerosas variantes se han propagado cuando un dispositivo infectado escanea Internet en busca de otros dispositivos que acepten conexiones Telnet. Luego, 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 dispositivos recién infectados se dirigen a dispositivos adicionales, utilizando la misma técnica. Mirai se ha utilizado principalmente para realizar ataques DDoS. Dadas las grandes cantidades de ancho de banda disponibles para muchos de estos dispositivos, las avalanchas de tráfico basura suelen ser enormes, lo que otorga a la botnet en su conjunto un tremendo poder.

El miércoles, investigadores de la firma de confiabilidad y seguridad de redes Akamai revelaron que una red basada en Mirai previamente desconocida a la que denominaron NoaBot ha estado apuntando a dispositivos Linux desde al menos el pasado mes de enero. En lugar de apuntar a contraseñas de telnet débiles, NoaBot apunta a contraseñas débiles que se conectan SSH conexiones. Otro giro: 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 también se ha utilizado para entregar P2PInfect, un gusano independiente que investigadores de Palo Alto Networks revelado el pasado mes de julio .

Akamai ha estado monitoreando NoaBot durante los últimos 12 meses en un honeypot que imita dispositivos Linux reales para rastrear varios ataques que circulan en la naturaleza. Hasta la fecha, los ataques se han originado desde 849 direcciones IP distintas, casi todas las cuales probablemente alojan un dispositivo que ya está infectado. La siguiente figura rastrea la cantidad de ataques realizados al honeypot durante el año pasado.

“A primera vista, NoaBot no es una campaña muy sofisticada; es ‘sólo’ una variante de Mirai y un criptominero XMRig, y hoy en día se venden a diez centavos la docena”, escribió el investigador senior de seguridad de Akamai, Stiv Kupchik, en un informe el miércoles. “Sin embargo, las ofuscaciones agregadas al malware y las adiciones al código fuente original pintan una imagen muy diferente de las capacidades de los actores de amenazas”.

La capacidad más avanzada es la forma en que NoaBot instala la variante XMRig. Por lo general, cuando se instalan criptomineros, los fondos de las billeteras a las que se distribuyen se especifican en los ajustes de configuración entregados en una línea de comando enviada al dispositivo infectado. Este enfoque ha planteado durante mucho tiempo un riesgo para los actores de amenazas porque permite a los investigadores rastrear dónde están alojadas las billeteras y cuánto dinero ha ingresado en ellas.

NoaBot utiliza una técnica novedosa para evitar dicha detección. En lugar de entregar los ajustes de configuración a través de una línea de comando, la botnet almacena los ajustes en forma cifrada u ofuscada y los descifra solo después de que XMRig se carga en la memoria. Luego, la botnet reemplaza la variable interna que normalmente contendría los ajustes de configuración de la línea de comando 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 comando o mediante variables de entorno. En nuestro caso, los actores de amenazas optaron por no modificar el código original de XMRig y en su lugar agregaron partes antes de la función principal. Para evitar la necesidad de argumentos en la línea de comando (que pueden ser un indicador de compromiso del COI y alertar a los defensores), los actores de la amenaza hicieron que el minero reemplazara su propia línea de comando (en términos técnicos, reemplazando argv) con argumentos más “significativos” antes de pasar el control. al código XMRig. La botnet ejecuta al minero con (como máximo) un argumento que le indica que imprima sus registros. Sin embargo, antes de reemplazar su línea de comando, el minero debe crear su configuración. Primero, copia argumentos básicos que se almacenan en texto sin formato: el indicador rig-id, que identifica al minero con tres letras aleatorias, los indicadores de subprocesos y un marcador de posición para la dirección IP del grupo (Figura 7).

Curiosamente, debido a que las configuraciones se cargan a través de los registros xmm, IDA en realidad omite los dos primeros argumentos cargados, que son el nombre binario y el marcador de posición de IP del grupo.

A continuación, el minero descifra el nombre de dominio del grupo. El nombre de dominio se almacena, cifrado, en unos pocos bloques de datos que se descifran mediante operaciones XOR. Aunque XMRig puede funcionar con un nombre de dominio, los atacantes decidieron dar un paso más e implementaron su propio DNS.
función de resolución. 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 manera similar y es la clave de acceso para que el minero se conecte al grupo. Con todo, la configuración total del minero se ve así:

-o --rig-id --threads –pass espana*tea

¿Notas que falta algo? Sí, no hay dirección de billetera.

Creemos que los actores de amenazas eligieron ejecutar su propio grupo privado en lugar de uno público, eliminando así la necesidad de especificar una billetera (¡su grupo, 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 realmente no podemos probar nuestra teoría ni recopilar más datos del grupo, ya que los dominios que tenemos ya no se pueden resolver. No hemos visto ningún incidente reciente que haga caer al minero, por lo que también podría ser que los actores de la amenaza hayan decidido partir hacia pastos más verdes.