Malware ilegal para Linux: persistente, poco sofisticado y sorprendentemente eficaz

Prefacio

OUTLAW es un paquete de minería de monedas autopropagante persistente pero poco sofisticado, observado en múltiples versiones durante los últimos años [1], [2], [3], [4]. A pesar de carecer de sigilo y técnicas de evasión avanzadas, sigue activo y eficaz aprovechando tácticas simples pero impactantes, como la fuerza bruta de SSH, la persistencia basada en cron y claves SSH, y los mineros de productos básicos modificados manualmente y los canales de IRC. Esta persistencia resalta cómo los operadores de botnets pueden lograr un impacto generalizado sin depender de técnicas sofisticadas.

Para comprender mejor el comportamiento y los patrones operativos de OUTLAW, implementamos un honeypot diseñado para atraer y observar a los atacantes en acción. Al crear cuidadosamente un entorno que imitaba un sistema vulnerable, pudimos incitar a los adversarios a interactuar con nuestro servidor. Esta interacción reveló acciones automatizadas y manuales, con operadores ingresando comandos directamente, haciendo modificaciones sobre la marcha e incluso escribiendo mal los comandos: claros indicadores de participación humana. Un GIF capturado muestra estos momentos y ofrece una visión poco común de su proceso de toma de decisiones en tiempo real.

Al analizar OUTLAW, obtenemos nuevos conocimientos sobre las herramientas empleadas por sus operadores y sus estrategias cambiantes a lo largo del tiempo. Este malware presenta una valiosa oportunidad para aplicar principios de ingeniería de detección, ya que su cadena de ataque abarca casi todo el marco MITRE ATT&CK. Examinar su proceso de infección nos permite desarrollar estrategias de detección efectivas que aprovechen sus comportamientos previsibles y repetitivos.

Este reporte proporciona un análisis completo de la cadena de ataque, incluidas reglas de detección detalladas y consultas de búsqueda. Al analizar los componentes de OUTLAW, demostramos cómo incluso el malware rudimentario puede mantener la longevidad en entornos modernos y cómo los defensores pueden aprovechar su simplicidad para mejorar la detección y la respuesta.

Conclusiones clave

Persistente pero poco sofisticado: OUTLAW sigue activo a pesar de emplear técnicas básicas como fuerza bruta de SSH, manipulación de claves SSH y persistencia basada en cron.
Herramientas de productos básicos: el malware implementa mineros XMRig modificados, aprovecha IRC para C2 e incluye scripts disponibles públicamente para persistencia y evasión de defensa.
Amplia superficie de ataque: la cadena de infección de OUTLAW abarca casi todo el marco MITRE ATT&CK, lo que ofrece muchas oportunidades de detección y búsqueda.
Propagación similar a un gusano: OUTLAW emplea sus hosts comprometidos para lanzar más ataques de fuerza bruta SSH en sus subredes locales, expandiendo rápidamente la botnet.

Descripción general de OUTLAW

OUTLAW sigue un proceso de infección de varias etapas que comienza con la descarga y ejecución de su carga útil, el establecimiento de persistencia y la expansión de su botnet a través de ataques de fuerza bruta SSH. La cadena de ejecución se muestra a continuación:

1. Infección inicial y despliegue

El ataque comienza cuando tddwrt7s.sh descarga el paquete dota3.tar.gz de un servidor C2.
El script initall.sh extraído se ejecuta, iniciando la cadena de infección.

2. Ganando control y persistencia

El malware cerciora el dominio eliminando a los mineros y a los atacantes de fuerza bruta de la competencia.
Luego se despliega:
- XMRIG modificado para minería de criptomonedas (conexión a un grupo de minería).
- STEALTH SHELLBOT para control remoto vía IRC C2.
- BLITZ para realizar ataques de fuerza bruta SSH.

3. Propagación y expansión

El módulo de fuerza bruta recupera listas de objetivos de un servidor C2 SSH e intenta ataques de fuerza bruta SSH en nuevas máquinas.
Los sistemas comprometidos con éxito se infectan y repiten el ciclo.

Este bucle de infección automatizado permite que OUTLAW permanezca activo y rentable con un esfuerzo mínimo por parte de los atacantes. Echemos un vistazo más profundo a toda la cadena de ataque.

Cadena de ejecución de OUTLAW

OUTLAW cubre eficazmente una amplia gama de tácticas y técnicas en el marco MITRE ATT&CK. Esta sección mapea su comportamiento para proporcionar una descripción general de su cadena de infección y sus métodos.

Acceso inicial: blitz

OUTLAW obtiene acceso inicial a través de ataques de fuerza bruta SSH oportunistas, apuntando a sistemas con credenciales débiles o predeterminadas. El malware emplea su componente blitz , también conocido con otros nombres como kthreadadd, para realizar escaneos de gran volumen e intentos de adivinación de contraseñas. Aprovecha listas de direcciones IP de destino y credenciales recuperadas de sus servidores C2.

OUTLAW también actúa como un gusano, instalar automáticamente en cada sistema que compromete con éxito. Este mecanismo de autopropagación le permite propagar rápidamente a través de las redes, convirtiendo cada dispositivo recién infectado en otro nodo para futuros intentos de infección y ataque de fuerza bruta.

Analizaremos con más profundidad cómo OUTLAW realiza estos ataques y se propaga más adelante en el artículo.

Ejecución: tddwrt7s.sh

Las primeras infecciones de OUTLAW parecen originar a partir de un sencillo script dropper: tddwrt7s.sh. Este script de shell comprueba si existe una instalación. Si el malware ya está presente y descomprimido, ejecutará el script initall, iniciando así la cadena de infección. De lo contrario, intentará descargar el paquete desde una lista de servidores de prueba proporcionados. A modo de ilustración, se muestra a continuación un fragmento abreviado del gotero:

El paquete dota3.tar.gz extraído extrae su contenido en una carpeta oculta llamada .rsync y contiene las siguientes entradas:

 ├── a
 │   ├── a
 │   ├── init0
 │   ├── kswapd0
 │   ├── kswapd01
 │   ├── run
 │   ├── socat
 │   └── stop
 ├── b
 │   ├── a
 │   ├── run
 │   └── stop
 ├── c
 │   ├── blitz
 │   ├── blitz32
 │   ├── blitz64
 │   ├── go
 │   ├── run
 │   ├── start
 │   ├── stop
 │   └── v
 ├── init
 ├── init2
 └── initall

Desconstruyamos las cadenas de ejecución una por una.

Script de inicialización principal: initall

Los tres scripts init controlan el flujo general de ejecución y la implementación del malware. A partir del script initall , el inicializador principal determina qué ruta de ejecución tomar. Comprueba el entorno del sistema y decide si emplear init o init2 en función de las licencias de archivo y los directorios disponibles.

Todos estos scripts init emplean ofuscación por concatenación de cadenas basada en variables, donde los comandos se dividen en pequeños fragmentos de variables que se concatenan y ejecutan dinámicamente, lo que dificulta el análisis estático. Por ejemplo, el script initall se ve así:

Sin embargo, al cambiar eval por echo, podemos obtener el resultado sin ningún esfuerzo:

De forma predeterminada, este script ejecutará consistentemente init. Esta es la ruta de ejecución principal que instala el malware en el directorio oculto ~/.configrc6. La ruta de ejecución alternativa es init2, que se emplea cuando ~/.configrc6 no es accesible. La principal diferencia es que esta ruta mantiene todos los componentes en el directorio de trabajo actual. Aplicando el mismo principio de desofuscación que usamos anteriormente, terminamos con los siguientes dos scripts:

El primer script (init) oculta sus componentes en el directorio oculto ~/.configrc6, mientras que el segundo script (init2) se ejecuta directamente desde el directorio de trabajo. A pesar de esta diferencia, el flujo de ejecución sigue siendo el mismo, iniciando el binario llamado a en los directorios a/ y b/ como procesos en segundo plano y estableciendo persistencia. En ambos scripts, el malware instala trabajos cron que ejecutan sus binarios a intervalos regulares y al resetear el sistema:

5 6 * * 0   ~/.configrc6/a/upd
@reboot     ~/.configrc6/a/upd
5 8 * * 0   ~/.configrc6/b/sync
@reboot     ~/.configrc6/b/sync
0 0 */3 * * ~/.configrc6/c/aptitude

Aunque los scripts ejecutan el binario a en los directorios a/ y b/ casi simultáneamente, seguiremos primero el flujo de ejecución del directorio a/ .

Ejecución de subrutina de un directorio: XMRIG

El primer script que se ejecuta es a, que elimina cualquier trabajo cron existente que emplee crontab -r y luego almacena el directorio de trabajo actual en una variable. Luego crea un script de shell llamado upd que verifica si un proceso (almacenado en bash.pid) todavía está ejecutar. Si el proceso no se está ejecutando, ejecuta ./run como un proceso en segundo plano, lo que garantiza que el malware se resetear continuamente si se finaliza.

Además, vemos algunos comandos comentados que indican que pueden existir otras versiones de este malware con nombres como rsync, go, kswapd0, blitz, y redtail.

Más abajo en el script, se crea una función que verifica si /sys/module/msr/parameters/allow_writes existe y lo establece en "activado" para habilitar la escritura en registros específicos del modelo (MSR). Si el archivo no existe, habilita la escritura de MSR a través del comando modprobe msr allow_writes=on .

A continuación, la función identifica la CPU activa marcando /proc/cpuinfo y aplica valores de registro MSR específicos para optimizar el rendimiento.

Por último, la función optimiza el uso de la memoria al habilitar hugepages para todos los núcleos de CPU, lo que aumenta la eficiencia del acceso a la memoria. Calcula la cantidad de hugepages necesarios en función de los procesadores disponibles (nproc) y los establece en los directorios /sys/devices/system/node/node*/hugepages/ .

La función optimize_func() no fue creada por el actor de la amenaza. El actor de amenazas empleó un script de código abierto del repositorio XMRig , específicamente el script randomx_boost.sh , para ayudar en su cadena de infección.

Dependiendo de los privilegios del usuario, ejecutará toda la función de optimización o intentará establecer el número de hugepages a sysctl:

Todos los pasos realizados en esta cadena muestran signos aparentes de optimización del sistema de minería de criptomonedas. Finalmente, el script otorga licencias de ejecución al archivo upd y licencias "777" a todos los archivos en su carpeta y ejecuta upd.

Como vimos anteriormente en la cadena, el archivo upd verifica si el proceso almacenado en bash.pid todavía se está ejecutando y, si no es así, ejecutará el script run :

El script de ejecución iniciará el script stop , que es un script típico que derriba las defensas de cualquier configuración de minero conocida y elimina cualquier proceso de minero conocido en función del nombre/ID del proceso o el tráfico de red. A continuación se ilustra una versión abreviada de este script:

Curiosamente, existe un segundo script de eliminación de procesos llamado init0 , que es un script de código abierto para matar mineros de criptomonedas en un entorno Linux. Este script no se está ejecutando porque el flujo de ejecución de este script fue comentado en el script a .

Luego de ejecutar exitosamente el script stop , el script run inicia los binarios kswapd01 y kswapd0 en segundo plano a través de nohup.

kswapd01

El binario kswap01 juega un papel fundamental para garantizar la comunicación persistente dentro de la infraestructura del malware. Su tarea principal es monitorear y mantener un proceso socat continuo, que es esencial para la comunicación con los servidores C2 del atacante.

Cuando se ejecuta, kswap01 comprueba si hay algún proceso socat existente ejecutar en la máquina infectada. Si no se encuentra ninguna conexión activa, procede a matar cualquier proceso socat en ejecución y selecciona una dirección IP alternativa de una lista predefinida. Luego, el binario establece una nueva conexión lanzando un nuevo proceso socat para escuchar en la máquina local y reenviar el tráfico a un servidor remoto, generalmente en el puerto 4444. Esto garantiza que el malware mantenga el control sobre el sistema infectado y pueda seguir recibiendo comandos del atacante.

Sin embargo, es importante tener en cuenta que no todas las versiones del paquete de malware OUTLAW observadas incluyen el binario socat . En estos casos, la funcionalidad proporcionada por socat se replica por otros medios o simplemente se omite, y se recurre a métodos alternativos para mantener la persistencia y la comunicación.

Al realizar estas comprobaciones y modificaciones, kswap01 ayuda a mantener la persistencia de la conexión C2, lo que dificulta que los defensores interrumpan el canal de comunicación entre el atacante y el sistema comprometido.

kswapd0

El archivo llamado kswapd0 es una copia modificada maliciosamente del minero de criptomonedas legítimo XMRig (específicamente la versión 6.22.1).

Dos modificaciones importantes definen el comportamiento del malware:

1. Comandos del shell de inicio

El malware elimina y recrea la carpeta ~/.ssh de la víctima, inyecta una clave pública SSH controlada por el atacante y vuelve a aplicar licencias restrictivas (chattr +ia) para evitar modificaciones. Esto otorga acceso SSH persistente.
También elimina o bloquea los archivos de configuración XMRig existentes (por ejemplo, ~/.xmrig.json, ~/.config/xmrig.json) para garantizar que las configuraciones del minero integrado del atacante permanezcan intactas.

2. Configuración del minero integrado

El binario se compila con una configuración de minería interna, lo que permite que XMRIG se ejecute sin un archivo de configuración externo.
El tráfico de minería se enruta a múltiples grupos de Monero a través de puertos de texto simple (:80, :4444), SSL (:442) y, ocasionalmente, direcciones TOR. Tenga en cuenta que el puerto 442 aquí no es un error tipográfico.
La configuración optimiza el rendimiento mediante:
- Ejecutar el minero en segundo plano
- Habilitar páginas grandes para RandomX
- Establecer el nivel de donación a cero
- Maximizar el uso de subprocesos de CPU

Al bloquear a los administradores, evitar cambios de configuración e inyectar una clave SSH controlada por el atacante, kswapd0 actúa como un mecanismo de persistencia sigiloso, lo que permite la minería continua de Monero y el acceso remoto no autorizado, todo ello mientras se hace pasar por un proceso legítimo del sistema.

Ejecución de subrutina del directorio b/: STEALTH SHELLBOT

Como describimos anteriormente, el binario a en el directorio b/ también se ejecutó a través de los scripts init .

Este script inicia otro script stop con el mismo propósito que describimos anteriormente: matar cualquier proceso malo conocido. Posteriormente, crea un script llamado sync, con el único propósito de ejecutar el script run . Este script está referenciado en el cronjob que describimos anteriormente. El script run contiene tres blobs codificados en base64, que se envían a perl. A continuación se muestra un ejemplo de un script abreviado:

Durante la decodificación base64, se identifican los scripts perl ofuscados. Estos scripts aprovechan una utilidad pública Perl Ofuscator para ofuscar su contenido, haciéndolos más difíciles de analizar:

Afortunadamente, el autor dejó los comentarios estándar en los scripts ofuscados. Usando el desofuscador disponible públicamente podemos desofuscar el script mediante el siguiente comando:

perl decode-stunnix-5.17.1.pl < obfuscated_run.pl > deobfuscated_run.pl

Luego de lo cual podremos visualizar el contenido desofuscado:

Éstas son sólo las primeras líneas del guión, con fines ilustrativos. Esta técnica de desofuscación también se puede emplear para otros scripts Perl ofuscados empleados por OUTLAW. Analizaremos estos scripts más de cerca en un momento.

El script finaliza con la instalación de su propia clave pública SSH para acceso persistente, estableciendo licencias restrictivas y haciendo que el directorio sea inmutable para evitar modificaciones a través de chattr:

Scripts de STEALTH SHELLBOT

Los scripts STEALTH SHELLBOT empleados en OUTLAW no son scripts personalizados sino que están disponibles públicamente y a menudo provienen de antiguos repositorios de GitHub y foros clandestinos. Estos scripts existen desde hace más de una década, originalmente diseñados para la administración remota, la automatización y la gestión de botnets. Sin embargo, desde entonces los autores de malware los reutilizaron para realizar actividades maliciosas.

Los scripts de SHELLBOT funcionan como puertas traseras basadas en IRC, lo que permite a los atacantes controlar de forma remota máquinas infectadas a través de comandos predefinidos enviados a través de un canal IRC. Una vez conectados al servidor IRC del atacante, estos bots pueden:

Ejecutar comandos de shell arbitrarios
Descargar y ejecutar cargas útiles adicionales
Lanzar ataques DDoS (en variantes anteriores)
Robar credenciales o exfiltrar información del sistema
Gestionar mineros de criptomonedas u otros componentes de malware

OUTLAW integra estos scripts SHELLBOT heredados como un mecanismo de persistencia secundario, lo que garantiza que incluso si sus módulos de fuerza bruta se interrumpen, los atacantes aún mantienen un punto de apoyo remoto. El bot se conecta a un C2 IRC controlado por el atacante, donde escucha más comandos, lo que permite la ejecución a pedido de acciones maliciosas.

Si bien estos scripts no son nuevos, su uso continuo resalta cómo los atacantes confían en herramientas disponibles públicamente en lugar de desarrollar nuevo malware desde cero.

Ejecución de subrutina del directorio c/: Cliente Bruteforcer

Como parte de la tercera y última subrutina, se implementa una herramienta de fuerza bruta personalizada. Esta cadena comienza, de forma similar a las subrutinas anteriores, desde los scripts init y init2 . Ambos scripts llaman al script start , que contiene el siguiente contenido:

Este script almacena el directorio de trabajo actual, proporciona todas las licencias (777) a todos los archivos en el directorio actual y crea un script llamado aptitude (que también es llamado por el trabajo cron previamente configurado) para ejecutar el script run . Luego de crear aptitude, se le conceden licencias de ejecución y se ejecuta.

El script run se emplea para recopilar información de la arquitectura de la CPU y contar los núcleos de la CPU para determinar el comportamiento de ejecución, como se muestra a continuación:

Si el sistema es x86_64, verifica si la CPU tiene menos de 7 núcleos, introduciendo un retraso aleatorio antes de ejecutar ./go en segundo plano. Si se detectan 7 o más núcleos, se omite o modifica la ejecución (con un binario usado previamente golan ahora comentado). Es posible que el actor de la amenaza estuvo probando o trabajando con un binario de Golang que puede aprovechar al máximo la cantidad de núcleos presentes en un sistema, pero eso es solo una suposición.

En la mayoría de los escenarios, el flujo de ejecución se mueve al script bash llamado go:

El script determina la arquitectura de la CPU y asigna un número de subprocesos en consecuencia:

Sistemas basados en ARM → 75 subprocesos
i686 (32 bits x86) → 325 subprocesos
Todos los demás (predeterminado) → 475 hilos

Luego entra en un bucle infinito, ejecutando las siguientes acciones:

Crea y limpia archivos temporales (v, p, ip, xtr*, a.*, b.*).
Escribe valores codificados (257.287.563.234 y sdaferthqhr34312asdfa) en los archivos c y d.
Espera un retraso aleatorio (1-30 segundos) antes de iniciar blitz.
Ejecuta blitz durante 3 horas con los parámetros especificados (-t $threads sugiere procesamiento multiproceso).
Realiza una limpieza posterior a la ejecución, eliminando archivos temporales y de registro antes de repetir el ciclo.

BOMBARDEO AÉREO

OUTLAW es un gusano que se autopropaga y se propaga lateralmente a través de ataques de fuerza bruta SSH empleando BLITZ, su generador de fuerza bruta personalizado. Diseñado para ataques de credenciales automatizados y agresivos, BLITZ escanea sistemáticamente y compromete los sistemas con credenciales SSH débiles o predeterminadas, lo que permite que el malware expanda su presencia con una intervención mínima del atacante.

Proceso de ejecución BLITZ

Tras su ejecución, BLITZ sigue una secuencia de ataque estructurada:

Recuperación de credenciales y destino de IP
- BLITZ se comunica con un servidor C2 SSH para obtener una lista de IP de destino y pares de credenciales.
Autenticación de fuerza bruta y creación de perfiles del sistema
- Mediante el uso de fuerza bruta SSH multiproceso, BLITZ intenta autenticar con credenciales robadas.
- Una vez obtenido el acceso, se realiza lo siguiente:
  - Cambia la contraseña del usuario para acceso persistente.
  - Ejecuta comandos de reconocimiento del sistema y recopila:
    - Privilegios de usuario
    - Detalles de la CPU
    - Información del banner SSH
    - Versión del sistema operativo
  - Exfiltra los datos recopilados al servidor C2.
Escaneo de subredes y movimiento lateral
- El malware escanea la subred local de los sistemas recientemente comprometidos e identifica máquinas adicionales con acceso SSH para atacar.
Autorreplicación e implementación de malware
- En lugar de descargarlo desde un C2 externo, BLITZ transfiere directamente el paquete de malware dota3.tar.gz desde el host infectante a la nueva víctima, lo que refuerza la persistencia y minimiza la dependencia de la infraestructura externa.

Al combinar ataques automatizados de fuerza bruta, creación de perfiles del sistema, escaneo de subredes y transferencia directa de malware, BLITZ maximiza la eficiencia de la infección y al mismo tiempo garantiza la expansión continua de la red.

Análisis binario y comunicación C2

Más allá de las operaciones de fuerza bruta, el análisis revela que BLITZ ejecuta sus tareas interactuando con comandos de shell del sistema y una biblioteca SSH incorporada. Una vez conectado a un sistema comprometido, consulta al servidor C2 en busca de objetivos actualizados y transmite datos de autenticación.

Además, OUTLAW incorpora una clave SSH codificada para la autenticación C2, que debe desbloquear empleando la contraseña "pegasus". Tras una autenticación exitosa, Blitz registra los detalles del ataque en un archivo "v", estructurado de la siguiente manera:

Este registro contiene:

Nombre de usuario y contraseña originales empleados en el ataque.
La dirección IP de la víctima y la nueva contraseña establecido por el malware.
Detalles del puerto SSH y del sistema operativo, incluidas las especificaciones de la CPU.

Una vez que BLITZ completa su ciclo de escaneo, el archivo "v" se filtra a un servidor C2 SSH, proporcionando a los atacantes una lista continuamente actualizada de sistemas infectados.

Post-compromiso

Para analizar el comportamiento del atacante posterior al compromiso, configuramos deliberadamente un honeypot y cargamos proactivamente sus credenciales en el mismo servidor SSH C2 empleado por el atacante. Esto efectivamente invitó al atacante a nuestro entorno controlado, lo que nos permitió monitorear de cerca sus acciones posteriores.

Unos días después de que BLITZ lograra forzar con éxito el acceso y establecer una nueva contraseña en el sistema honeypot, observamos un inicio de sesión remoto que empleaba estas credenciales. El inicio de sesión se originó desde 212.234.225[.]29. El atacante realizó inmediatamente un reconocimiento básico ejecutando el comando w para verificar quién inició sesión y luego ejecutando ps para ver qué procesos se estaban ejecutando. Mientras escribían los comandos, cometieron un pequeño error tipográfico y eliminaron el mensaje con un rápido Ctrl+C, lo que indica una interacción manual en lugar de un script automatizado en esta etapa. A continuación, el atacante pegó un serial de comandos para descargar una copia nueva de dota3.tar.gz a través de wget, la descomprimió y ejecutó el script recién obtenido.

Toda esta cadena de actividad se puede visualizar a través de la vista de sesión, una herramienta de investigación que permite examinar los datos del proceso de Linux organizados en una estructura de tipo árbol según el modelo de eventos lógicos de Linux, con procesos organizados por parentesco y tiempo de ejecución. Muestra eventos en un formato altamente legible inspirado en la terminal. Esto lo convierte en una herramienta poderosa para monitorear e investigar la actividad de la sesión en su infraestructura Linux y comprender el comportamiento de los usuarios y servicios.

La cadena de ataque que se muestra arriba refleja el método de infección original, lo que sugiere que el atacante estaba actualizando componentes o reinfectando el host para mantener la persistencia. Poco luego de verificar que la carga útil actualizada se estaba ejecutando, el atacante se desconectó del host, dejando atrás un entorno preparado para el ataque de fuerza bruta SSH, la minería de criptomonedas y el control remoto a través de IRC.

Este breve inicio de sesión sirve como recordatorio de que incluso las campañas poco sofisticadas pueden incluir focos de actividad interactiva por parte de los atacantes (una especie de "control de calidad" manual), lo que subraya la importancia de una detección oportuna y una contención rápida.

Detección de OUTLAW mediante MITRE ATT&CK

OUTLAW es un malware para Linux que se basa en ataques de fuerza bruta SSH, minería de criptomonedas y propagación de tipo gusano para infectar y mantener el control de los sistemas. Si bien no es muy sofisticado, cubre una amplia gama de técnicas MITRE ATT&CK, lo que lo convierte en un caso eficaz para la ingeniería de detección.

Esta sección mapea la cadena de ataque de OUTLAW a MITRE ATT&CK, destacando las reglas de SIEM elásticas y de puntos finales y las consultas de búsqueda de amenazas que pueden identificar su actividad en diferentes etapas.

OUTLAW sigue un flujo de infección estructurado:

Acceso inicial : fuerza bruta SSH contra credenciales débiles.
Ejecución : ejecuta scripts maliciosos para iniciar varias etapas de infección de malware.
Persistencia : instala trabajos cron y modifica claves SSH.
Evasión de defensa : se esconde en directorios ocultos, modifica licencias de archivos, emplea técnicas de empaquetado, codificación de comandos y ofusca scripts.
Acceso a credenciales : modifica las credenciales e inyecta claves SSH públicas.
Descubrimiento : enumera detalles del usuario, del sistema y del hardware.
Movimiento lateral : se propaga a través de fuerza bruta SSH interna y transferencia de malware.
Recopilación y exfiltración : recopila y exfiltra datos del sistema a su C2.
Comando y control : emplea socat y STEALTH SHELLBOT para la comunicación C2.
Impacto : lanza XMRIG para minar criptomonedas y aprovecha el host infectado como un nodo de fuerza bruta.

Las siguientes secciones detallan estrategias de detección para cada técnica, ayudando a los defensores a identificar y mitigar eficazmente las infecciones de OUTLAW.

TA001: Acceso inicial

OUTLAW obtiene acceso inicial a través de ataques de fuerza bruta SSH oportunistas, apuntando a sistemas con credenciales débiles o predeterminadas. Las reglas de detección elásticas predefinidas pueden detectar con éxito este método de acceso inicial. Estos incluyen:

Además, existen varias reglas basadas en registros de autenticación para detectar autenticaciones SSH sospechosas:

Además de confiar en las detecciones, es importante incorporar la búsqueda de amenazas en su flujo de trabajo. Elastic Security proporciona varias consultas de búsqueda empleando ES|QL y OSQuery, disponibles públicamente en nuestro repositorio de reglas de detección, específicamente en el subdirectorio de búsqueda de Linux. Por ejemplo, las dos siguientes cacerías pueden ayudar a identificar diferentes etapas del ataque:

TA002: Ejecución

Luego de obtener acceso inicial, OUTLAW ejecuta un serial de scripts y binarios para establecer el control. Al descargar y descomprimir, detectamos:

El script STEALTH SHELLBOT se detecta a través de:

Script ejecutado a través de un proceso primario inusual

Además, el malware ejecuta múltiples comandos de sistema sospechosos, lo que provoca:

Suspicious System Commands Executed by Previously Unknown Executable

TA003: Persistencia

Esta combinación de ejecución basada en cron y manipulación de claves SSH permite a OUTLAW mantener un punto de apoyo persistente en los sistemas comprometidos. Ambas técnicas de persistencia se investigan en profundidad en nuestra publicación "Ingeniería de detección de Linux: una introducción a los mecanismos de persistencia". Podemos detectar estas técnicas a través de las siguientes reglas SIEM y de puntos finales:

Además, podemos buscar estas técnicas a través de las siguientes búsquedas de ES|QL y OSQuery:

TA005: Evasión de defensa

OUTLAW emplea múltiples técnicas de evasión de defensa para evitar ser detectado. Uno de sus métodos principales es la decodificación Base64, que se detecta a través de las siguientes reglas predefinidas:

Además, los binarios del malware están empaquetados con UPX, lo que reduce su tamaño y altera su firma para evadir la detección de malware tradicional. Una vez que el malware se descomprime en la memoria, esto se detecta a través de nuestras detecciones de malware generales.

Continuando con la cadena de ejecución, el malware crea varios archivos y directorios ocultos y los modifica empleando chattr:

Podemos mejorar aún más la detección mediante la siguiente consulta de búsqueda:

Ejecución de procesos ocultos

TA006: Acceso a credenciales

OUTLAW mantiene acceso persistente a un sistema comprometido mediante la manipulación de credenciales. Luego de una autenticación de fuerza bruta SSH exitosa, el malware reemplaza el archivo SSH authorised_keys existente con una nueva versión que contiene una clave pública SSH maliciosa, otorgando así acceso persistente. Esto se detecta a través de las siguientes señales:

Luego, el malware cambia las credenciales del usuario de la cuenta autenticada ingresando una nueva contraseña usando la utilidad passwd :

Modificación de credenciales de cuenta de usuario de Linux

TA007: Descubrimiento

OUTLAW recopila información del sistema tras una infección exitosa para crear un perfil del entorno comprometido. El malware ejecuta varios comandos para recopilar detalles sobre la CPU del sistema, los privilegios del usuario, el sistema operativo, el uso de la memoria y los binarios disponibles. Este paso de reconocimiento ayuda al atacante a evaluar las capacidades del sistema y determinar cuál es la mejor manera de emplear la máquina comprometida. Todos ellos se detectan a través de varias reglas de bloques de construcción, tal como se enumeran en nuestro directorio rules_building_block. A continuación se muestra una breve lista de los más importantes desencadenados por OUTLAW:

La configuración de la interfaz predeterminada no incluye reglas de bloques de construcción debido a sus niveles de ruido relativamente altos. Sin embargo, estas reglas pueden habilitar para ayudar en la identificación de amenazas potenciales.

TA008: Movimiento lateral

El malware OUTLAW se propaga a través de una red comprometida realizando ataques internos de fuerza bruta SSH. Podemos identificar este comportamiento a través de las siguientes reglas ES|QL:

Una vez que se logra forzar con éxito un sistema, el paquete de malware, dota3.tar.gz, se distribuye desde el host infectado al nuevo objetivo. Luego se escanea la subred local en busca de objetivos adicionales para garantizar la propagación continua del malware.

Las reglas de detección elásticas predefinidas pueden identificar estos intentos de movimiento lateral:

Además, al copiar el malware OUTLAW a un host remoto, se activan las alertas de prevención de malware.

TA009: Colección y TA010: Exfiltración

OUTLAW recopila información básica del sistema, credenciales y detalles SSH de las máquinas comprometidas, principalmente para rastrear hosts infectados y facilitar futuros ataques. Estos datos se almacenan en un archivo de texto simple antes de cargar a un servidor C2. Dado que esta actividad de recopilación se limita a reunir detalles del sistema y escribirlos en un archivo, no es inherentemente sospechosa en sí misma.

La exfiltración ocurre cuando OUTLAW inicia una conexión SSH saliente a través del servidor sftp para transferir la información recopilada a un servidor C2 predefinido. Si bien esto puede parecer a una actividad SSH normal, podemos detectar la ejecución sospechosa de utilidades de transferencia de archivos a través de ES|QL:

Se lanzó una utilidad de transferencia de archivos inusual

TA011: Comando y Control

OUTLAW mantiene la comunicación con su infraestructura C2 a través de múltiples canales, lo que permite a los atacantes emitir comandos, exfiltrar datos y gestionar sistemas infectados. Podemos detectar varias de las utilidades empleadas por el malware a través de las siguientes reglas:

Las mismas consultas de búsqueda que fueron relevantes para detectar los intentos de acceso iniciales del malware también se pueden emplear para buscar esta actividad C2. Además, se pueden emplear las siguientes consultas de búsqueda:

TA040: Impact

OUTLAW afecta a los sistemas infectados consumiendo recursos de la CPU para la minería de criptomonedas y realizando ataques de fuerza bruta SSH para propagar. Se intentan varias optimizaciones de CPU y memoria antes de lanzar el software de minería XMRIG modificado, incluida la habilitación del acceso de escritura MSR y la configuración de parámetros del kernel como hugepages. Estas modificaciones se pueden detectar a través de las siguientes reglas:

Como OUTLAW intenta habilitar el acceso de escritura MSR a través de modprobe pero no tiene las licencias necesarias, se activan las reglas relacionadas con el controlador del kernel:

Estas reglas monitorean directamente las llamadas al sistema init_module() y finit_module() , a través de Auditd. Para obtener más información sobre cómo configurar la integración de Auditd Manager para capturar eventos del controlador y mucho más, consulte la publicación Ingeniería de detección de Linux con Auditd .

Simultáneamente, se lanzan intentos de fuerza bruta de SSH desde el host infectado, lo que desencadena:

Posible intento de fuerza bruta de SSH impulsado por malware

Durante su ejecución, OUTLAW ejecuta scripts de eliminación para terminar con malware competidor o procesos sobrantes de infecciones anteriores. Este comportamiento desencadena:

Indicadores de compromiso (IOC)

El conjunto completo de indicadores se puede encontrar como un paquete en Github.

Firmas de Yara

rule Linux_Hacktool_Outlaw_cf069e73 {
    meta:
        author = "Elastic Security"
        description = "OUTLAW SSH bruteforce component fom the Dota3 package"
        reference_sample = "c3efbd6b5e512e36123f7b24da9d83f11fffaf3023d5677d37731ebaa959dd27"
      
    strings:
        $ssh_key_1 = "MIIJrTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQI8vKBZRGKsHoCAggA"
        $ssh_key_2 = "MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAECBBBC3juWsJ7DsDd2wH2XI+vUBIIJ"
        $ssh_key_3 = "UCQ2viiVV8pk3QSUOiwionAoe4j4cBP3Ly4TQmpbLge9zRfYEUVe4LmlytlidI7H"
        $ssh_key_4 = "O+bWbjqkvRXT9g/SELQofRrjw/W2ZqXuWUjhuI9Ruq0qYKxCgG2DR3AcqlmOv54g"
        $path_1 = "/home/eax/up"
        $path_2 = "/var/tmp/dota"
        $path_3 = "/dev/shm/ip"
        $path_4 = "/dev/shm/p"
        $path_5 = "/var/tmp/.systemcache"
        $cmd_1 = "cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'"
        $cmd_2 = "cd ~; chattr -ia .ssh; lockr -ia .ssh"
        $cmd_3 = "sort -R b | awk '{ if ( NF == 2 ) print } '> p || cat b | awk '{ if ( NF == 2 ) print } '> p; sort -R a"
        $cmd_4 = "rm -rf /var/tmp/dota*"
        $cmd_5 = "rm -rf a b c d p ip ab.tar.gz"
    condition:
        (all of ($ssh_key*)) or (3 of ($path*) and 3 of ($cmd*))
}

Descripción general de las reglas de SIEM y endpoints por MITRE ATT&CK Tactic

Identificación de la técnica	Descripción
TA001: Acceso inicial	Potential External Linux SSH Brute Force Detected Potential Successful SSH Brute Force Attack Autenticación SSH exitosa a partir de una clave pública SSH inusual Autenticación SSH exitosa de un usuario inusual Autenticación SSH exitosa desde una dirección IP inusual
TA002: Ejecución	File Downloaded from Suspicious Source by Web Server Linux.Trojan.Pornoasset Script ejecutado a través de un proceso primario inusual Suspicious System Commands Executed by Previously Unknown Executable
TA003: Persistencia	Cron Job Created or Modified Modificación de archivos de claves autorizadas por SSH Persistencia potencial mediante modificación de archivos
TA005: Evasión de defensa	Carga útil decodificada en Base64 enviada al intérprete Actividad inusual de codificación y decodificación Base64
TA006: Acceso a credenciales	Modificación de archivos de claves autorizadas por SSH Eliminación de archivos de claves autorizadas de SSH Modificación de credenciales de cuenta de usuario de Linux
TA007: Descubrimiento	Descubrimiento de información del sistema Linux
TA008: Movimiento lateral	Posible actividad de escaneo de puertos desde un host comprometido
TA009 y TA010: Recolección y Exfiltración	Se lanzó una utilidad de transferencia de archivos inusual
TA011: Comando y Control	Actividad de escucha o shell inverso de Socat
TA040: Impact	Actividad sospechosa de las características del kernel

Conclusión

OUTLAW ejemplifica cómo incluso el malware poco sofisticado puede persistir y escalar de manera efectiva en entornos modernos. A pesar de carecer de técnicas de evasión avanzadas, su combinación de ataques de fuerza bruta SSH, autorreplicación y componentes modulares le permite mantener una botnet de larga duración. OUTLAW garantiza una expansión continua con una intervención mínima del atacante aprovechando los hosts comprometidos para propagar aún más las infecciones.

Nuestro experimento honeypot proporcionó una visión poco común del comportamiento del atacante en el mundo real y confirmó que, si bien gran parte del funcionamiento de OUTLAW está automatizado, hay momentos de interacción humana directa. La capacidad de observar comandos manuales, intentos de reconocimiento e incluso errores tipográficos simples resalta un aspecto del mantenimiento de botnets que a menudo se pasa por alto: el control de calidad impulsado por el operador. Estos conocimientos refuerzan la necesidad de contar con estrategias de detección que tengan en cuenta no sólo los ataques automatizados sino también la actividad manual posterior al compromiso.

Al comprender cómo OUTLAW opera, propaga y monetiza las infecciones, los defensores pueden desarrollar estrategias de detección estables para mitigar su impacto. Este reporte proporciona reglas SIEM prácticas, consultas de búsqueda de amenazas y conocimientos forenses, lo que permite a los equipos de seguridad mantener a la vanguardia de amenazas similares en evolución.

Referencias

[1] CounterCraft, malware de DOTA3 una y otra vez

[2] Juniper Networks, DOTA3: ¿Su dispositivo de Internet de las cosas está haciendo un trabajo extraoficial?

[3] SANS ISC, Higiene Higiene Higiene

[4] Darktrace, Outlaw Returns: Descubriendo características que regresan y nuevas tácticas