Rootkit Linux LinkPro

Une récente compromission d'un environnement Amazon Web Services (AWS) a révélé un rootkit GNU/Linux jusqu'alors non documenté, identifié comme LinkPro. Cette porte dérobée se distingue par sa double utilisation de modules eBPF : l'un configuré pour masquer les artefacts, et l'autre agissant comme un déclencheur furtif – un « knock » qui active la fonctionnalité de commande à distance uniquement après la détection d'un paquet TCP spécialement conçu. La chaîne d'attaque et les mécanismes du rootkit illustrent un opérateur sophistiqué qui combine abus de conteneur, dissimulation au niveau du noyau et activation réseau flexible pour contrecarrer la détection et la corrélation forensique.

Vecteur d’infection et déploiement initial

L'intrusion a débuté par l'exploitation d'une instance Jenkins exposée, vulnérable à la vulnérabilité CVE‑2024‑23897 (CVSS 9.8). À partir de ce point d'ancrage, les attaquants ont déployé une image Docker malveillante (kvlnt/vv, depuis supprimée de Docker Hub) dans plusieurs clusters Kubernetes. L'image utilisait une base Kali Linux et contenait un petit dossier d'application destiné à établir la persistance, l'accès à distance et un téléchargement par porte dérobée.

À l’intérieur de l’image malveillante de Docker

Le dossier d'application de l'image contenait trois fichiers clés avec des rôles distincts :

start.sh — un script shell qui lance un service SSH et exécute les deux autres composants.

Link — un programme open source (vnt) compilé/packagé pour agir comme client VPN/proxy, se connectant en sortie à vnt.wherewego[.]top:29872. Cela permet à l'attaquant d'atteindre l'hôte compromis de n'importe où et de passer par lui pour atteindre d'autres cibles.

app — un téléchargeur basé sur Rust (appelé vGet) qui récupère une charge utile vShell chiffrée à partir d'un bucket S3, puis établit un lien WebSocket vers son serveur de commande et de contrôle (C2) à 56.155.98[.]37.

Charges utiles supplémentaires livrées aux nœuds Kubernetes

Outre l'image malveillante, les opérateurs ont également déployé deux autres composants sur les nœuds : un dropper installant une autre porte dérobée vShell, et LinkPro, un rootkit écrit en Golang. LinkPro est conçu pour fonctionner en deux modes : passif (inverse) ou actif (direct) selon sa configuration. En mode passif, il attend d'être activé par un paquet réseau spécifique ; en mode actif, il établit le contact avec le C2 lui-même. Le mode direct prend en charge cinq protocoles de transport (HTTP, WebSocket, UDP, TCP, DNS), tandis que le mode inverse limite les communications à HTTP.

Comment LinkPro persiste

L'exécution globale et le comportement de persistance du malware suivent une séquence claire :

• Installez le module Hide eBPF. Ce module inclut les programmes eBPF Tracepoint et Kretprobe utilisés pour masquer les processus et l'activité réseau de LinkPro.
• Si l'installation du module Hide eBPF échoue — ou s'il a été désactivé — installez une bibliothèque partagée dans /etc/libld.so et ajoutez ce chemin à /etc/ld.so.preload comme mécanisme de masquage de secours.
• Pour un fonctionnement passif (inverse), installez le module eBPF Knock. Knock contient un programme XDP et un programme TC ; le canal C2 n'est donc actif qu'après réception d'un « paquet magique » spécifique.
• Établissez la persistance en créant un service systemd.
• Exécuter les commandes reçues du C2.
• À l'arrêt ou lorsqu'il est signalé (SIGHUP, SIGINT, SIGTERM), désinstallez les modules eBPF et supprimez/restaurez la modification de préchargement /etc/libld.so afin que le système revienne à son état antérieur.

Le paquet magique et le mécanisme d’activation par frappe

L'activation passive de LinkPro dépend d'un paquet TCP précis : tout paquet TCP dont la taille de fenêtre est égale à 54 321 est considéré comme le « paquet magique ». Lorsque Knock détecte ce paquet, il enregistre l'adresse IP source et lui attribue une date d'expiration d'une heure. Les paquets TCP suivants provenant de cette source sont surveillés et, le cas échéant, Knock réécrit les en-têtes afin que le trafic de l'opérateur soit redirigé vers le port d'écoute de LinkPro (2333). Les paquets sortants sont ajustés pour renvoyer le port d'origine au réseau (port source réécrit à 2233). L'objectif est simple, mais efficace : permettre à l'attaquant d'atteindre LinkPro par n'importe quel port autorisé par le pare-feu frontal, tout en rendant difficile la corrélation des journaux du pare-feu externe avec l'activité réseau interne de l'hôte.

Comment LinkPro se cache

LinkPro utilise une stratégie de dissimulation à deux niveaux :

Masquage du noyau/eBPF : Le module « Masquer eBPF » installe les programmes Tracepoint et Kretprobe qui interceptent les appels système, tels que getdents (pour masquer les fichiers/répertoires) et sys_bpf (pour masquer ses propres programmes BPF). Cette approche nécessite un noyau compilé avec CONFIG_BPF_KPROBE_OVERRIDE activé.

Solution de secours LD_PRELOAD dans l'espace utilisateur : si la fonctionnalité noyau n'est pas présente, LinkPro écrit une bibliothèque partagée (libld.so) et place son chemin dans /etc/ld.so.preload. Comme /etc/ld.so.preload charge la bibliothèque spécifiée dans chaque processus lié dynamiquement (ceux utilisant /lib/ld-linux.so et glibc), la bibliothèque libld.so implantée intercepte les fonctions libc en amont (avant le comportement de glibc) et modifie les retours des appels libc pour masquer les artefacts qui révéleraient autrement sa présence.

Capacités et jeu de commandes du rootkit

LinkPro prend en charge les actions à distance interactives et automatisées. Ses fonctionnalités implémentées incluent :

• Démarrage d’un pseudo-terminal /bin/bash et exécution de sessions shell interactives.
• Exécution de commandes shell arbitraires.
• Énumération des fichiers et des répertoires et exécution d'opérations sur les fichiers.
• Téléchargement et écriture de fichiers sur le disque.
• Mise en place d'un tunnel proxy SOCKS5 pour pivoter et vivre de la terre en proxy.

Prise en charge du protocole réseau et comportement C2

En mode actif (direct), LinkPro est flexible : il peut communiquer via HTTP, WebSocket, UDP, TCP ou DNS. En mode passif (inverse), sa communication est limitée à HTTP, mais bénéficie de la discrétion, car il n'écoute qu'après que le paquet magique Knock a ouvert une fenêtre de commande temporaire d'une heure.

Comportement de nettoyage et de désinstallation

Si le processus reçoit des signaux d'arrêt, LinkPro s'efforce de supprimer les traces : il désinstalle les modules eBPF installés et supprime ou restaure le fichier /etc/libld, le regroupant à son état précédent afin que le système apparaisse inchangé. Ce nettoyage délibéré indique que l'opérateur est soucieux de limiter les évasions et de minimiser les traces d'analyse à long terme.

Contexte opérationnel et attribution

La campagne a utilisé un exploit Jenkins de haute gravité, des images de conteneurs malveillantes, plusieurs variantes de portes dérobées et une furtivité au niveau du noyau – une combinaison qui suggère un opérateur motivé et compétent. Aucune attribution définitive n'a été rendue publique ; cependant, l'ensemble des outils et l'utilisation apparente de la compromission pour le proxy et l'accès distant persistant suggèrent fortement une activité motivée par des raisons financières (pivoting, proxy pour des intrusions supplémentaires ou revente d'accès).

Dépendance du noyau et comportement de secours

Comme LinkPro s'appuie sur les fonctionnalités de substitution de BPF kprobe pour son interception furtive du noyau, il n'applique la technique de masquage au niveau du noyau que lorsque le noyau hôte expose CONFIG_BPF_KPROBE_OVERRIDE. Lorsque cette fonctionnalité du noyau est absente, LinkPro utilise délibérément la méthode de bibliothèque partagée LD_PRELOAD pour se dissimuler dans l'espace utilisateur, garantissant ainsi sa dissimulation dans un large éventail d'environnements.

Note de clôture

LinkPro démontre comment les intrusions modernes peuvent combiner compromission de conteneurs, chargeurs étagés, instrumentation du noyau (eBPF) et astuces réseau astucieuses (activation de paquets magiques et réécriture de ports) pour préserver discrétion et flexibilité. La détection et la correction nécessitent une inspection minutieuse des programmes eBPF non autorisés, des entrées inattendues dans /etc/ld.so.preload, des services systemd inhabituels et des connexions réseau à l'infrastructure indiquée (les indicateurs d'investigation incluent l'adresse IP 56.155.98[.]37, les ports 29872, 2333 et 2233, ainsi que le nom d'image Docker supprimé kvlnt/vv).