Rootkit de Linux LinkPro

Una reciente vulneración de un entorno de Amazon Web Services (AWS) reveló un rootkit GNU/Linux no documentado previamente, identificado como LinkPro. Esta puerta trasera destaca por su doble uso de módulos eBPF: uno para ocultar artefactos y otro que actúa como un activador sigiloso: un "golpe" que activa la funcionalidad de comandos remotos solo tras detectar un paquete TCP especialmente diseñado. La cadena de ataque y los mecanismos del rootkit ilustran un operador sofisticado que combina el abuso de contenedores, la ocultación a nivel de kernel y la activación flexible de la red para frustrar la detección y la correlación forense.

Vector de infección y despliegue inicial

La intrusión comenzó con la explotación de una instancia de Jenkins expuesta, vulnerable a CVE‑2024‑23897 (CVSS 9.8). Desde allí, los atacantes introdujeron una imagen maliciosa de Docker (kvlnt/vv, ya eliminada de Docker Hub) en varios clústeres de Kubernetes. La imagen utilizaba una base de Kali Linux y contenía una pequeña carpeta de aplicación diseñada para establecer persistencia, acceso remoto y una descarga de puerta trasera preconfigurada.

Dentro de la imagen maliciosa de Docker

La carpeta de la aplicación de la imagen contenía tres archivos clave con funciones distintas:

start.sh : un script de shell que inicia un servicio SSH y ejecuta los otros dos componentes.

link : un programa de código abierto (vnt) compilado y empaquetado para funcionar como cliente VPN/proxy, con conexión saliente a vnt.wherewego[.]top:29872. Esto permite al atacante acceder al host comprometido desde cualquier lugar y dirigirse a otros objetivos a través de él.

aplicación : un descargador basado en Rust (conocido como vGet) que obtiene una carga útil vShell cifrada de un depósito S3 y luego establece un enlace WebSocket a su servidor de comando y control (C2) en 56.155.98[.]37.

Cargas útiles adicionales entregadas a los nodos de Kubernetes

Además de la imagen maliciosa, los operadores también instalaron otros dos componentes en los nodos: un dropper que instala otra puerta trasera vShell y LinkPro, un rootkit desarrollado en Golang. LinkPro está diseñado para ejecutarse en dos modos: pasivo (inverso) o activo (directo), según su configuración. En el modo pasivo, espera a ser activado por un paquete de red especial; en el modo activo, inicia el contacto con el propio C2. El modo directo admite cinco protocolos de transporte (HTTP, WebSocket, UDP, TCP, DNS), mientras que el modo inverso limita las comunicaciones a HTTP.

Cómo persiste LinkPro

El comportamiento general de ejecución y persistencia del malware siguen una secuencia clara:

• Instale el módulo Ocultar eBPF. Este módulo incluye los programas eBPF de Tracepoint y Kretprobe, utilizados para ocultar los procesos y la actividad de red de LinkPro.
• Si falla la instalación del módulo Hide eBPF (o si se ha deshabilitado), instale una biblioteca compartida en /etc/libld.so y agregue esa ruta a /etc/ld.so.preload como mecanismo de ocultación alternativo.
• Para la operación inversa (pasiva), instale el módulo eBPF de Knock. Knock contiene un programa XDP y un programa TC, por lo que el canal C2 solo se activa tras recibir un paquete mágico específico.
• Establezca la persistencia creando un servicio systemd.
• Ejecutar comandos recibidos desde el C2.
• Al apagar o cuando se lo indique (SIGHUP, SIGINT, SIGTERM), desinstale los módulos eBPF y elimine/restaure la modificación de precarga /etc/libld.so para que el sistema vuelva a su estado anterior.

El paquete mágico y el mecanismo de activación por golpe

La activación pasiva de LinkPro depende de un paquete TCP preciso: cualquier paquete TCP con un tamaño de ventana igual a 54321 se considera un "paquete mágico". Cuando Knock detecta dicho paquete, almacena la IP de origen y la etiqueta con una fecha de caducidad de una hora. Los paquetes TCP subsiguientes provenientes de ese origen se monitorizan y, cuando corresponde, Knock reescribe las cabeceras para que el tráfico del operador se redirija al puerto de escucha de LinkPro (2333). Los paquetes salientes se ajustan para presentar el puerto original a la red (el puerto de origen se reescribe a 2233). El objetivo es simple pero efectivo: permitir que el atacante acceda a LinkPro a través de cualquier puerto permitido por el firewall frontend, a la vez que dificulta la correlación de los registros externos del firewall con la actividad de la red interna del host.

Cómo se oculta LinkPro

LinkPro utiliza una estrategia de ocultación de dos niveles:

Ocultación de kernel/eBPF : El módulo Hide eBPF instala programas de Tracepoint y Kretprobe que interceptan llamadas del sistema como getdents (para ocultar archivos/directorios) y sys_bpf (para ocultar sus propios programas BPF). Este enfoque requiere un kernel compilado con CONFIG_BPF_KPROBE_OVERRIDE habilitado.

LD_PRELOAD en el espacio de usuario : Si la capacidad del kernel no está disponible, LinkPro escribe una biblioteca compartida (libld.so) y coloca su ruta en /etc/ld.so.preload. Dado que /etc/ld.so.preload hace que la biblioteca especificada se cargue en todos los procesos enlazados dinámicamente (aquellos que usan /lib/ld-linux.so y glibc), la biblioteca libld.so implantada intercepta las funciones de libc de forma anticipada (antes del comportamiento de glibc) y modifica los retornos de las llamadas a libc para ocultar artefactos que, de otro modo, revelarían su presencia.

Capacidades de rootkit y conjunto de comandos

LinkPro admite acciones remotas interactivas y automatizadas. Sus funciones incluyen:

• Iniciar una pseudo-terminal /bin/bash y ejecutar sesiones de shell interactivas.
• Ejecutar comandos de shell arbitrarios.
• Enumerar archivos y directorios y realizar operaciones con archivos.
• Descargar y escribir archivos en el disco.
• Establecer un túnel proxy SOCKS5 para pivotar y vivir de la tierra.

Compatibilidad con protocolos de red y comportamiento de C2

En modo activo (directo), LinkPro es flexible: puede comunicarse mediante transportes HTTP, WebSocket, UDP, TCP o DNS. En modo pasivo (inverso), su comunicación se limita a HTTP, pero se beneficia del sigilo, ya que solo escucha después de que el paquete mágico Knock abra una ventana de comandos temporal de una hora.

Comportamiento de limpieza y desinstalación

Si el proceso recibe señales de terminación, LinkPro intenta eliminar los rastros: desinstala los módulos eBPF instalados y elimina o restaura el archivo /etc/libld, agrupándolo a su estado anterior para que el sistema parezca intacto. Esta rutina de limpieza deliberada indica que el operador se preocupa por la evasión y por minimizar las huellas forenses a largo plazo.

Contexto operativo y atribución

La campaña utilizó un exploit de Jenkins de alta gravedad, imágenes de contenedor maliciosas, múltiples variantes de puerta trasera y sigilo a nivel de kernel, una combinación que apunta a un operador motivado y capaz. No se ha hecho pública una atribución definitiva; sin embargo, el conjunto de herramientas y el aparente uso de la vulnerabilidad para proxy y acceso remoto persistente sugieren firmemente una actividad con fines económicos (pivotación, proxy para intrusiones adicionales o reventa del acceso).

Dependencia del kernel y comportamiento de respaldo

Dado que LinkPro utiliza las funciones de anulación de kprobe de BPF para su interceptación sigilosa del kernel, solo aplica la técnica de ocultación a nivel de kernel cuando el kernel del host expone CONFIG_BPF_KPROBE_OVERRIDE. Cuando esta capacidad del kernel no está disponible, LinkPro recurre deliberadamente al método de biblioteca compartida LD_PRELOAD para ocultarse en el espacio de usuario, garantizando así la ocultación en una amplia gama de entornos.

Nota de cierre

LinkPro demuestra cómo las intrusiones modernas pueden combinar la vulneración de contenedores, cargadores preconfigurados, instrumentación del kernel (eBPF) y trucos de red ingeniosos (activación de paquetes mágicos y reescritura de puertos) para mantener la discreción y la flexibilidad. La detección y la remediación requieren una inspección minuciosa para detectar programas eBPF no autorizados, entradas inesperadas en /etc/ld.so.preload, servicios systemd inusuales y conexiones de red a la infraestructura indicada (los indicadores forenses incluyen la IP 56.155.98[.]37, los puertos 29872, 2333, 2233 y el nombre de la imagen de Docker eliminada kvlnt/vv).