eBPF rootkits : la menace furtive qui aveugle vos EDR Linux

L'attaque supply chain « Atomic Arch » du 12 juin 2026 a compromis 408 packages de l'Arch User Repository en déployant, entre autres, un rootkit eBPF. Ce n'est pas un incident isolé : eBPF est en train de devenir la plateforme de choix des acteurs offensifs avancés pour maintenir une présence furtive sur les systèmes Linux. Et la majorité des équipes de sécurité n'ont encore ni la visibilité ni les outils pour le détecter.

eBPF : comprendre la technologie avant de comprendre la menace

Pour saisir pourquoi eBPF est dangereux entre de mauvaises mains, il faut comprendre ce que c'est vraiment — pas la version marketing, la version technique.

BPF (Berkeley Packet Filter) est né en 1992 dans un article de McCanne et Jacobson comme un mécanisme de filtrage de paquets réseau au niveau noyau, évitant la copie coûteuse des données vers l'espace utilisateur. Linux l'a implémenté dans les années 1990 pour des outils comme tcpdump. Pendant vingt ans, BPF est resté cantonné à ce rôle de filtrage réseau.

Tout change en 2014 avec l'introduction d'eBPF dans Linux 3.18. « Extended BPF » est une refonte radicale : une machine virtuelle RISC 64 bits avec 11 registres, un jeu d'instructions étendu, un JIT compiler qui traduit les programmes eBPF en code machine natif, et surtout un verifier statique qui valide la sécurité du programme avant son chargement dans le noyau. Ce dernier point est crucial : le verifier garantit que le programme ne peut pas planter le noyau, boucler indéfiniment, ou accéder à de la mémoire non initialisée. Il ne vérifie pas les intentions malveillantes.

Depuis Linux 3.18, l'écosystème eBPF a explosé. Les versions 4.x et 5.x ont ajouté des dizaines de nouveaux types de programmes et de hook points : tracepoints (événements kernel statiques), kprobes (hook dynamique sur n'importe quelle fonction noyau), uprobes (hook sur des fonctions userspace), XDP (traitement réseau avant même l'allocateur de paquets), TC (traffic control), LSM (Linux Security Modules), sock_ops, cgroup, perf events. En 2026, un programme eBPF peut s'accrocher à des milliers de points d'observation dans le noyau Linux.

Les maps eBPF permettent aux programmes noyau de stocker de l'état et de communiquer avec l'espace utilisateur via des structures de données partagées (hash maps, arrays, ring buffers). C'est la combinaison hook points + maps qui rend eBPF si puissant : un programme peut observer des événements noyau, les stocker, les corréler, et les remonter vers un processus userspace de contrôle. Un programme eBPF peut également être « pinné » sur le système de fichiers BPF (/sys/fs/bpf/), lui assurant une persistance indépendante du processus qui l'a créé.

Aujourd'hui, les plus grandes infrastructures mondiales reposent sur eBPF : Cloudflare l'utilise pour son DDoS mitigation, Meta pour son monitoring de performance, Netflix pour sa télémétrie réseau, Google pour Katran (load balancer). Des projets comme Cilium (networking Kubernetes) et Falco (détection de menaces) sont entièrement construits sur eBPF. C'est une technologie légitime, puissante, et indispensable dans l'écosystème Linux moderne — ce qui complique considérablement sa défense, car un programme eBPF malveillant est difficile à distinguer d'un agent d'observabilité légitime sans analyse approfondie.

Pourquoi eBPF est l'outil idéal pour un attaquant avancé

Un rootkit traditionnel basé sur un module noyau (LKM) modifie directement le code du noyau Linux. Cette approche est puissante mais bruyante : le chargement d'un module non signé déclenche des alertes sur les systèmes avec Secure Boot et module signing activés. La modification directe de la table des appels système est de plus en plus difficile avec les protections modernes (KASLR, SMEP, SMAP, kCFI).

eBPF change radicalement l'équation. Voici les propriétés qui en font une plateforme offensive supérieure :

Légitimité apparente. Les programmes eBPF sont chargés via des appels système standards (bpf()) et passent par le verifier — un mécanisme de sécurité officiel du noyau. Il n'y a pas de modification du code noyau, pas de bypass de Secure Boot, pas de driver non signé. Sur un système avec des outils d'observabilité légitimes (Cilium, Falco, Datadog agent), des programmes eBPF chargés sont la norme, pas l'exception. Distinguer le légitime du malveillant requiert une analyse fine que la plupart des équipes de sécurité ne font pas en routine.

Furtivité face aux outils userspace. Les commandes classiques de monitoring (ps, netstat, ss, lsof, top) lisent le système de fichiers proc (/proc) ou font appel à des syscalls. Un rootkit eBPF peut hooker ces syscalls — notamment openat(), read(), getdents64() — pour filtrer les résultats retournés. Résultat : ps aux ne liste pas le processus malveillant, ss -anp ne montre pas la connexion C2, ls /proc ne voit pas le PID de l'attaquant.

Interception des flux d'information privilégiés. En hookant read() sur les descripteurs de fichiers associés aux sockets PAM, un programme eBPF capture les mots de passe en clair au moment où ils traversent le mécanisme d'authentification — avant tout chiffrement. C'est le principe de Pamspy (2022) : voler les credentials SSH, sudo et login en clair sans jamais toucher aux fichiers de configuration.

Persistance via bpf pinning. Les programmes et maps eBPF peuvent être pinnés sur le système de fichiers BPF (/sys/fs/bpf/), garantissant leur persistance tant que les fichiers pinned existent — indépendamment du processus qui les a créés. La suppression du binaire malveillant initial n'arrête pas le rootkit déjà chargé.

Prérequis minimal. eBPF requiert CAP_BPF ou CAP_SYS_ADMIN — disponibles par défaut pour root. Sur les postes de développement, sudo est courant pour l'installation de packages. Sur les runners CI/CD, les droits élevés sont fréquents pour accéder aux ressources partagées.

Les rootkits eBPF documentés — de la recherche académique au terrain

L'usage offensif d'eBPF n'est pas nouveau pour la communauté de sécurité. Ce qui est nouveau, c'est son passage du monde de la recherche académique aux opérations réelles à grande échelle.

Pamspy (2022) est la première démonstration publique d'un credential stealer eBPF. Il hooker la fonction pam_get_authtok de la bibliothèque PAM via un uprobe eBPF, capturant tous les mots de passe saisis pour sudo, ssh, login et toute application utilisant PAM — en clair, avant tout traitement. L'outil est entièrement documenté et a servi de référence technique pour les développements postérieurs.

ebpfkit (2021, Guillaume Fournier, Datadog) est une démonstration académique d'un rootkit réseau complet basé sur eBPF : backdoor réseau, masquage de connexions, interception de paquets, réponse à des triggers réseau spécifiques — sans aucune modification du code noyau. Présenté à HITB 2021 et DEF CON, il a démontré la faisabilité opérationnelle de cette approche à la communauté défensive.

Boopkit (2022, Kris Nova) implémente un reverse shell activé via eBPF : un paquet réseau spécialement crafté déclenche l'ouverture d'un shell root depuis la machine compromise vers l'infrastructure C2, sans aucun processus d'écoute visible sur les ports locaux. Le trigger réseau est invisible des outils de monitoring classiques.

TripleCross (2022) est un rootkit eBPF académique complet : persistance noyau, backdoor réseau, hijacking de processus légitimes pour injection de code, mécanismes anti-analyse. Il démontre la maturité de la plateforme eBPF pour un usage offensif avancé accessible à un développeur noyau Linux de niveau intermédiaire.

Atomic Arch (juin 2026) marque le tournant : c'est la première fois qu'un rootkit eBPF est déployé à grande échelle via une attaque supply chain sur un gestionnaire de packages public. Les 408 packages AUR compromis représentent une surface de distribution massive et opérationnelle. La nouveauté n'est pas la technologie eBPF — connue depuis des années — mais son industrialisation dans une chaîne d'attaque automatisée ciblant les développeurs à grande échelle.

La progression de Pamspy (2022) à Atomic Arch (2026) suit exactement le cycle de maturité observé pour les autres techniques offensives : recherche académique → preuve de concept → intégration dans des frameworks → déploiement opérationnel en campagne. Nous sommes désormais à l'étape d'industrialisation.

Ce que vos EDR et outils traditionnels ne voient pas

C'est le point central, et il faut être direct : la majorité des EDR du marché présentent des angles morts significatifs face aux rootkits eBPF. Voici pourquoi.

Les EDR basés sur ptrace sont hookables. De nombreux agents EDR instrumentent les processus surveillés via ptrace ou en injectant des bibliothèques dans l'espace utilisateur. Un rootkit eBPF opérant au niveau noyau peut intercepter les appels ptrace et filtrer ce que l'agent voit — trompant l'EDR depuis un niveau hiérarchiquement inférieur dans la pile système.

LD_PRELOAD est inutile. La technique classique d'interception libc via LD_PRELOAD est complètement inefficace contre eBPF : les hooks opèrent au niveau des syscalls noyau, avant même que la libc ne soit invoquée.

Les signatures sont inefficaces. Un programme eBPF est compilé en bytecode spécifique par le JIT compiler noyau au moment du chargement. Il n'existe pas de signature statique universelle — chaque payload peut varier structurellement sans changer ses capacités fonctionnelles.

Les logs système peuvent être filtrés. Un rootkit eBPF peut hooker les syscalls d'écriture dans les fichiers de logs pour filtrer les entrées qui le concernent avant qu'elles ne soient écrites sur disque. Votre SIEM reçoit des logs propres — expurgés des traces de l'attaquant.

Les outils réseau mentent. ss, netstat, lsof -i lisent /proc/net/tcp et /proc/net/tcp6. Un hook ciblant ces fichiers proc supprime les lignes correspondant aux connexions C2. Le SOC ne voit aucune connexion sortante anormale.

La conclusion est inconfortable : si vous n'avez pas de solution de détection eBPF-aware déployée sur vos systèmes Linux, vous êtes aveugle face à cette classe d'attaques. Les audits et pentests classiques ne la détectent pas non plus — la grande majorité des pentesters n'incluent pas de scénarios eBPF dans leurs engagements standard.

Les vraies défenses — ce qui fonctionne réellement

Des défenses efficaces existent. Elles nécessitent d'être déployées proactivement — après compromission, la détection est beaucoup plus difficile.

Tetragon (Cilium/CNCF) est la solution la plus avancée disponible en open source. L'ironie est totale : Tetragon utilise lui-même eBPF pour monitorer ce qui se passe dans le noyau, y compris les chargements de programmes eBPF. Il peut détecter le chargement de programmes eBPF non autorisés, tracer les appels syscall en temps réel avec le contexte complet (processus, user, namespace réseau), et appliquer des politiques de sécurité via des enforcement hooks eBPF LSM. Disponible en DaemonSet Kubernetes ou agent standalone, Tetragon est aujourd'hui le standard de facto pour la détection des menaces kernel-level sur Linux.

Falco (CNCF) avec son driver eBPF permet une détection comportementale des activités suspectes au niveau syscall. Des règles Falco peuvent alerter sur : le chargement de programmes eBPF depuis des processus non whitelistés, l'exécution de bpftool, la modification de fichiers dans /sys/fs/bpf/. Falco s'intègre nativement dans les écosystèmes Kubernetes via des Helm charts maintenus.

Audit régulier des programmes eBPF chargés via sudo bpftool prog list doit être une vérification de routine. Sur un système propre, vous devriez connaître exactement quels programmes eBPF sont chargés et par quel processus. Tout programme non attendu déclenche une investigation. Automatisez cette vérification dans vos scripts de conformité.

Restriction de CAP_BPF. Depuis Linux 5.8, CAP_BPF est une capacité distincte de CAP_SYS_ADMIN. Appliquez le principe de moindre privilège : seuls les processus qui ont explicitement besoin de charger des programmes eBPF doivent posséder cette capacité. Dans Kubernetes, vérifiez que vos PodSecurityAdmission policies n'accordent pas CAP_BPF ni CAP_SYS_ADMIN aux pods applicatifs standard.

kernel.unprivileged_bpf_disabled=1 désactive l'utilisation d'eBPF par les utilisateurs non privilégiés. Activée par défaut sur Ubuntu 20.04+ et Debian 11+, cette sysctl doit être vérifiée et enforced dans votre configuration de durcissement pour toutes les distributions en production.

Collecte de logs vers un SIEM externe dès le démarrage. Un rootkit eBPF peut filtrer les logs localement avant écriture sur disque. La parade : exfiltrer les logs vers un collecteur externe dès le boot du système, avant que tout rootkit ne soit chargé. Les logs déjà envoyés ne peuvent plus être filtrés a posteriori.

BPF LSM et whitelist eBPF. Depuis Linux 5.7, il est possible d'écrire des politiques de sécurité en eBPF via les programmes LSM. Tetragon exploite ce mécanisme pour implémenter des politiques d'enforcement permettant uniquement les programmes eBPF issus de processus whitelistés. C'est la défense la plus granulaire disponible.

Révision de la politique de gestion des packages tiers. La leçon d'Atomic Arch dépasse Arch Linux : toute installation de package depuis une source communautaire non officielle (AUR, Flatpak non officiel, npm, PyPI) doit être traitée comme un vecteur d'attaque potentiel sur des postes accédant à des secrets d'entreprise ou à des environnements de production.

Conclusion

eBPF est une technologie remarquable qui a transformé l'observabilité et les performances réseau sous Linux. Elle est aussi en train de transformer le paysage offensif — Atomic Arch en est la démonstration la plus récente et la plus tangible. Le défi pour les équipes de sécurité est de ne pas tomber dans le piège du déni : « nous n'avons pas de serveurs Arch Linux » est une réponse insuffisante. La technologie eBPF est disponible sur toutes les distributions Linux avec un noyau 4.18+. Les mêmes techniques — interception PAM, masquage de processus, persistance bpffs — fonctionnent sur Ubuntu, Red Hat, Debian, ou Alpine.

La question n'est plus de savoir si vos environnements Linux seront ciblés par des techniques eBPF — les cibles à haute valeur (développeurs, serveurs CI/CD, infrastructures cloud) le sont déjà. La question est de savoir si vous avez la visibilité pour le détecter. Tetragon, Falco, l'audit des programmes eBPF chargés, la restriction de CAP_BPF, la collecte de logs vers un SIEM externe — ces mesures font partie du socle défensif Linux pour 2026. Pas dans six mois : maintenant.