Se ha descubierto un nuevo malware para Linux llamado Quasar Linux (QLNX), el cual está dirigido específicamente a ingenieros de DevOps y desarrolladores de software. Este malware destaca por su sofisticación, ya que se ejecuta casi totalmente en memoria, lo que dificulta enormemente su detección por parte de las herramientas de seguridad tradicionales al evitar el almacenamiento de archivos en el disco.

Un malware de Linux recién descubierto conocido como Quasar Linux, o QLNX, está atacando activamente a desarrolladores de software e ingenieros de DevOps con un nivel de sofisticación rara vez visto en amenazas centradas en Linux.

A diferencia de la mayoría del malware que depende de archivos almacenados en el disco, QLNX se ejecuta casi por completo en la memoria, lo que hace que sea muy difícil de detectar para las herramientas de seguridad tradicionales. La amenaza ha generado serias preocupaciones debido a quiénes ataca y qué es lo que finalmente busca robar.

QLNX llega como un único binario autónomo, pero ahí es donde termina el comportamiento ordinario. Una vez ejecutado, desplaza su carga útil a la memoria y no deja rastro en el sistema de archivos; luego, se implanta en el sistema operativo para recolectar claves SSH, credenciales de la nube, tokens de registros de paquetes y contraseñas almacenadas en el navegador.

Una estación de trabajo de desarrollador comprometida no es solo una máquina infectada; es una puerta trasera hacia repositorios de código fuente, tuberías de compilación (build pipelines) y entornos de nube. Los analistas de GuardSix identificaron el malware y señalaron que fue descubierto originalmente por investigadores de TrendMicro.

GuardSix dijo en un informe que QLNX está construido alrededor de un marco de acceso remoto de 58 comandos diseñado para evadir las defensas convencionales de los endpoints de Linux.

El malware ataca sistemas que ejecutan Debian, Ubuntu, RHEL, Fedora y Arch, centrándose principalmente en los hosts de desarrollo y de compilación CI/CD.

Lo que diferencia a QLNX es su capacidad para adaptarse a casi cualquier sistema Linux que infecte. En lugar de llevar componentes preconstruidos, incrusta código fuente de C puro y utiliza el propio compilador de la máquina objetivo para construir un rootkit personalizado en tiempo de ejecución.

Dado que los archivos resultantes son únicos para cada host, la detección de firmas estáticas falla y el malware se mezcla con la actividad que parece normal.

El daño se extiende mucho más allá de un solo endpoint. Una infección exitosa posiciona a un atacante dentro de la cadena de suministro de desarrollo, con acceso a todo lo necesario para manipular el código, publicar paquetes maliciosos o pivotar hacia la infraestructura de la nube.

Los defensores que pasen por alto el compromiso inicial pueden enfrentar consecuencias que lleguen mucho más allá de la máquina infectada inicialmente.

Quasar Linux RAT ataca a desarrolladores

La cadena de infección de QLNX se desarrolla en seis etapas cuidadosamente secuenciadas y diseñadas para evitar dejar evidencia. Al iniciarse, crea un archivo que existe solo en la memoria, escribe su carga útil real en él, ejecuta esa carga y luego elimina el archivo original del disco.

El proceso en ejecución no tiene ningún archivo asociado en el sistema de archivos, por lo que las herramientas antivirus basadas en disco no encuentran nada que escanear. Para evitar llamar la atención, QLNX reescribe el nombre de su propio proceso para imitar hilos de trabajo legítimos del kernel como [kworker/0:0] o [migration/0].

Los hilos genuinos del kernel nunca deberían mantener conexiones de red en el espacio de usuario ni tener un proceso padre regular en el espacio de usuario. La mayoría de los controles rutinarios del sistema pasarían por alto este engaño por completo.

Luego, el malware compila su rootkit incrustado y la fuente del backdoor PAM contra las cabeceras del kernel local utilizando el propio gcc de la víctima, produciendo un archivo de objeto compartido único por host que evade la detección basada en firmas.

El rootkit compilado se carga en todo el sistema modificando un archivo que obliga a cada proceso recién creado a cargar la librería maliciosa. Una malla peer-to-peer conecta los hosts infectados, por lo que eliminar un nodo de comando no desconecta al atacante.

Pasos de remediación y mitigación para QLNX

GuardSix deja claro que una limpieza estándar no es suficiente. Un borrado completo y la reinstalación del sistema operativo desde una imagen verificada y limpia es la única solución totalmente fiable, ya que una limpieza parcial deja un riesgo residual porque el rootkit eBPF puede sobrevivir a menos que se elimine completamente a nivel de kernel.

Para los equipos que no pueden reinstalar la imagen inmediatamente, GuardSix recomienda aislar todos los hosts sospechosos de la red a la vez, ya que eliminarlos uno por uno permite que los nodos de malla supervivientes vuelvan a infectar a los pares ya limpiados.

Eliminar los archivos de persistencia conocidos, limpiar la configuración de la librería de precarga (preload) y recopilar los registros de credenciales cifradas para la revisión forense son pasos esenciales.

En cuanto a la prevención, restringir el compilador de C en sistemas que no lo requieran bloquea a QLNX de construir su rootkit. Segmentar las estaciones de trabajo de los desarrolladores entre sí rompe la malla peer-to-peer.

Las organizaciones deben monitorear estrechamente los archivos de configuración del sistema de bajo nivel y rotar todas las credenciales de toda la empresa tras cualquier detección confirmada.

Indicadores de Compromiso (IoCs):-

Nota: Las direcciones IP y los dominios han sido desinfectados intencionalmente (por ejemplo, [.]) para evitar la resolución accidental o la creación de hipervínculos. Reactívalos solo dentro de plataformas de inteligencia de amenazas controladas como MISP, VirusTotal o tu SIEM.