eBPF Offensif : Rootkits et Évasion Kernel-Level

L'eBPF (extended Berkeley Packet Filter) est devenu l'une des technologies les plus puissantes du noyau Linux — et l'un des vecteurs d'attaque les plus redoutables pour les acteurs offensifs. Conçu pour exécuter des programmes sandboxés dans le kernel avec des performances proches du natif, eBPF permet l'observation et la manipulation du trafic réseau, des appels système, des événements kernel et des fonctions utilisateur. Les attaquants exploitent eBPF pour créer des rootkits kernel-level quasi indétectables, contourner les EDR et solutions de sécurité, et établir des mécanismes de persistance furtifs. Ce guide technique couvre l'ensemble de l'utilisation offensive d'eBPF, depuis l'exploitation des vulnérabilités du vérificateur jusqu'au développement de rootkits eBPF, en passant par les techniques de détection et les contre-mesures. Les red teamers, les analystes SOC et les développeurs kernel trouveront ici une référence technique complète avec des exemples de code et des architectures d'attaque documentées.

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.

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 :

• 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 :

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.

FAQ — Questions Fréquentes