Quasar Linux (QLNX): Un Punto de Apoyo en la Cadena de Suministro con Capacidades Completas de RAT

Resumen

Quasar Linux (QLNX) es un troyano avanzado de acceso remoto para Linux que combina un rootkit de espacio de usuario y eBPF con una puerta trasera PAM y amplias capacidades de recolección de credenciales. El malware admite ejecución sin archivos, suplantación de nombres de procesos y varias técnicas de persistencia que lo ayudan a permanecer oculto en los sistemas infectados. Su enfoque en estaciones de trabajo de desarrolladores lo hace especialmente peligroso para el abuso de la cadena de suministro, ya que puede robar tokens, claves SSH y credenciales en la nube. El malware también utiliza comunicaciones cifradas y admite una arquitectura de malla peer-to-peer para mejorar la resiliencia y mantener el acceso.

Investigación

Los investigadores de Trend Micro obtuvieron el binario de QLNX y realizaron tanto análisis estático como dinámico, descubriendo el código fuente incrustado para los componentes de rootkit y puerta trasera PAM. Su investigación documentó la capacidad del malware para compilar componentes directamente en el host objetivo, la variedad de mecanismos de persistencia que utiliza y el conjunto completo de comandos que admite el implante. El análisis de red también reveló un protocolo personalizado basado en TLS y un identificador mágico distintivo utilizado en las comunicaciones. A partir de este trabajo, los investigadores extrajeron indicadores de compromiso para apoyar la caza y detección.

Mitigación

Los defensores deben buscar QLNX monitoreando su archivo de bloqueo mutex único, sospechosas entradas LD_PRELOAD y comandos de compilación inusuales que generen objetos compartidos maliciosos. Las organizaciones también deben bloquear la ejecución de binarios desconocidos llamados gcc compilation commands that generate malicious shared objects. Organizations should also block execution of unknown binaries named quasar-implant y restringir el acceso de escritura a /etc/ld.so.preload. La autenticación multifactor debería ser impuesta para las cuentas de desarrolladores, y los equipos de seguridad deberían monitorear de cerca los intentos de exfiltrar almacenes de credenciales y archivos de tokens sensibles.

Respuesta

Si se encuentran indicadores de QLNX, aísle inmediatamente el sistema afectado, recoja imágenes de memoria y disco, y termine el proceso malicioso. Elimine entradas no autorizadas de /etc/ld.so.preload, elimine los .so archivos maliciosos compilados y borre el archivo de bloqueo utilizado por el implante. Todas las credenciales potencialmente expuestas, especialmente los tokens de la nube y del registro de paquetes, deben ser rotadas sin demora. Los investigadores también deben evaluar si algún sistema de la cadena de suministro, repositorio o entorno de construcción fue contaminado durante la intrusión.

## Ejecución de Simulación

Prerrequisito: El Comprobación Previa de Telemetría y Línea Base debe haber tenido éxito.

Razonamiento: Esta sección detalla la ejecución precisa de la técnica del adversario (TTP) diseñada para activar la regla de detección. Los comandos y la narrativa DEBEN reflejar directamente los TTPs identificados y apuntar a generar la telemetría exacta esperada por la lógica de detección.

• Narrativa y Comandos del Ataque:

  1. Etapa 1 – Generación de Carga Útil: El atacante escribe una carga útil mínima en C que llama a memfd_create para crear un archivo ejecutable anónimo en memoria, escribe un shellcode simple (p.ej., execve("/bin/sh", …)), lo marca como ejecutable y luego lo lanza a través de execveat.
  2. Etapa 2 – Compilación Sobre la Marcha: Usando gcc (el indicador visible en la regla) el atacante compila el código fuente sin tocar el disco (salida dirigida a /dev/fd/3).
  3. Etapa 3 – Ejecución e Inyección: El binario compilado se ejecuta, invoca memfd_create, carga el shellcode y finalmente llama a execveat para ejecutar el ELF residente en memoria. Opcional ptrace puede ser utilizado para inyectar código en un proceso hermano, lo cual también cumpliría con la regla.

• Script de Prueba de Regresión:

  #!/usr/bin/env bash
  #
  # Simulación de ejecución sin archivos similar a QLNX
  # Genera ELF en memoria mediante memfd_create y lo ejecuta con execveat.
  # Requiere: gcc, libcap2-bin (para demo execveat) y reglas auditd del despegue previo.
  
  set -euo pipefail
  
  # 1️⃣ Crea el código fuente en C que realiza el baile de memfd + execveat
  cat > /tmp/payload.c <<'EOF'
  #define _GNU_SOURCE
  #include <sys/mman.h>
  #include <sys/syscall.h>
  #include <unistd.h>
  #include <fcntl.h>
  #include <string.h>
  
  int main(void) {
      // Crea un descriptor de archivo anónimo (memfd)
      int fd = syscall(SYS_memfd_create, "memfd_payload", MFD_CLOEXEC);
      if (fd == -1) _exit(1);
  
      // Binario ELF simple que solo execve /bin/sh
      const unsigned char elf[] = {
          0x7f,0x45,0x4c,0x46,0x02,0x01,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
          // ... (truncado por brevedad – un ELF mínimo estáticamente vinculado a /bin/sh)
      };
      write(fd, elf, sizeof(elf));
      // Hazlo ejecutable
      fchmod(fd, 0755);
  
      // Usa execveat para ejecutar el binario en memoria
      syscall(SYS_execveat, fd, "", NULL, NULL, AT_EMPTY_PATH);
      _exit(0);
  }
  EOF
  
  # 2️⃣ Compilar con gcc (esto será capturado por la regla de detección)
  gcc -static -o /tmp/payload /tmp/payload.c
  
  # 3️⃣ Ejecutar el binario malicioso – esto activa execveat
  /tmp/payload
  
  # 4️⃣ Limpieza
  rm -f /tmp/payload /tmp/payload.c

• Comandos de Limpieza:

  # Eliminar archivos residuales y descargar posibles reglas de auditoría (si el entorno de prueba es desechable)
  rm -f /tmp/payload /tmp/payload.c
  sudo auditctl -d -a always,exit -F arch=b64 -S execveat -k qlnx_execveat
  sudo auditctl -d -a always,exit -F arch=b64 -S memfd_create -k qlnx_memfd
  sudo auditctl -d -a always,exit -F arch=b64 -S ptrace -k qlnx_ptrace