Rootkits eBPF : comprendre la menace et la détecter

Un rootkit eBPF est un logiciel malveillant qui abuse d'eBPF pour se cacher, écouter et persister au cœur du noyau : cette page explique ce qu'il peut faire, cite les cas réels documentés, et montre comment le détecter. L'angle est strictement défensif : aucun mode opératoire pour en construire un, mais tout ce qu'un administrateur doit savoir pour ne pas être aveugle. Bonne nouvelle démontrée à la fin : même un programme conçu pour être discret reste visible avec les bons outils. Public : ingénieur sécurité, administrateur de serveurs sensibles. Sorties capturées sur une VM Ubuntu 24.04 (noyau 6.8). Contexte préalable : la surface d'attaque d'eBPF.

Ce que vous allez apprendre

• Comprendre ce qu'un rootkit eBPF cherche à accomplir
• Connaître les cas réels documentés, en production comme en recherche
• Saisir pourquoi ils sont difficiles à repérer avec les outils classiques
• Détecter un programme eBPF suspect avec bpftool
• Relier la détection aux mesures de durcissement

Un attaquant déjà privilégié

Un rootkit eBPF n'est pas un moyen d'entrer dans un système : il faut déjà les privilèges pour charger un programme eBPF. C'est un outil de persistance et de furtivité une fois l'accès obtenu. La première défense reste donc d'empêcher cet accès initial ; ce qui suit traite de la couche d'après.

Ce qu'un rootkit eBPF cherche à faire

La puissance d'eBPF, observer et influencer le noyau, devient une menace entre de mauvaises mains. Quatre objectifs reviennent, décrits ici au niveau conceptuel.

Se cacher. En s'intercalant sur les fonctions que les outils système utilisent pour lister les processus, les fichiers ou les connexions, un rootkit peut filtrer ce que voit l'administrateur. Un processus malveillant devient invisible à ps, un fichier à ls, une connexion à netstat, alors qu'ils existent bel et bien.

Ouvrir une backdoor passive. Plutôt qu'un port en écoute (repérable), un rootkit peut utiliser un filtre de paquets pour guetter un paquet « magique » dans le trafic normal. À sa réception, il déclenche une action (ouvrir un accès). Sans port ouvert, la porte dérobée échappe aux outils qui listent les services.

Voler des données. En s'accrochant aux bonnes fonctions, un programme peut lire des informations au moment où elles sont en clair dans la mémoire d'une application, avant chiffrement ou après déchiffrement.

Altérer les réponses du noyau. Certains types de programmes peuvent modifier ce qu'une fonction du noyau renvoie, pour tromper un contrôle ou masquer une action.

Les cas réels, documentés

Ce n'est pas de la théorie. Plusieurs cas sont publiquement documentés et servent de référence aux défenseurs.

• BPFDoor : une porte dérobée Linux observée en production, attribuée par plusieurs éditeurs à un groupe étatique. Elle utilise un filtre BPF pour écouter passivement un paquet déclencheur, sans port ouvert. Sa discrétion en a fait un cas d'école, restée active des années sur des cibles.
• Symbiote : un logiciel malveillant Linux documenté en 2022, qui recourt à BPF pour filtrer le trafic réseau et dissimuler ses communications de commande.
• ebpfkit et TripleCross : des rootkits de recherche, publiés par des chercheurs en sécurité (présentations en conférence, code ouvert à visée éducative). Ils démontrent les techniques ci-dessus et servent aux équipes défensives à s'entraîner à les détecter.

Pourquoi on n'en donne pas la recette

Cette page ne montre pas comment construire un tel outil. La valeur pour un défenseur n'est pas de savoir l'écrire, mais de savoir ce qu'il fait et comment le repérer. Les projets de recherche cités existent pour ceux qui doivent tester leurs défenses ; leur code est déjà public et documenté, ce n'est pas l'objet ici.

Pourquoi ils sont difficiles à repérer

Un rootkit eBPF opère au niveau du noyau, sous les outils d'administration. S'il fausse ce que ps ou ls renvoient, l'administrateur qui s'appuie sur ces outils voit un système sain. C'est toute la difficulté : les instruments habituels de diagnostic sont précisément ceux que le rootkit manipule. Chercher un processus caché avec ps revient à demander au menteur s'il ment.

Mais ils restent détectables

Voici le point rassurant, et il est décisif. Un rootkit eBPF peut tromper les outils système, mais il ne peut pas facilement se cacher du sous-système eBPF lui-même. Tout programme chargé est visible avec bpftool, l'outil d'inspection du noyau, qui ne dépend pas des fonctions que le rootkit détourne.

D'abord, lister les accroches actives : à quoi les programmes sont rattachés.

sudo bpftool link show

Sortie réelle (ici une accroche modify_return, un type qui peut altérer des retours de fonctions, à examiner de près sur une machine de production) :

1: tracing  prog 2
  prog_type tracing  attach_type modify_return
  target_obj_id 1  target_btf_id 93388

Ensuite, inspecter le code d'un programme suspect. bpftool en restitue le bytecode vérifié, annoté :

sudo bpftool prog dump xlated id <numéro>

int deref_avec_test(void * ctx):
; int deref_avec_test(void *ctx) {
   0: (b7) r1 = 0
; __u32 cle = 0;
   1: (63) *(u32 *)(r10 -4) = r1

Un défenseur voit donc le nom, le type, l'accroche et jusqu'aux instructions de chaque programme chargé. Un rootkit peut masquer un processus dans ps, il n'efface pas sa propre trace dans bpftool prog show.

Détecter en pratique

La démarche défensive s'appuie sur cette visibilité et complète les mesures de durcissement.

1. Établir une référence. Sur une machine saine, relever la liste des programmes (bpftool prog show) et des accroches (bpftool link show). C'est votre point de comparaison.

2. Comparer régulièrement. Tout programme kprobe, tracing ou modify_return absent de la référence est suspect. Une accroche modify_return non expliquée mérite une attention particulière.

3. Surveiller les chargements. L'appel système bpf() peut lui-même être surveillé : un outil de sécurité runtime (comme Tetragon ou Tracee) alerte quand un programme est chargé. C'est eBPF qui surveille eBPF.

4. Restreindre en amont. Avec BPF LSM, on peut n'autoriser le chargement qu'à des processus légitimes, coupant l'herbe sous le pied à un rootkit même sur une machine compromise.

L'ironie utile

L'outil de sécurité runtime qui protège vos serveurs et le rootkit qui les menace reposent sur la même technologie. C'est ce qui rend la détection possible : un programme eBPF défensif observe le chargement et l'activité des autres programmes eBPF. La défense joue sur le même terrain que l'attaque.

À retenir

• Un rootkit eBPF abuse d'eBPF pour se cacher, ouvrir une backdoor passive, voler des données ou altérer les retours du noyau.
• Ce n'est pas un vecteur d'entrée : il suppose un attaquant déjà privilégié, d'où l'importance de la défense en amont.
• Des cas réels sont documentés : BPFDoor (in the wild), Symbiote, et les rootkits de recherche ebpfkit / TripleCross.
• Ils sont durs à voir avec ps/ls/netstat, qu'ils manipulent, mais restent visibles dans bpftool (prog show, link show, prog dump).
• La détection repose sur une référence connue, une comparaison régulière, et la surveillance des chargements (eBPF surveille eBPF).
• BPF LSM permet de restreindre en amont qui peut charger un programme.

Prochaines étapes

Durcir eBPF sur un serveur Les contre-mesures : sysctl, CAP_BPF, audit, BPF LSM.

La surface d'attaque d'eBPF Les trois zones de risque du sous-système.

Tetragon : observer et bloquer à l'exécution Utiliser eBPF pour détecter les comportements suspects, dont les chargements.

Le vérificateur eBPF expliqué Le gardien qui limite déjà ce qu'un programme peut faire.

×

📖 Voir la documentation →