L'eBPF (extended Berkeley Packet Filter) s'est imposé comme l'une des technologies les plus puissantes du noyau Linux — et, entre les mains d'acteurs offensifs, comme l'un des vecteurs d'attaque les plus redoutables. Conçu pour exécuter des programmes sandboxés dans le kernel avec des performances proches du natif, eBPF offre une visibilité et une capacité de manipulation inédites sur le trafic réseau, les appels système et les événements du noyau. Ces mêmes primitives — kprobes, tracepoints, filtres XDP — permettent de masquer des processus, d'intercepter des identifiants ou de détourner des connexions sans charger le moindre module noyau classique. La thématique ebpf offensif rootkit kernel concentre aujourd'hui l'attention des équipes de sécurité : les implants basés sur eBPF échappent aux contrôles traditionnels tout en restant partiellement détectables. Cet article détaille leurs techniques, leurs limites et les stratégies de détection kernel-level applicables en production.

En bref

  • eBPF permet des rootkits kernel-level sans module kernel — plus portables et plus furtifs que les LKM
  • Les rootkits eBPF dissimulent processus, fichiers, connexions réseau et interceptent les credentials
  • Les EDR basés sur eBPF peuvent être contournés par des programmes eBPF à priorité plus élevée
  • Le vérificateur eBPF a un historique de vulnérabilités permettant l'accès kernel arbitraire
  • La détection passe par l'audit de bpf() syscall, l'inspection des programmes et maps, et le monitoring continu

En bref

  • Architecture eBPF : programmes, maps, vérificateur, helpers et hooks
  • Rootkits eBPF : dissimulation de processus, fichiers, connexions réseau et users
  • Évasion EDR : manipulation des événements de télémétrie via eBPF
  • Vulnérabilités du vérificateur : bypass des bornes, type confusion, speculative attacks
  • Détection : audit des programmes eBPF chargés, signatures et monitoring
eBPF (extended Berkeley Packet Filter) — Technologie du noyau Linux permettant d'exécuter des programmes sandboxés dans le kernel sans modifier le code source ni charger de modules. Les programmes eBPF sont vérifiés statiquement avant exécution pour garantir la terminaison et la sûreté mémoire, mais des vulnérabilités dans le vérificateur permettent parfois le bypass de ces garanties.

Architecture eBPF : Vue d'Ensemble

eBPF est une machine virtuelle dans le kernel Linux qui exécute un bytecode vérifié. Les programmes eBPF sont attachés à des hooks (points d'attachement) dans le kernel — syscalls, tracepoints, kprobes, uprobes, XDP (réseau), LSM (sécurité). Ils utilisent des maps (structures de données partagées) pour communiquer entre eux et avec l'espace utilisateur.

ComposantRôleUsage offensif
ProgrammesBytecode eBPF exécuté dans le kernelInterception et modification de données
MapsStockage clé-valeur partagéConfiguration du rootkit, exfiltration
VérificateurAnalyse statique pré-exécutionCible de bypass pour accès kernel arbitraire
HelpersFonctions kernel accessibles depuis eBPFbpf_probe_read_kernel, bpf_override_return
Hooks (kprobes)Points d'attachement dynamiquesInterception de n'importe quelle fonction kernel

Rootkits eBPF : Principes et Architecture

Un rootkit eBPF exploite les capacités légitimes d'eBPF pour dissimuler la présence d'un attaquant. Contrairement aux rootkits kernel classiques (LKM — Loadable Kernel Module), les rootkits eBPF :

⚡

Retour terrain

Dans mes missions de red team, la phase de post-exploitation révèle systématiquement des données que le client pensait protégées. Le cas le plus fréquent : des fichiers Excel de comptabilité ou RH stockés sur des partages réseau accessibles à tous les utilisateurs du domaine, sans restriction. Sur les 30 dernières missions, 27 avaient des partages réseau avec des données sensibles accessibles à n'importe quel utilisateur authentifié. La sensibilité des données n'est pas corrélée à leur niveau de protection réel.

  • Ne nécessitent pas de compiler un module kernel — pas de dépendance aux headers kernel
  • Sont portables entre les versions de kernel (grâce au BTF — BPF Type Format)
  • Ne déclenchent pas les alertes de module loading (pas de insmod)
  • Sont plus difficiles à détecter car eBPF est un composant légitime et largement utilisé
  • Peuvent être déployés par un processus avec CAP_BPF + CAP_PERFMON (pas nécessairement root sur les kernels récents)

Dissimulation de Processus via eBPF

La technique consiste à intercepter les appels système getdents64() (utilisé par ls, ps, find) via un programme eBPF de type tracepoint ou fentry. Le programme modifie le buffer de retour pour supprimer les entrées correspondant aux processus à dissimuler :

// Programme eBPF de dissimulation de processus (simplifié)
SEC("tp/syscalls/sys_exit_getdents64")
int handle_getdents_exit(struct trace_event_raw_sys_exit *ctx) {
 // Lire le buffer de retour du syscall getdents64
 struct linux_dirent64 *dirp;
 long ret = ctx->ret;
 
 // Parcourir les entrées du répertoire (/proc/PID)
 // Si le nom correspond au PID à cacher :
 // → Décaler les entrées suivantes pour "supprimer" l'entrée
 // → Décrémenter ret (nombre d'octets retournés)
 
 // Le processus n'apparaît plus dans ps, top, /proc
 return 0;
}

// Programme de dissimulation de fichiers
SEC("tp/syscalls/sys_exit_getdents64")
int hide_files(struct trace_event_raw_sys_exit *ctx) {
 // Même technique pour cacher des fichiers dans un répertoire
 // Filtrer par nom de fichier (e.g., ".backdoor", "rootkit.so")
 return 0;
}

Dissimulation de Connexions Réseau

Les connexions réseau du rootkit (C2, reverse shell) sont dissimulées en interceptant la lecture de /proc/net/tcp et /proc/net/tcp6. Un programme eBPF de type fentry attaché à tcp4_seq_show supprime les lignes correspondant aux connexions à cacher. Le résultat : netstat, ss, et lsof ne montrent pas les connexions du rootkit.

Interception de Credentials via eBPF

// Keylogger eBPF via interception de read() sur /dev/tty
SEC("tp/syscalls/sys_exit_read")
int sniff_tty_read(struct trace_event_raw_sys_exit *ctx) {
 // Si le FD correspond à un terminal (stdin, /dev/tty)
 // Lire le buffer de retour (les caractères saisis)
 // Envoyer vers une map perf_event pour exfiltration
 
 char buf[256];
 bpf_probe_read_user(buf, sizeof(buf), (void *)ctx->ret);
 bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, buf, sizeof(buf));
 return 0;
}

// Interception de sudo/su pour capturer les mots de passe
SEC("uprobe//usr/bin/sudo")
int sniff_sudo(struct pt_regs *ctx) {
 // Lire les arguments de la ligne de commande
 // Capturer la saisie du mot de passe via PAM hooks
 return 0;
}

Évasion EDR via eBPF

Les EDR modernes (CrowdStrike Falcon, SentinelOne, Elastic) utilisent eux-mêmes eBPF pour la télémétrie de sécurité. Un rootkit eBPF peut contourner ces EDR en :

  • Patching des programmes eBPF de l'EDR : détacher ou remplacer les programmes eBPF de l'EDR par des versions modifiées qui filtrent les événements malveillants
  • Manipulation des événements en amont : les programmes eBPF s'exécutent en chaîne — un programme attaché avec une priorité plus élevée peut modifier les données avant que l'EDR ne les voie
  • Blocking des perf events : empêcher la transmission des événements de télémétrie à l'agent EDR en espace utilisateur
  • bpf_override_return() : sur les kernels avec CONFIG_BPF_KPROBE_OVERRIDE, cette helper permet de modifier la valeur de retour d'une fonction kernel — un attaquant peut faire échouer silencieusement les checks de sécurité

Vulnérabilités du Vérificateur eBPF

Le vérificateur eBPF est la première ligne de défense : il analyse statiquement chaque programme avant exécution pour garantir la terminaison, la sûreté mémoire et le respect des contraintes. Mais le vérificateur est un logiciel complexe (~20 000 lignes de C) avec un historique de vulnérabilités :

CVETypeImpactKernel
CVE-2021-3490Bounds tracking (ALU32)OOB R/W kernel5.7-5.12
CVE-2023-2163Verifier bypass (branch pruning)Arbitrary R/W5.4-6.3
CVE-2022-23222Type confusion (PTR_TO_MEM)LPE5.8-5.16
CVE-2021-34866Ringbuf boundsOOB access5.8-5.14

Détection des Rootkits eBPF

La détection des programmes eBPF malveillants est un défi car eBPF est une technologie légitime. Les approches de détection :

  • Audit des programmes chargés : bpftool prog list affiche tous les programmes eBPF actifs. Un rootkit qui n'apparaît pas dans cette liste est suspect (dissimulation de la commande bpf()).
  • Monitoring de bpf() syscall : surveiller les appels à bpf(BPF_PROG_LOAD) avec les arguments (type de programme, hooks ciblés) via auditd ou un programme eBPF de surveillance.
  • Analyse des maps eBPF : les maps contiennent les données du rootkit (PIDs à cacher, ports à filtrer). L'inspection des maps peut révéler une activité malveillante.
  • Intégrité du kernel : comparer les hooks eBPF actifs avec une baseline connue. Un programme attaché à tcp4_seq_show ou getdents64 est suspect.
⚠️ Attention — Les rootkits eBPF sont particulièrement dangereux car ils opèrent au niveau kernel avec les privilèges les plus élevés, tout en utilisant une technologie légitime qui est de plus en plus déployée pour la sécurité elle-même. La frontière entre usage légitime et malveillant d'eBPF est extrêmement fine.
💡 Conseil pratique — Pour vous protéger contre les rootkits eBPF, restreignez l'accès au syscall bpf() via seccomp, désactivez unprivileged_bpf_disabled (sysctl kernel.unprivileged_bpf_disabled=1), et surveillez les programmes eBPF chargés via bpftool et les audit logs.

À retenir

  • eBPF permet des rootkits kernel-level sans module kernel — plus portables et plus furtifs que les LKM
  • Les rootkits eBPF dissimulent processus, fichiers, connexions réseau et interceptent les credentials
  • Les EDR basés sur eBPF peuvent être contournés par des programmes eBPF à priorité plus élevée
  • Le vérificateur eBPF a un historique de vulnérabilités permettant l'accès kernel arbitraire
  • La détection passe par l'audit de bpf() syscall, l'inspection des programmes et maps, et le monitoring continu

FAQ — Questions Fréquentes

eBPF nécessite-t-il les droits root ?

Historiquement oui, mais les kernels récents permettent le chargement de certains types de programmes eBPF avec les capabilities CAP_BPF et CAP_PERFMON (sans root complet). Le sysctl kernel.unprivileged_bpf_disabled contrôle si les utilisateurs non privilégiés peuvent charger des programmes eBPF (désactivé par défaut sur la plupart des distributions).

Un antivirus peut-il détecter un rootkit eBPF ?

Les antivirus traditionnels (basés sur les signatures fichiers) ne détectent pas les rootkits eBPF car le bytecode est chargé en mémoire via le syscall bpf(). Les EDR avancés surveillent les appels bpf() et analysent les programmes chargés, mais un rootkit eBPF peut potentiellement intercepter et modifier cette télémétrie.

Quelle est la différence entre un rootkit eBPF et un rootkit LKM ?

Un rootkit LKM est un module kernel compilé (.ko) qui nécessite les headers kernel et déclenche des alertes de module loading. Un rootkit eBPF utilise le bytecode eBPF, est portable entre versions kernel (BTF), ne nécessite pas de compilation kernel, et utilise une interface légitime. L'eBPF est cependant plus limité (pas d'accès mémoire arbitraire sans vulnérabilité du vérificateur).

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Besoin d'un accompagnement expert ?

Nos consultants spécialisés en sécurité kernel et détection avancée vous accompagnent dans l'évaluation de votre posture de sécurité.

Contactez-nous
Article recommandé : DMA Attacks : Exploitation Thunderbolt, PCIe et FireWire

📚 Articles connexes

🔗 Références externes

Ayi NEDJIMI

Testez vos défenses avant les attaquants

Pentest, Red Team, audit de sécurité — rapport détaillé avec plan de remédiation priorisé.

Environnement de test et laboratoire pratique

La maîtrise des techniques de sécurité offensive et défensive requiert un environnement de pratique dédié. L'installation d'un laboratoire virtuel sur votre poste (VMware Workstation, VirtualBox, ou Proxmox pour une infrastructure plus élaborée) permet de tester les concepts présentés dans cet article sans risque pour les systèmes de production.

Configuration recommandée du lab

Pour reproduire les scénarios décrits, une configuration minimale comprend : un hyperviseur disposant d'au moins 16 Go de RAM et 4 cœurs CPU, un réseau virtuel isolé (host-only ou internal network sans accès Internet pour les VMs malveillantes), et un snapshot de base avant chaque manipulation pour faciliter le retour arrière. Les distributions spécialisées Kali Linux (offensive) et Parrot OS Security Edition couvrent l'ensemble des outils nécessaires sans configuration manuelle. Pour l'aspect défensif, Security Onion déploie en une seule VM un stack complet (Zeek, Suricata, Elasticsearch, Kibana) qui permet de visualiser l'impact des techniques testées.

Ressources de formation complémentaires

Les plateformes d'entraînement permettent de consolider la pratique dans des environnements légaux et structurés. HackTheBox et TryHackMe proposent des machines virtuelles sur lesquelles appliquer les techniques décrites, avec des difficultés progressives adaptées aux débutants comme aux experts. Pour les scénarios d'entreprise (Active Directory, Cloud, applications web complexes), les labs Pro de HackTheBox ou les modules DFIR/SOC de Blue Team Labs Online offrent des cas réalistes. Les CTF compétitifs (Hack The Box CTF, DEFCON CTF, PicoCTF) développent la créativité et l'adaptabilité face à des challenges inédits. La régularité de pratique (1-2 heures hebdomadaires minimum) prime sur l'intensité ponctuelle pour développer des réflexes durables.

Indicateurs de maturité et métriques de sécurité

Mesurer l'efficacité des mesures de sécurité implémentées est indispensable pour justifier les investissements et guider les priorités. Les métriques suivantes constituent un tableau de bord de sécurité applicable aux organisations de toutes tailles.

Métriques de couverture et de détection

Les indicateurs clés à suivre mensuellement : taux de couverture MITRE ATT&CK (pourcentage des techniques adversariales couvertes par des règles de détection actives) ; Mean Time To Detect (MTTD) pour les incidents de sécurité confirmés ; Mean Time To Respond (MTTR) depuis l'alerte jusqu'à la résolution ; taux de faux positifs sur les alertes SIEM (objectif : moins de 5% pour les règles de haute priorité) ; pourcentage de systèmes avec agents EDR installés et actifs (objectif : 100% des endpoints gérés). Ces métriques, compilées dans un rapport mensuel pour la direction, permettent de démontrer la valeur des investissements sécurité et d'identifier les domaines nécessitant des ressources supplémentaires.

Amélioration continue par les exercices

Les organisations les plus matures en matière de cybersécurité organisent régulièrement des exercices pour tester et améliorer leurs capacités. Les exercices tabletop (simulation de crise sur table, sans activation des systèmes techniques) développent la coordination des équipes et valident les procédures de communication de crise. Les tests de pénétration (pentest) annuels fournissent une évaluation objective de la résistance technique de l'infrastructure. Les exercices Red/Blue/Purple Team (1-2 fois par an pour les organisations matures) permettent d'aligner les équipes offensive et défensive autour d'objectifs communs d'amélioration. Chaque exercice doit donner lieu à un plan d'action formalisé avec des jalons de correction mesurables, intégré dans la feuille de route sécurité de l'organisation.

Bonnes pratiques et recommandations complémentaires

Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.

Veille et mise à jour continue

La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).

Documentation et partage de connaissances

La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.

Checklist de mise en œuvre et points de contrôle

La mise en pratique des recommandations de cet article nécessite une approche structurée. Cette checklist synthétise les points de contrôle essentiels pour évaluer l'état d'avancement de votre déploiement et identifier les actions prioritaires.

Phase de préparation et d'inventaire

Avant toute action technique, constituer un inventaire précis est indispensable. Les éléments à recenser : cartographie exhaustive des actifs concernés (systèmes, applications, flux de données) avec leur criticité métier associée ; identification des propriétaires techniques et fonctionnels pour chaque actif ; évaluation du niveau de maturité actuel à partir des référentiels reconnus (CIS Controls, ISO 27001, NIST CSF) ; et documentation des dépendances entre composants pour anticiper les impacts des modifications. Un inventaire incomplet génère des angles morts qui deviennent des vecteurs d'attaque exploitables par des acteurs malveillants disposant d'informations accessibles publiquement (OSINT, Shodan, LinkedIn).

Phase de déploiement et validation

Le déploiement progressif réduit les risques d'interruption de service et facilite la détection des régressions. Adopter un modèle de déploiement par vagues (wave deployment) : d'abord les environnements de développement et de test pour valider les configurations, ensuite les systèmes non-critiques en production, enfin les systèmes critiques lors de fenêtres de maintenance planifiées. Chaque vague s'accompagne d'une validation fonctionnelle complète et d'une période d'observation des métriques de performance et de sécurité. Un plan de retour arrière documenté et testé est obligatoire avant toute opération sur un système critique. Les critères de succès doivent être définis avant le déploiement, non après — un taux de faux positifs inférieur à 5% pour les alertes de sécurité, une disponibilité maintenue au niveau SLA contractuel, et l'absence d'incidents de sécurité liés aux modifications.

Phase de supervision et d'amélioration continue

La mise en place d'indicateurs de suivi permet de mesurer l'efficacité des mesures déployées et de justifier leur maintien auprès de la direction. Tableau de bord mensuel recommandé : nombre d'alertes générées par catégorie (critique, majeur, mineur) avec tendance sur 6 mois ; taux de couverture des actifs critiques par les contrôles de sécurité ; délai moyen de remédiation des vulnérabilités par sévérité CVSS ; et résultats des tests de régression mensuels sur les règles de détection. Ce tableau de bord, présenté en comité de sécurité, constitue la base d'un dialogue constructif entre les équipes techniques et le management sur les priorités d'investissement en cybersécurité.

Ressources, outils et veille spécialisée

L'efficacité opérationnelle des équipes de sécurité repose sur la maîtrise des outils adaptés et sur une veille continue sur les évolutions techniques et réglementaires du domaine. Ce panorama recense les ressources incontournables pour approfondir les sujets abordés dans cet article.

Outils open source recommandés

L'écosystème open source de la cybersécurité offre des outils de qualité professionnelle, souvent comparables voire supérieurs aux solutions commerciales sur des cas d'usage spécifiques. Pour la détection et la réponse à incident : OSSEC/Wazuh (HIDS/XDR open source déployé sur plus de 500 000 systèmes), TheHive et Cortex (orchestration et automatisation de la réponse à incident), MISP (partage de threat intelligence, utilisé par plus de 6 000 organisations mondiales). Pour l'analyse forensique : Autopsy (interface graphique pour Sleuth Kit, analyse disque), Volatility 3 (analyse mémoire vive), YARA (création de règles de détection de malwares). Pour l'audit d'infrastructure : OpenSCAP (compliance scanning automatisé), Lynis (audit de durcissement Linux), BloodHound (cartographie des chemins d'attaque Active Directory). Ces outils, maintenus par des communautés actives et adoptés par les grandes entreprises et agences gouvernementales, constituent le socle technique des équipes SOC modernes.

Sources de veille et formation continue

La cybersécurité évolue à un rythme qui impose une veille structurée pour maintenir l'efficacité des défenses. Les sources primaires à surveiller : CERT-FR (bulletins d'alerte et de sensibilisation de l'ANSSI, à intégrer dans les flux de veille en priorité) ; NVD et CISA KEV (catalogue des CVE et des vulnérabilités activement exploitées) ; Microsoft MSRC, Google Project Zero et Cisco Talos (recherche offensive et advisories éditeurs) ; et les publications académiques des conférences SSTIC (France), USENIX Security, IEEE S&P et CCS. Pour la montée en compétences des équipes, les certifications SANS GIAC (GCIH, GPEN, GCFA) offrent le meilleur équilibre entre reconnaissance professionnelle et valeur pratique. Les plateformes d'entraînement TryHackMe et HackTheBox permettent une pratique régulière sur des scénarios réalistes sans risque légal, avec des modules spécifiques adaptés aux profils défensifs (Blue Team Labs) et offensifs (HTB Pro Labs).