eBPF Escapes: Wenn Überwachungstools zum ultimativen Rootkit werden 🕵️

Im Jahr 2026 ist der Linux-Kernel kein statischer Türsteher mehr; er ist ein dynamischer, programmierbarer Spielplatz. Im Zentrum dieser Transformation steht eBPF (extended Berkeley Packet Filter). Früher ein einfaches Werkzeug zum Filtern von Netzwerkpaketen, hat sich eBPF zu einer “Superkraft” für cloud-native Observability, Networking und Sicherheit entwickelt. Es treibt die fortschrittlichsten Service Meshes, Hochleistungs-Firewalls und Deep-System-Monitoring an.

Doch wie das alte Sicherheitsmotto sagt: Mit großer Macht kommt große Anfälligkeit. Während legitime Tools wie Cilium, Tetragon und Pixie eBPF zum Schutz von Clustern nutzen, ist eine neue Generation von “eBPF Escapes” aufgetaucht. Im Jahr 2025 und Anfang 2026 haben Forscher einen Anstieg eBPF-basierter Rootkits beobachtet—bösartige Programme, die den eigenen “sicherheitsgeprüften” Bytecode des Kernels ausnutzen, um Dateien zu verstecken, Anmeldeinformationen zu stehlen und den Traffic nahezu unsichtbar umzuleiten.

Dieser Artikel erklärt die Mechanismen von eBPF-Rootkits, die Schwachstellen im eBPF-Verifier und wie dein vertrauenswürdigstes Überwachungstool genau das sein könnte, was dich bei einem Angriff blind macht.

1. Die Architektur der Kontrolle: Warum eBPF die perfekte Waffe ist

Um zu verstehen, wie eBPF zum Rootkit wird, muss man wissen, warum es überhaupt gebaut wurde. Traditionell erforderte das Ändern des Kernel-Verhaltens das Schreiben eines Kernel-Moduls (LKM). Das war gefährlich; ein einziger Fehler konnte das gesamte System zum Absturz bringen (ein “Kernel Panic”).

eBPF änderte das durch die Einführung einer sandboxed virtuellen Maschine im Kernel. Es ermöglicht Entwicklern:

• Code schreiben in einer eingeschränkten C-ähnlichen Sprache.
• Sicherheit verifizieren mittels eines “eBPF Verifiers”, der sicherstellt, dass der Code nicht unendlich schleift oder illegalen Speicher zugreift.
• JIT-Kompilierung des Codes in native Maschinencode für nahezu null Overhead.
• An Hooks anfügen wie syscalls, Tracepoints oder Netzwerkereignisse.

Die Perspektive des Angreifers

Für einen Angreifer ist eBPF überlegen gegenüber traditionellen Rootkits aus drei Gründen:

Persistenz ohne Neustarts: eBPF-Programme können dynamisch geladen und entladen werden.

Sicherheit vor Erkennung: Traditionelle EDR-Tools (Endpoint Detection and Response) suchen nach verdächtigen Dateien oder Prozessen. eBPF-Programme leben im Speicher des Kernels und hinterlassen oft keine Spuren auf der Festplatte.

Legitime Tarnung: Da viele Sicherheits-Tools (wie Falco oder Datadog) eBPF verwenden, kann ein bösartiges eBPF-Programm leicht im Rauschen legitimer Kernel-Probes versteckt werden.

2. Waffeneinsatz bei Hooks: Wie eBPF-Rootkits die Realität manipulieren

Ein eBPF-Rootkit zerstört das System nicht; es verzerrt seine Wahrnehmung. Durch das Anfügen an kritische Kernel-Funktionen kann ein Angreifer ändern, was das OS an den Benutzer meldet.

A. Dateien und Prozesse verstecken (Der getdents64 Hook)

Der häufigste Weg, ein Rootkit zu verstecken, ist das Hooken des sys_getdents64 syscall. Das ist die Funktion, die der Kernel nutzt, um Dateien in einem Verzeichnis aufzulisten.

Der Angriff: Wenn du ls oder ps ausführst, ruft der Kernel getdents64 auf. Ein bösartiges eBPF-Programm (angeschlossen via fexit- oder kretprobe-Hook) fängt die Dateiliste ab, bevor sie an den User-Space weitergegeben wird.

Das Ergebnis: Das eBPF-Programm scannt die Liste, erkennt Dateinamen oder Prozess-IDs (PIDs), die mit Malware in Verbindung stehen, und löscht sie aus dem Puffer. Der Benutzer sieht ein “sauberes” Verzeichnis, während die Malware weiterhin sichtbar im System läuft.

B. Netzwerk-Redirection (XDP und TC Hooks)

eBPF arbeitet auf der XDP-Ebene (eXpress Data Path)—dem niedrigsten Punkt im Netzwerk-Stack, noch vor dem Erreichen der Linux-Firewall (iptables/nftables).

Der Angriff: Rootkits wie LinkPro (entdeckt Ende 2025) nutzen XDP, um auf “Magic Packets” zu lauschen. Das sind speziell gestaltete TCP-Pakete (z.B. mit einer bestimmten Fenstergröße oder Sequenznummer), die als “Wake-on-LAN” für die Malware fungieren.

Das Ergebnis: Das Rootkit kann C2 (Command and Control)-Verkehr abfangen und die Pakete verwerfen, sodass sie nie in tcpdump oder Wireshark erscheinen. Es kann auch den Traffic an einen versteckten Proxy umleiten und Daten exfiltrieren, ohne dass der lokale Netzwerk-Stack jemals eine Verbindung bemerkt.

C. Anmeldeinformationen stehlen (Uprobes und PAM)

Angreifer können uprobes (User-level Probes) verwenden, um Funktionen in gemeinsam genutzten Bibliotheken wie libpam.so (Linux Pluggable Authentication Module) zu hooken.

Der Angriff: Tools wie Pamspy hooken die Funktion pam_get_authtok.

Das Ergebnis: Jedes Mal, wenn ein Benutzer ein Passwort für sudo, ssh oder eine lokale Anmeldung eingibt, erfasst das eBPF-Programm das Klartext-Passwort und speichert es in einer eBPF-Map (eine im Kernel befindliche Datenstruktur), um es später vom Angreifer abzurufen.

3. Das “Bouncer” umgehen: Der eBPF Verifier Bypass

Das Einzige, was zwischen einem Entwickler und einem Kernel-Fehler steht, ist der eBPF Verifier. Er ist der “Bouncer” des Kernels, der statische Analysen durchführt, um Speicher- und Sicherheitsverletzungen zu verhindern. Doch der Verifier ist eine komplexe Software, und wie alle Software hat er Bugs.

Die find_equal_scalars Schwachstelle

Im großen Sicherheitsaudit 2024 der NCC Group identifizierten Forscher Logikfehler darin, wie der Verifier “scalar”-Werte (Ganzzahlen) verfolgt.

Der Exploit: Ein Angreifer kann ein eBPF-Programm schreiben, das komplexe bitweise Operationen (AND, OR, XOR) nutzt, um den Verifier zu täuschen und ihn glauben zu lassen, eine Registervariable enthalte einen sicheren Wert (z.B. 0 bis 64), während in Wirklichkeit eine große Adresse im Speicher gespeichert ist.

Der Escape: Sobald der Verifier getäuscht wurde, produziert der JIT-Compiler Code, der es dem eBPF-Programm erlaubt, beliebigen Kernel-Speicher zu lesen und zu schreiben. Das ist der “Heilige Gral” für einen Angreifer, der ein sandboxed Programm in eine vollständige Kernel-Exploit verwandelt.

Logikfehler vs. Feature Abuse

Nicht alle eBPF Escapes erfordern eine “Schwachstelle.” Viele nutzen die eigenen Helferfunktionen des Kernels aus. Zum Beispiel ist bpf_probe_write_user eine legitime Funktion, die von Debuggern verwendet wird, um Speicher zu modifizieren. Ein Angreifer kann diese nutzen, um einen “Root”-Benutzer in den /etc/passwd-Puffer im Speicher zu injizieren, während die Datei auf der Festplatte unberührt bleibt.

4. Die Sichtbarkeitslücke: Warum traditionelle Sicherheit blind ist

Warum kann dein teures EDR-Tool diese Rootkits nicht finden? Die Antwort liegt in der Sichtbarkeitslücke.

Feature	Traditionelle Malware	eBPF Rootkit
Festplatten-Fußabdruck	Binärdateien in /usr/bin oder /tmp	Nur im Kernel-Speicher
Syscall-Logs	Sichtbar in auditd oder syslog	Hookt die Logging-Funktionen direkt
Netzwerkverkehr	Sichtbar für iptables und tcpdump	Abgefangen auf XDP/Driver-Ebene
Erkennung	Dateisignaturen/Hashes	“Signless” Bytecode-Ausführung

Im Jahr 2026 konzentrieren sich die meisten EDRs noch auf den User-Space. Sie überwachen Prozessbäume und Dateimodifikationen. Ein eBPF-Rootkit ist jedoch ein “Gespenst in der Maschine.” Es erstellt keinen neuen Prozess; es ändert nur das Verhalten bestehender Prozesse.

Wenn du den Kernel fragst: “Gibt es einen Prozess namens ‘backdoor’?”, sagt der Kernel (der jetzt unter Kontrolle des Rootkits steht) einfach: “Nein.”

5. Fallstudie: Der LinkPro-Ausbruch 2025

Das bisher ausgeklügeltste Beispiel für einen eBPF-Exit ist LinkPro, ein Rootkit, das im Oktober 2025 entdeckt wurde und auf AWS-gehostete Kubernetes-Cluster abzielt.

Erster Zugriff: Angreifer nutzten eine Schwachstelle in einem Jenkins-Server (CVE-2024-23897), um initialen Zugang zu erlangen.

Bereitstellung: Statt einer Standard-Shell setzten sie ein bösartiges Docker-Image mit eBPF-Modulen ein.

Kernel-Hooking: LinkPro lud zwei Module. Eines hookte sys_bpf—den syscall, der zum Laden anderer eBPF-Programme verwendet wird. So konnte das Rootkit seine eigene Präsenz vor Tools wie bpftool verbergen.

Stealth-C2: Das Rootkit blieb inaktiv, bis es ein “Magic TCP SYN”-Paket mit einer bestimmten Fenstergröße (54321) erhielt. Erst dann öffnete es eine Reverse-Shell, was eine Erkennung durch Port-Scanning unmöglich machte.

LinkPro zeigte, dass eBPF nicht nur ein Werkzeug für lokale Persistenz ist; es ist ein Werkzeug für laterale Bewegungen in der Cloud.

6. Wie du dein Kernel 2026 schützen kannst

Wenn der Verifier umgangen werden kann und Hooks versteckt sind, besteht noch Hoffnung für Verteidiger? Ja, aber es erfordert einen Wandel von “Legacy Security” zu “Kernel-gestützter Sicherheit.”

1. Kernel-Konfiguration härten

Die erste Verteidigungslinie ist die Einschränkung, wer eBPF-Programme laden darf.

Deaktivieren unprivilegierter BPF: Stelle sicher, dass kernel.unprivileged_bpf_disabled = 1 gesetzt ist. Das verhindert, dass Nicht-Root-Benutzer BPF-Code laden.

Capabilities einschränken: Nutze Linux Capabilities, um sicherzustellen, dass nur bestimmte Dienste (wie dein Überwachungsagent) CAP_BPF und CAP_PERFMON besitzen.

2. Laufzeit-Integritätsüberwachung (Tetragon und Tracee)

Ironischerweise ist der beste Schutz gegen ein eBPF-Rootkit, bessere eBPF-Tools. Tools wie Tetragon (von Cilium) nutzen eBPF, um den Zustand des Kernels selbst zu überwachen.

Signaturprüfung: Im Jahr 2026 setzen viele Organisationen auf signierte eBPF-Programme. Der Kernel ist so konfiguriert, dass nur BPF-Bytecode geladen wird, der kryptografisch von einer vertrauenswürdigen Stelle (z.B. dem Sicherheitsteam) signiert wurde.

BPF Type Format (BTF) Integrität: Überwachung von BPF Type Format-Daten (BTF) kann aufzeigen, wenn ein Rootkit Kernel-Strukturen modifiziert hat, um seine Maps zu verstecken.

3. Forensische Bestandsaufnahme

Sicherheitsteams sollten regelmäßig “Kernel Snapshots” durchführen.

bpftool: Nutze bpftool prog show, um alle geladenen Programme aufzulisten. Wenn Programme ohne Namen oder PID vorhanden sind, sofort untersuchen.

Memory Forensics: In hochsicheren Umgebungen kann eine Speicheranalyse auf Hypervisor-Ebene (mit Tools wie Volatility 3) eBPF-Programme erkennen, die sys_bpf hooken, um sich vor bpftool zu verstecken.

4. Auf “Magic Packets” achten

Moderne Firewalls sollten so konfiguriert sein, dass sie nach “Anomalous Header Values” suchen. eBPF-Rootkits verwenden oft nicht-standard TCP-Flags oder Fenstergrößen zur Aktivierung. Verhaltensbasierte KI in Firewalls des Jahres 2026 ist speziell darauf abgestimmt, diese “niedrigfrequenten, hochabsichtlichen” Pakete zu erkennen.

7. Fazit: Die doppelte Nutzung moderner Kernel-Technologie

Mit Blick auf 2026 wird der Kampf um den Linux-Kernel nur intensiver. eBPF ist eine klassische “Dual-Use”-Technologie—ein Durchbruch für Performance und Observability, der sich gleichzeitig als ultimatives Werkzeug für hochentwickelte Akteure entpuppt.

Für Organisationen ist die Botschaft klar: Du kannst nur vertrauen, was du verifizieren kannst. Wenn du eBPF für Monitoring und Sicherheit nutzt, musst du auch das eBPF-Subsystem selbst sichern. Das Werkzeug, das dir “Röntgenblick” in deine Container gibt, kann, wenn es kompromittiert wird, zur Blindfold werden, das einen Räuber in deinem Kern versteckt.

Ist dein Kernel programmierbar? Ja. Aber die Frage ist: Wer programmiert?