synawk

Masjesu es una botnet interesante, como se menciona en el titulo, el malware usado por esta botnet, despliega diferentes formatos de binarios intentando ejecutarlos en el sistema afectado. Pero vayamos al principio; como es que esta botnet pasa a infectar el sistema.

Al ingresar al sistema a través de fuerza bruta por el protocolo SSH, de forma automatizada se descarga un script llamado bins.sh, esto se puede ver en la siguiente imagen:

Como con muchas otras botnets, este script de acceso inicial sirve para descargar y ejecutar el formato correcto para el sistema en donde se esta ejecutando. En este caso en particular, el autor de este malware no repara en identificar el tipo de sistema donde se encuentra, si no mas bien descarga todos los formatos disponibles y luego pasa a ejecutarlos esperando que alguno funcione. Una solución simple que no requiere mayor esfuerzo.

Al descargar todos los archivos se puede ver que cada uno corresponde a una versión especifica para cada arquitectura disponible.

Para este análisis, se utilizó el binario 3I8g5yO42xhH, el cual corresponde a la arquitectura x86-64, facilitando así el proceso de reversing e inspección de su contenido. Como primer paso, revisamos lo que nos muestra la herramienta capa para identificar las posibles acciones que el malware podría estar llevando a cabo.

Los resultados indican que el malware está estableciendo una conexión hacia un servidor de control (C2), lo cual es evidente al tratarse de una botnet. Sin embargo, es importante destacar que la información se encuentra ofuscada, por lo que para extraerla debemos identificar los algoritmos usados. Le damos un vistazo ahora a lo que nos muestra IDA.

Al abrir el código, se observan numerosas funciones con nombres como unlockthis, getmethis, detroythis, etc. Al acceder a una de ellas, se evidencia su interacción con una región denominada tables. Se presume que en algún punto del código se realiza la inicialización de una serie de valores en una determinada región de memoria, la cual posteriormente es consultada. De hecho, como se aprecia en la imagen previa, se encuentra presente una función denominada table_init. Por lo que al revisarla se puede ver que el código ejecuta varias funciones que agregan ciertos bytes a una función addthis.

Como es de esperarse dentro de esta función addthis se le debe pasar 2 argumentos, el primero es el índice y el segundo la ruta de los bytes a agregar. De hecho al ingresar a la función se puede ver justamente eso:

Con esta información, se pueden comenzar a realizar muchas acciones. El camino más fácil es llevar a cabo un análisis dinámico y detenerse precisamente en cada una de las funciones que retorna dicho valor. Sin embargo, esto es demasiado simple, y me bastaría con realizar algunos breakpoints en los lugares correctos. Por ejemplo, en la siguiente imagen, obtengo el valor de uno de los strings ofuscados que corresponden a la creación de cronjobs.

Para hacerlo más desafiante, lo realicé solo con análisis estático, es decir, sin ejecutar el binario. Para lograrlo, es necesario primero pensar en cómo hacerlo. Lo primero que se me ocurrió fue tomar todas las direcciones en donde se almacenan estos valores, junto con sus tamaños. Todo esto lo llevé a un script en Python, que junto con radare2, me permitió obtener los bytes que corresponden a cada sección.

Una vez capturados los bytes de cada región, lo que falta es el desencriptado. Dado que está ofuscado con algún algoritmo, es necesario realizar reversing a esa función. La función con dicho algoritmo es translatemethis, y realiza una serie de operaciones en el string proporcionado, tomando como argumento el índice dentro de la tabla.

Aunque pueda parecer una función altamente compleja, la realidad es que es bastante simple. De hecho, es más sencillo ver el código en ASM para darse cuenta de que existe un bloque que se repite la longitud de la table_key, que es 3. Y lo que realiza es un simple XOR basado en el table_key con valor [0x16, 0x9f, 0x8]

Con esto, ya podemos desofuscar las cadenas de texto que se pudieron extraer anteriormente, y modificando el código en Python para agregar el algoritmo que realice un XOR 3 veces a cada byte. Esta función servirá mas adelante para otras operaciones que realiza el malware.

Ahora que ya se tienen los strings expuestos, se puede continuar con el flujo del malware, conociendo qué cadena de texto corresponde a cada parte. El malware realiza una serie de acciones, como agregar un cron, crear un subproceso o eliminar algunos binarios. Pasaré por alto estos detalles, ya que no aportan nada nuevo a los malwares tradicionales. Iré directamente a lo importante: la conexión al C2 que realiza.

Para obtener la conexión se pueden utilizar diversos métodos, en primer lugar dentro del código esta expuesto el SERVER_IP que corresponde al servidor usado para la conexión.

Por otro lado para capturar el puerto, se debe puede ver también dentro del código lo siguiente:

A simple vista, es difícil verlo, pero el v34 se refiere a la estructura sockaddr, que en este caso configura dos atributos: el tipo de conexión y el puerto. Precisamente para este último, se encuentra dentro de la lista ofuscada. Ya que tenemos esta información y se trata de la dirección 0x49f008, que tiene como valor 448, podemos confirmar que este valor representa el puerto. Otra forma de obtenerlo es utilizando tcpdump -i eth0 en un entorno controlado. En ambos casos, se puede obtener el puerto.

Al probar la conexión, no esperaba que el servicio estuviera activo; sin embargo, se obtuvo una respuesta. Como se puede ver en la siguiente imagen, el servicio responde de manera satisfactoria, por lo que es posible interactuar con él. El único inconveniente es que está encriptado, y además, aún no conocemos la forma de interactuar con el servicio.

Aquí viene la parte interesante, ya que se pudo identificar que una vez establecida la conexión, el malware realiza las siguientes acciones:

1. Espera por la data remota usando recv
2. Se recibe la data y se pasa por translatemethis para desofuscar su contenido.
3. Una vez se recibe el contenido, se puede ver una serie de valores aleatorias que parece ser base64, sin embargo se trata de una cadena de texto aleatoria.
4. Se realiza un split esperando que el valor venga con un formato separado por espacios es decir [RANDOM_STRING] [ARG1] [ARG2] …
5. Finalmente basado en la longitud del string decide que camino tomar; esto es un poco fuera de lo común, ya que no lo hace basado en algún comando si no en la longitud de la cadena de texto.

El flujo se repite cada vez que se recibe un “comando”. Algunas de las acciones incluyen la realización de un TCP SYN/ACK y también involucra una acción para establecer conexiones UDP. Por supuesto, hay un comando diseñado para detener el proceso en esa instancia. Todas estas operaciones son comunes en un malware que conecta el equipo afectado a una botnet. Sin embargo, lo que quería lograr era poder conectarme a través de un script en Python y recibir los comandos que el C2 está ejecutando para identificar qué acciones realiza y con qué frecuencia.

Al momento de realizar la conexion, el malware envia un string generado de forma aleatoria hacia el C2, al parecer esto con el objetivo que mantener la conexion activa, digamos en modo idle. La longitud de esta cadena de texto esta definida de la siguiente manera

Se puede ver que solo permite 4 longitudes. Este código lo convertimos a código Python para poder interactuar directamente desde ahí. Adicionalmente, agregamos el código para desofuscar que ya teníamos anteriormente. También, añadimos una condición para que cada vez que encuentre una longitud distinta a la que corresponde al modo idle, lo guarde en un archivo de texto. La siguiente imagen muestra la validación una vez que recibe una cadena de texto con una de las longitudes posibles. Si se recibe de esa forma, el malware genera un string con las otras longitudes mostradas anteriormente y procede a enviarlo al C2.

Se ejecutó el script de Python y luego de esperar unos minutos ya había capturado algunos de los comandos enviados por el C2 para realizar ciertas acciones. Cabe mencionar que la mayoría de las IPs atacadas pertenecen a Europa del Este y Asia.

Al tratarse de un malware que se conecta a una botnet, no contiene mucho más de lo que la mayoría de malwares de este tipo tiene. El desarrollo no se muestra muy avanzado, y la frecuencia con la que se reciben los comandos es baja, por lo que es probable que no existan muchos equipos infectados con este malware.

Lo que sí es importante destacar es que cuentan con un canal de Telegram público que permite adquirir el servicio de la botnet; el cual cuenta con un poco más de 700 suscriptores.

Conclusiones

El malware utilizado por la botnet es simple pero efectivo. Además, los ataques no ocurren con mucha frecuencia; es decir, hay bastante tiempo entre los comandos. Es esencial señalar que hasta la fecha, no hemos encontrado información ni análisis en internet sobre esta botnet y su malware. Considerando la fecha de la primera publicación de la botnet en Telegram (27 de diciembre del 2023), se puede asumir que es una botnet relativamente nueva y muy probablemente aún en desarrollo. No obstante, esto no la excluye como una potencial amenaza para dispositivos IoT.

IoCs

Archivos (sha-1)

e84c063c36a84fa6ab78bd2e88930fd47bcf4ad1
8d46ef6bb2736939d6b45b0d64f6085fb31029fc
87802e0472a4661b2935e554a1f7370687c92602
37a801da2c939e6f48d7ee38f334a61d38397070
435c981650c55a51716d32a7c722eae47ecdecb7
992004ac861076e7d045b125f4b930b72b6b4c62
4fcd6c9051289b0cc14d88ab7b3efee13792312b
0a1cd98a7bb2e3e2c709291f947235be8e3dd2d2
026a89c1d4a5957641744fb13ef0394c1357f784
a24cf296569b740e4b3908d5f4d66bb890459d24
0fd99d5dd23680f1f8c0d2b655f23fa66a75948b
f58df53ce332297e8fe7fc23fb1abcb57a5ae39e
c5ddc79fa15a8c68d109c53aeca4ac41f74c16da
5b6e1b5695d490bd7dc5411c84a10252d0954f04

Red

163.5.59.40
37.44.238.123