eBPF-Rootkit unter Linux: DB-Leck über Auftragnehmer

eBPF-Rootkit über Auftragnehmer: Versteckte Datenbanklecks in Linux aufdecken

Ein Datenbankserver unter Ubuntu erzeugte einen Monat lang 5–10 % mehr ausgehenden als eingehenden Datenverkehr. Logs und Prozesse schienen sauber, und der Provider bestätigte normalen Netzwerkbetrieb. Eine Prüfung ergab ein eBPF-Rootkit, das über einen kompromittierten Laptop eines DBA-Auftragnehmers eingeschleust wurde. Angreifer nutzten die Lieferkette, um ein Programm zu installieren, das Prozesse verbarg und personenbezogene Daten an einen C2-Server exfiltrierte.

Erster Hinweis: Verdächtige iptables-Regel

In /etc/iptables/rules.v4 tauchte eine Regel auf, die ausgehende TCP-Verbindungen zu einer IP aus dem VPN-Pool des Auftragnehmers erlaubte:

-A OUTPUT -d xxx.xxx.xxx.xxx -p tcp --dport YYYY -j ACCEPT

Diese Regel gehörte nicht zur Grundkonfiguration. Sie ermöglichte die heimliche Übertragung komprimierter Datenbanktabellen-Dumps. Eine Analyse von /var/log/auth.log zeigte SSH-Key-Logins vom Auftragnehmer mit einer IP aus demselben Pool. Der Serverzugriff wurde nach der Arbeit widerrufen, aber das VPN blieb aktiv.

Diskrepanz in /proc deutete auf Rootkit hin

Der Befehl ps auxf zeigte Standardprozesse, aber die Anzahl der Verzeichnisse in /proc übertraf die PID-Anzahl um eins. Dies deutete auf eine Abfangung der Systemaufrufe getdents und getdents64 hin. Die Überprüfung von /proc/modules und die Analyse des Kernelspeichers mit einer LiveCD ergab keine LKM-Module – die Liste stimmte mit der Basislinie überein.

eBPF als Rootkit-Grundlage: Implementierungsdetails

Das Utility bpftool offenbarte eBPF-Programme, die an Kprobe-Punkten __x64_sys_getdents und __x64_sys_kill angehängt waren. Ein zusätzliches Socket-Programm leitete Datenverkehr um. In /usr/share/man/man3/ wurde eine Binärdatei namens systemd-snoop gefunden, die eBPF über libbpf lädt.

Die Malware speicherte nachts PII-Tabellen, komprimierte sie und sendete sie an den C2-Server. eBPF ist in der Modulliste nicht sichtbar, da es über den bpf()-Systemaufruf geladen wird. Die Erkennung erfordert Root-Rechte für bpftool oder Kernel-Speicheranalyse. In diesem Fall waren die Objekte nicht versteckt.

Angriffsszenario

• Laptop des Auftragnehmers kompromittiert.
• Während geplanter Arbeit über SSH-Key – Login auf den Server.
• Hinzufügen der iptables-Regel und Installation von systemd-snoop.
• Nächtliche Datenexfiltration über eBPF-Proxy.

Methoden zur Erkennung von eBPF-Rootkits

Standard-AIDE ist wirkungslos – eBPF modifiziert keine Dateien in /lib/modules. Empfohlene Ansätze:

• Regelmäßige Erfassung von bpftool prog list und bpftool map list mit Weiterleitung an SIEM.
• Audit des bpf()-Systemaufrufs über auditd oder ebpf_exporter.
• Überwachung mit Falco, Tracee oder Osquery auf anomale eBPF-Aktivität.
• Analyse von NetFlow auf Verkehrsdiskrepanzen und Korrelation mit GeoIP.

Schutz der Lieferkette vor Auftragnehmern

Authentifizierung und Zugriff

• Obligatorische 2FA für SSH auch mit Keys.
• Minimale Berechtigungen: kein Root-Zugriff, nur über Bastion-Host mit Sitzungsprotokollierung.
• Key-Rotation alle 6 Monate, Widerruf innerhalb von 24 Stunden nach Beendigung.
• Temporäre VPN-Sitzungen mit automatischer Trennung.

Infrastruktur

• GitOps für Firewall: iptables-Änderungen nur über Ansible mit Git-Kontrolle.
• Zentralisiertes ELK/Graylog + SIEM zur Korrelation von Logs, NetFlow und GeoIP.

Wichtige Erkenntnisse

• eBPF-Rootkits verbergen Prozesse, sind in /proc/modules nicht sichtbar und werden über bpftool erkannt.
• Angriff über Auftragnehmer: Laptop-Kompromittierung + verbleibender VPN-Zugriff.
• Symptome: Verkehrsasymmetrie, PID-Diskrepanz in /proc.
• Schutz: 2FA, Bastion-Host, bpf()-Audit, NetFlow-Überwachung.
• Tools: Falco, Tracee, ebpf_exporter zur Laufzeiterkennung.

Dieser Fall zeigt, wie eine geringfügige Verkehrsanomalie eine einjährige Datenexfiltration aufdeckte. Die Implementierung proaktiver eBPF-Überwachung und strenger Zugangskontrollen minimiert Risiken durch externe Teams.

— Editorial Team