Rootkit Linux LinkPro

Una recente compromissione di un ambiente Amazon Web Services (AWS) ha rivelato un rootkit GNU/Linux precedentemente non documentato, identificato come LinkPro. Questa backdoor è degna di nota per il suo duplice utilizzo di moduli eBPF: uno impostato per nascondere artefatti e un altro che funge da trigger stealth, un "colpo" che attiva la funzionalità di comando remoto solo dopo aver rilevato un pacchetto TCP appositamente creato. La catena di attacco e i meccanismi del rootkit illustrano un operatore sofisticato che combina abuso di container, occultamento a livello di kernel e attivazione flessibile della rete per ostacolare il rilevamento e la correlazione forense.

Vettore di infezione e distribuzione iniziale

L'intrusione è iniziata con lo sfruttamento di un'istanza di Jenkins esposta e vulnerabile a CVE-2024-23897 (CVSS 9.8). Da quel punto d'appoggio, gli aggressori hanno inserito un'immagine Docker dannosa (kvlnt/vv, nel frattempo rimossa da Docker Hub) in diversi cluster Kubernetes. L'immagine utilizzava una base Kali Linux e conteneva una piccola cartella applicativa destinata a stabilire persistenza, accesso remoto e un download di backdoor a fasi.

All’interno dell’immagine Docker dannosa

La cartella dell'app dell'immagine conteneva tre file chiave con ruoli distinti:

start.sh — uno script shell che avvia un servizio SSH ed esegue gli altri due componenti.

link — un programma open source (vnt) compilato/confezionato per fungere da client VPN/proxy, connettendosi in uscita a vnt.wherewego[.]top:29872. Ciò consente all'aggressore di raggiungere l'host compromesso da qualsiasi luogo e di passare ad altri obiettivi tramite esso.

app : un downloader basato su Rust (denominato vGet) che recupera un payload vShell crittografato da un bucket S3, quindi stabilisce un collegamento WebSocket al suo server di comando e controllo (C2) a 56.155.98[.]37.

Payload aggiuntivi consegnati ai nodi Kubernetes

Oltre all'immagine dannosa, gli operatori hanno anche rilasciato altri due componenti sui nodi: un dropper che installa un'altra backdoor vShell e LinkPro, un rootkit scritto in Golang. LinkPro è progettato per funzionare in due modalità: passiva (inversa) o attiva (in avanti), a seconda della sua configurazione. In modalità passiva, attende di essere attivato da uno speciale pacchetto di rete; in modalità attiva, avvia il contatto con il C2 stesso. La modalità in avanti supporta cinque protocolli di trasporto (HTTP, WebSocket, UDP, TCP, DNS), mentre la modalità inversa limita le comunicazioni a HTTP.

Come persiste LinkPro

L'esecuzione complessiva e il comportamento persistente del malware seguono una sequenza chiara:

• Installa il modulo Hide eBPF. Questo modulo include i programmi eBPF Tracepoint e Kretprobe utilizzati per nascondere i processi e l'attività di rete di LinkPro.
• Se l'installazione del modulo Hide eBPF non riesce, o se è stato disabilitato, installare una libreria condivisa in /etc/libld.so e aggiungere tale percorso a /etc/ld.so.preload come meccanismo di occultamento di riserva.
• Per il funzionamento inverso (passivo), installare il modulo Knock eBPF. Knock contiene un programma XDP e un programma TC, quindi il canale C2 diventa attivo solo dopo aver ricevuto uno specifico "pacchetto magico".
• Stabilisci la persistenza creando un servizio systemd.
• Eseguire i comandi ricevuti dal C2.
• Allo spegnimento o quando segnalato (SIGHUP, SIGINT, SIGTERM), disinstallare i moduli eBPF e rimuovere/ripristinare la modifica di precaricamento /etc/libld.so in modo che il sistema ritorni allo stato precedente.

Il pacchetto magico e il meccanismo di attivazione del colpo

L'attivazione passiva di LinkPro dipende da un preciso pacchetto TCP: qualsiasi pacchetto TCP la cui dimensione della finestra sia pari a 54321 viene trattato come "pacchetto magico". Quando Knock rileva quel pacchetto, memorizza l'IP sorgente e lo contrassegna con una scadenza di un'ora. I pacchetti TCP successivi provenienti da quella sorgente vengono monitorati e, se necessario, Knock riscrive le intestazioni in modo che il traffico dell'operatore venga reindirizzato alla porta di ascolto di LinkPro (2333). I pacchetti in uscita vengono modificati per presentare alla rete la porta originale (porta sorgente riscritta a 2233). L'intento è semplice ma efficace: consentire all'attaccante di raggiungere LinkPro attraverso qualsiasi porta consentita dal firewall front-end, rendendo al contempo difficile correlare i log del firewall esterno con l'attività di rete interna dell'host.

Come si nasconde LinkPro

LinkPro utilizza una strategia di occultamento a due livelli:

Nascondere kernel/eBPF : il modulo Hide eBPF installa i programmi Tracepoint e Kretprobe che intercettano le chiamate di sistema come getdents (per nascondere file/directory) e sys_bpf (per nascondere i propri programmi BPF). Questo approccio richiede un kernel compilato con CONFIG_BPF_KPROBE_OVERRIDE abilitato.

Fallback LD_PRELOAD in spazio utente : se la funzionalità kernel non è presente, LinkPro scrive una libreria condivisa (libld.so) e ne inserisce il percorso in /etc/ld.so.preload. Poiché /etc/ld.so.preload fa sì che la libreria specificata venga caricata in ogni processo collegato dinamicamente (quelli che utilizzano /lib/ld-linux.so e glibc), la libreria libld.so impiantata aggancia le funzioni libc in anticipo (prima del comportamento di glibc) e modifica i ritorni delle chiamate a libc per nascondere artefatti che altrimenti ne esporrebbero la presenza.

Capacità del rootkit e set di comandi

LinkPro supporta sia azioni remote interattive che automatizzate. Le sue funzionalità implementate includono:

• Avvio di uno pseudo-terminale /bin/bash ed esecuzione di sessioni shell interattive.
• Esecuzione di comandi shell arbitrari.
• Enumerazione di file e directory ed esecuzione di operazioni sui file.
• Scaricamento e scrittura di file su disco.
• Creazione di un tunnel proxy SOCKS5 per il pivoting e il proxy living-off-the-land.

Supporto del protocollo di rete e comportamento C2

In modalità attiva (in avanti), LinkPro è flessibile: può comunicare tramite HTTP, WebSocket, UDP, TCP o DNS. In modalità passiva (inversa), la sua comunicazione è limitata a HTTP, ma beneficia della furtività perché rimane in ascolto solo dopo che il pacchetto magico Knock ha aperto una finestra di comando temporanea di un'ora.

Comportamento di pulizia e disinstallazione

Se il processo riceve segnali di terminazione, LinkPro mira a rimuovere le tracce: disinstalla i moduli eBPF installati ed elimina o ripristina /etc/libld, riportandolo allo stato precedente in modo che il sistema appaia invariato. Questa routine di pulizia deliberata indica un operatore attento a evitare elusioni e a ridurre al minimo le impronte forensi a lungo termine.

Contesto operativo e attribuzione

La campagna ha utilizzato un exploit Jenkins ad alta gravità, immagini di container dannose, diverse varianti di backdoor e stealth a livello di kernel: una combinazione che indica un operatore motivato e capace. Non è stata resa pubblica alcuna attribuzione definitiva; tuttavia, il set di strumenti e l'apparente utilizzo della compromissione per il proxy e l'accesso remoto persistente suggeriscono fortemente un'attività motivata da ragioni finanziarie (pivoting, proxy per ulteriori intrusioni o rivendita dell'accesso).

Dipendenza del kernel e comportamento di fallback

Poiché LinkPro si affida alle funzionalità di override di BPF kprobe per la sua intercettazione stealth del kernel, applica la tecnica di occultamento a livello kernel solo quando il kernel host espone CONFIG_BPF_KPROBE_OVERRIDE. Laddove tale funzionalità del kernel sia assente, LinkPro ricorre deliberatamente al metodo della libreria condivisa LD_PRELOAD per nascondersi nello spazio utente, garantendo l'occultamento in un'ampia gamma di ambienti.

Nota di chiusura

LinkPro dimostra come le intrusioni moderne possano combinare compromissione dei container, loader a stadi, strumentazione del kernel (eBPF) e ingegnosi trucchi di rete (attivazione di pacchetti magici e riscrittura delle porte) per mantenere furtività e flessibilità. Il rilevamento e la correzione richiedono un'attenta ispezione per individuare programmi eBPF non autorizzati, voci inaspettate in /etc/ld.so.preload, servizi systemd insoliti e connessioni di rete all'infrastruttura indicata (gli indicatori forensi includono l'IP 56.155.98[.]37, le porte 29872, 2333, 2233 e il nome dell'immagine Docker rimossa kvlnt/vv).