Fuites eBPF : Quand votre outil de surveillance devient le rootkit ultime 🕵️

Dans le paysage de 2026, le noyau Linux n’est plus un simple gardien statique ; c’est un terrain de jeu dynamique et programmable. Au cœur de cette transformation se trouve eBPF (extended Berkeley Packet Filter). Autrefois un outil modeste pour filtrer les paquets réseau, eBPF est devenu la “superpuissance” de l’observabilité cloud-native, du réseautage et de la sécurité. Il alimente les maillages de services les plus avancés, les pare-feux haute performance et les moniteurs système profonds.

Cependant, comme le dit le vieux proverbe de la sécurité : avec de grands pouvoirs viennent de grandes exploitations. Alors que des outils légitimes comme Cilium, Tetragon et Pixie utilisent eBPF pour protéger les clusters, une nouvelle génération de “Fuites eBPF” a émergé. En 2025 et début 2026, les chercheurs ont constaté une recrudescence de rootkits basés sur eBPF — des programmes malveillants exploitant le bytecode “sûr” du noyau pour dissimuler des fichiers, voler des identifiants et rediriger le trafic avec une invisibilité quasi totale.

Cet article explore la mécanique des rootkits eBPF, les vulnérabilités du vérificateur eBPF, et comment votre outil de surveillance le plus fiable pourrait être la cause même de votre aveuglement face à une intrusion.

1. L’architecture du contrôle : pourquoi eBPF est l’arme parfaite

Pour comprendre comment eBPF devient un rootkit, il faut saisir pourquoi il a été conçu. Traditionnellement, modifier le comportement du noyau nécessitait d’écrire un Kernel Module (LKM). C’était risqué ; un seul bug pouvait faire planter tout le système (un “Kernel Panic”).

eBPF a changé cela en introduisant une machine virtuelle sandboxée à l’intérieur du noyau. Elle permet aux développeurs de :

• Écrire du code dans un langage restreint ressemblant à C.
• Vérifier la sécurité via un “Vérificateur eBPF” qui s’assure que le code ne boucle pas à l’infini ou n’accède pas à une mémoire illégale.
• Compiler Just-In-Time (JIT) le code en instructions machine natives pour un coût quasi nul.
• Attacher à des hooks comme syscalls, tracepoints ou événements réseau.

La perspective de l’attaquant

Pour un attaquant, eBPF est supérieur aux rootkits traditionnels pour trois raisons :

Persistance sans redémarrage : les programmes eBPF peuvent être chargés et déchargés dynamiquement.

Sécurité contre la détection : les outils EDR (Endpoint Detection and Response) traditionnels recherchent des fichiers ou processus suspects. Les programmes eBPF vivent dans l’espace mémoire du noyau, laissant souvent aucune trace sur le disque.

Masquage légitime : comme de nombreux outils de sécurité (Falco, Datadog) utilisent eBPF, un programme malveillant peut facilement se dissimuler dans le bruit des probes légitimes du noyau.

2. Armement du hook : comment les rootkits eBPF manipulent la réalité

Un rootkit eBPF ne casse pas le système ; il déforme sa perception. En se branchant sur des fonctions critiques du noyau, un attaquant peut changer ce que l’OS rapporte à l’utilisateur.

A. Cacher des fichiers et processus (le hook getdents64)

La méthode la plus courante pour dissimuler un rootkit est de hooker la syscall sys_getdents64. C’est la fonction que le noyau utilise pour lister les fichiers d’un répertoire.

L’attaque : lorsque vous exécutez ls ou ps, le noyau appelle getdents64. Un programme eBPF malveillant (attaché via un hook fexit ou kretprobe) intercepte la liste des fichiers avant qu’elle n’atteigne l’espace utilisateur.

Le résultat : le programme eBPF parcourt la liste, identifie les noms de fichiers ou PIDs liés au malware, et les supprime du buffer. L’utilisateur voit un répertoire “propre”, tandis que le malware continue de fonctionner en toute invisibilité.

B. Redirection réseau (hooks XDP et TC)

eBPF opère au niveau XDP (eXpress Data Path) — le point le plus bas de la pile réseau, avant que le paquet n’atteigne le pare-feu Linux (iptables/nftables).

L’attaque : des rootkits comme LinkPro (découvert fin 2025) utilisent XDP pour écouter les “Magic Packets”. Ce sont des paquets TCP spécialement conçus (par exemple, une taille de fenêtre ou un numéro de séquence spécifique) qui agissent comme un “Wake-on-LAN” pour le malware.

Le résultat : le rootkit peut intercepter le trafic C2 (Command and Control) et supprimer les paquets pour qu’ils n’apparaissent jamais dans tcpdump ou Wireshark. Il peut aussi rediriger le trafic vers un proxy caché, exfiltrant des données sans que la pile réseau locale ne s’en aperçoive.

C. Vol de crédentials (Uprobes et PAM)

Les attaquants peuvent utiliser uprobes (Probes utilisateur) pour hooker des fonctions dans des bibliothèques partagées comme libpam.so (le module d’authentification modulaire Linux).

L’attaque : des outils comme Pamspy hookent la fonction pam_get_authtok.

Le résultat : chaque fois qu’un utilisateur tape un mot de passe pour sudo, ssh ou une connexion locale, le programme eBPF capture le mot de passe en clair et le stocke dans une Map eBPF (structure de données résidente du noyau) pour que l’attaquant puisse le récupérer plus tard.

3. Briser le “Bouncer” : la contournement du vérificateur eBPF

La seule barrière entre un développeur et un bug qui peut casser le noyau est le Vérificateur eBPF. C’est le “bouncer” du noyau, effectuant une analyse statique pour garantir la sécurité mémoire. Cependant, le vérificateur est une pièce complexe de logiciel, et comme tout logiciel, il comporte des bugs.

La vulnérabilité find_equal_scalars

Lors d’un audit de sécurité majeur en 2024 par le NCC Group, des chercheurs ont identifié des failles logiques dans la façon dont le vérificateur suit les valeurs “scalaires” (entiers).

L’exploit : un attaquant peut écrire un programme eBPF utilisant des opérations bitwise complexes (AND, OR, XOR) pour tromper le vérificateur en lui faisant croire qu’un registre contient une valeur sûre (par exemple, 0 à 64), alors qu’il contient en réalité une grande valeur (par exemple, une adresse mémoire).

L’évasion : une fois le vérificateur trompé, le compilateur JIT produit un code permettant au programme eBPF de lire et écrire dans la mémoire du noyau de façon arbitraire. C’est le “Saint Graal” pour un attaquant, transformant un programme sandboxé en une exploitation kernel à grande échelle.

Failles logiques vs. abus de fonctionnalités

Toutes les fuites eBPF ne nécessitent pas une “vulnérabilité”. Beaucoup exploitent les fonctions d’aide propres au noyau. Par exemple, bpf_probe_write_user est une fonction légitime utilisée par les débogueurs pour modifier la mémoire. Un attaquant peut l’utiliser pour injecter un utilisateur “root” dans le buffer /etc/passwd en mémoire, lors de la lecture par le processus de login, sans toucher au fichier réel sur disque.

4. Le fossé de visibilité : pourquoi la sécurité traditionnelle est aveugle

Pourquoi votre outil EDR haut de gamme ne peut-il pas détecter ces rootkits ? La réponse réside dans le fossé de visibilité.

Fonctionnalité	Malware traditionnel	Rootkit eBPF
Empreinte disque	Fichiers binaires dans /usr/bin ou /tmp	Réside uniquement en mémoire du noyau
Logs syscall	Visible dans auditd ou syslog	Hooke les fonctions de journalisation elles-mêmes
Trafic réseau	Visible via iptables et tcpdump	Intercepté au niveau XDP/driver
Détection	Signatures/hachages de fichiers	Exécution de bytecode “sans signe”

En 2026, la plupart des EDR se concentrent encore sur l’espace utilisateur. Ils surveillent les arbres de processus et les modifications de fichiers. Un rootkit eBPF, cependant, est un “fantôme dans la machine”. Il ne crée pas un nouveau processus ; il modifie simplement le comportement des processus existants.

Si vous demandez au noyau, “Y a-t-il un processus nommé ‘backdoor’ ?”, le noyau (qui est maintenant sous le contrôle du rootkit) répond simplement : “Non.”

5. Étude de cas : l’épidémie LinkPro 2025

L’exemple le plus sophistiqué d’une fuite eBPF à ce jour est LinkPro, un rootkit découvert en octobre 2025 ciblant des clusters Kubernetes hébergés sur AWS.

Accès initial : les attaquants ont exploité une vulnérabilité dans un serveur Jenkins (CVE-2024-23897) pour obtenir un accès initial.

Déploiement : au lieu d’une simple shell, ils ont déployé une image Docker malveillante contenant des modules eBPF.

Hooking du noyau : LinkPro a chargé deux modules. L’un hooke sys_bpf — la syscall utilisée pour charger d’autres programmes eBPF. Cela a permis au rootkit de dissimuler sa présence aux outils comme bpftool.

C2 furtif : le rootkit est resté inactif jusqu’à ce qu’il reçoive un paquet “Magic TCP SYN” avec une taille de fenêtre spécifique (54321). Ce n’est qu’à ce moment qu’il ouvrait une reverse shell, rendant toute détection par scan de ports classique impossible.

LinkPro a démontré que eBPF n’est pas seulement un outil de persistance locale ; c’est aussi un outil de mouvement latéral cloud-native.

6. Comment défendre votre noyau en 2026

Si le vérificateur peut être contourné et que les hooks peuvent être dissimulés, y a-t-il un espoir pour les défenseurs ? Oui, mais cela nécessite un passage du “Sécurité Legacy” à la “Sécurité Kernel-Consciente”.

1. Renforcer la configuration du noyau

La première ligne de défense consiste à restreindre qui peut charger des programmes eBPF.

Désactiver BPF non privilégié : assurez-vous que kernel.unprivileged_bpf_disabled = 1 est activé. Cela empêche les utilisateurs non root de charger du code BPF.

Limiter les capacités : utilisez les capacités Linux pour garantir que seuls certains services (comme votre agent de surveillance) disposent de CAP_BPF et CAP_PERFMON.

2. Surveillance de l’intégrité en temps réel (Tetragon et Tracee)

Ironiquement, la meilleure façon de lutter contre un rootkit eBPF est avec de meilleurs eBPF. Des outils comme Tetragon (de Cilium) utilisent eBPF pour surveiller l’état du noyau lui-même.

Renforcement par signature : en 2026, de nombreuses organisations ont adopté des programmes eBPF signés. Le noyau est configuré pour ne charger que du bytecode BPF cryptographiquement signé par une autorité de confiance (comme l’équipe de sécurité).

Intégrité BTF : la surveillance des données BPF Type Format (BTF) peut révéler si un rootkit a modifié des structures du noyau pour dissimuler ses maps.

3. Enquête forensique

Les équipes de sécurité doivent régulièrement effectuer des “Snapshots du noyau”.

bpftool : utilisez bpftool prog show pour lister tous les programmes chargés. Si certains n’ont pas de nom ou PID associé, investiguez immédiatement.

Forensique mémoire : dans des environnements hautement sécurisés, l’analyse mémoire au niveau de l’hyperviseur (avec des outils comme Volatility 3) peut identifier des programmes eBPF hookant sys_bpf pour se cacher de bpftool.

4. Surveillez les “Magic Packets”

Les pare-feux modernes doivent être configurés pour détecter les “Valeurs d’en-tête anormales”. Les rootkits eBPF utilisent souvent des drapeaux TCP ou des tailles de fenêtre non standard pour l’activation. L’IA comportementale dans les pare-feux 2026 est désormais spécifiquement ajustée pour repérer ces paquets “à faible fréquence, haute intention”.

7. Conclusion : la double utilisation du noyau moderne

Alors que nous avançons vers 2026, la bataille pour le noyau Linux ne fera que s’intensifier. eBPF est une technologie à double usage — une avancée pour la performance et l’observabilité qui sert aussi d’outil ultime pour des acteurs sophistiqués.

Pour les organisations, la leçon est claire : vous ne pouvez pas faire confiance à ce que vous ne pouvez pas vérifier. Si vous utilisez eBPF pour votre surveillance et votre sécurité, vous devez également sécuriser le sous-système eBPF lui-même. L’outil qui vous donne une “radiographie” de vos conteneurs peut, s’il est compromis, devenir un bandeau pour un prédateur dans votre noyau.

Votre noyau est-il programmable ? Oui. Mais la question est : qui programme ?