Los investigadores de Trend Micro han descrito un implante para Linux previamente no documentado con el nombre en clave Quasar Linux RAT (QLNX) que, según indican, tiene como objetivo sistemas de desarrolladores e ingenieros de DevOps con el fin de robar credenciales que permiten acceder a registros de paquetes, infraestructura en la nube y pipelines de CI/CD. Según se informa, el malware se ejecuta de forma fileless desde la memoria, utiliza una arquitectura de rootkit de dos niveles y admite 58 comandos distintos que proporcionan al operador control total sobre el host comprometido. La amenaza afecta a sistemas Linux utilizados en procesos de desarrollo y operación de software.
Recolección dirigida de secretos de desarrolladores
La característica clave de QLNX que lo distingue de otros troyanos de acceso remoto para Linux es un módulo especializado de recopilación de credenciales orientado específicamente al ecosistema de desarrollo. Según los investigadores Aliakbar Zahravi y Ahmed Mohamed Ibrahim, el módulo extrae secretos de los siguientes archivos y configuraciones:
- .npmrc: tokens de NPM
- .pypirc: credenciales de PyPI
- .git-credentials: datos de acceso a repositorios Git
- .aws/credentials: claves de acceso de AWS
- .kube/config: configuración de Kubernetes
- .docker/config.json: credenciales de Docker
- .vault-token: tokens de HashiCorp Vault
- Credenciales de Terraform, tokens de GitHub CLI y archivos .env
La posible compromisión de estos activos, según la estimación de Trend Micro, permite a un atacante publicar paquetes maliciosos en los registros de NPM o PyPI, obtener acceso a la infraestructura en la nube o desplazarse dentro de los pipelines de CI/CD. Esto crea un riesgo de ataques en cascada contra la cadena de suministro de software: un único mantenedor de paquetes comprometido puede convertirse en el punto de entrada para una distribución masiva de código malicioso.
Mecanismos de sigilo y persistencia
Según se informa, QLNX muestra un conjunto avanzado de técnicas de evasión de detección. El implante se ejecuta de forma fileless desde la memoria RAM y se hace pasar por hilos legítimos del kernel —por ejemplo, kworker o ksoftirqd—, lo que dificulta su detección mediante herramientas estándar de monitorización de procesos.
Para mantener la persistencia en el sistema, presuntamente se emplean al menos siete métodos distintos, entre ellos:
- Unidades de systemd
- Tareas de crontab
- Inyecciones en .bashrc
El implante también perfila el host para detectar entornos en contenedores y borra los registros del sistema para ocultar los rastros de su actividad.
Arquitectura de rootkit en dos niveles
Merece especial atención la arquitectura de ocultación en dos niveles. En el espacio de usuario, QLNX, según los investigadores, utiliza el mecanismo LD_PRELOAD del enlazador dinámico de Linux para interceptar llamadas al sistema y ocultar los artefactos y procesos del implante. En el nivel del kernel se emplea un componente basado en eBPF que, por orden del servidor de mando y control, oculta procesos, archivos y puertos de red de las utilidades estándar —ps, ls, netstat.
La combinación de rootkits en espacio de usuario y en el kernel complica significativamente la detección: incluso si se neutraliza uno de los niveles de ocultación, el otro sigue enmascarando la presencia del implante.
Intercepción de autenticación mediante PAM
Según se indica, QLNX incluye una puerta trasera basada en Pluggable Authentication Module (PAM) que intercepta credenciales en texto claro durante los eventos de autenticación, registra los datos de las sesiones SSH salientes y envía la información recopilada al servidor de mando y control. Además, se describe un segundo módulo de recopilación de credenciales basado en PAM que se carga automáticamente en cada proceso enlazado dinámicamente para extraer el nombre del servicio, el nombre de usuario y el token de autenticación.
Infraestructura de mando y control y capacidades
Tras establecer la persistencia, el implante pasa a la fase operativa principal, intentando de forma continua establecer y mantener la comunicación con el servidor C2 mediante los protocolos raw TCP, HTTPS y HTTP. El conjunto de 58 comandos soportados, según los investigadores, incluye:
- Ejecución de comandos arbitrarios de shell
- Gestión de archivos e inyección de código en procesos
- Captura de pantallas e interceptación de pulsaciones de teclado
- Configuración de proxies SOCKS y túneles TCP
- Ejecución de Beacon Object Files (BOF)
- Gestión de una red mesh peer-to-peer (P2P)
En el momento de la publicación de la investigación, el mecanismo exacto de entrega inicial de QLNX sigue siendo desconocido.
Evaluación del impacto
Están especialmente expuestas aquellas organizaciones en las que los desarrolladores trabajan en sistemas Linux y almacenan en ellos secretos de acceso a la infraestructura, como tokens de registros de paquetes, claves de proveedores cloud y configuraciones de orquestación de contenedores. La compromisión de una única estación de trabajo de un desarrollador puede desembocar en la publicación de paquetes envenenados, acceso no autorizado a la infraestructura cloud de producción y movimiento lateral a través de los pipelines de CI/CD.
Importante aclaración: en el momento de la publicación no se han proporcionado indicadores de compromiso (hashes, direcciones IP, dominios), casos confirmados de ataques reales ni de envenenamiento de paquetes. La evaluación del alcance de la amenaza se basa en el análisis de las capacidades del implante y no en incidentes documentados.
Recomendaciones de protección
- Auditoría del almacenamiento de secretos: asegúrese de que los tokens de NPM, PyPI, AWS, Docker, Kubernetes y otros secretos no se almacenen en texto claro en los directorios personales. Utilice gestores de secretos y tokens de corta duración.
- Monitorización de LD_PRELOAD: revise la variable de entorno LD_PRELOAD y el archivo /etc/ld.so.preload para detectar entradas inesperadas.
- Control de programas eBPF: utilice bpftool para inventariar los programas BPF cargados e identificar módulos anómalos.
- Verificación de la configuración de PAM: revise periódicamente los archivos en /etc/pam.d/ y los módulos PAM cargados en busca de cambios no autorizados.
- Supervisión de la ocultación de procesos: preste atención a procesos con nombres kworker o ksoftirqd que no se correspondan con los hilos esperados del kernel.
- Revisión de los mecanismos de persistencia: lleve a cabo una auditoría de las unidades de systemd, las tareas de crontab y los archivos .bashrc en busca de entradas sospechosas.
- Rotación de secretos: ante cualquier sospecha de compromiso, rote de inmediato todos los tokens y claves de acceso almacenados en el sistema afectado.
El implante QLNX descrito demuestra una tendencia hacia la creación de malware especializado específicamente en la infraestructura de desarrollo. La acción prioritaria para los equipos de seguridad es inventariar los secretos que se almacenan en texto claro en las estaciones de trabajo de los desarrolladores y migrarlos a almacenes centralizados de secretos que admitan tokens de corta duración y auditoría de accesos.
