LinkPro Linux Rootkit

Ein kürzlich erfolgter Angriff auf eine Amazon Web Services (AWS)-Umgebung brachte ein bislang undokumentiertes GNU/Linux-Rootkit mit dem Namen LinkPro ans Licht. Diese Hintertür zeichnet sich durch die doppelte Nutzung von eBPF-Modulen aus: Ein Modul dient zum Verbergen von Artefakten, ein weiteres fungiert als versteckter Trigger – ein sogenannter „Knock“, der die Remote-Befehlsfunktion erst nach dem Erkennen eines speziell manipulierten TCP-Pakets aktiviert. Die Angriffskette und die Mechanismen des Rootkits zeugen von einem raffinierten Angreifer, der Container-Missbrauch, Verschleierung auf Kernel-Ebene und flexible Netzwerkaktivierung kombiniert, um Erkennung und forensische Korrelation zu verhindern.

Infektionsvektor und Ersteinsatz

Der Angriff begann mit der Ausnutzung einer exponierten Jenkins-Instanz, die anfällig für CVE-2024-23897 (CVSS 9.8) war. Von diesem Angriffspunkt aus schleusten die Angreifer ein bösartiges Docker-Image (kvlnt/vv, inzwischen aus Docker Hub entfernt) in mehrere Kubernetes-Cluster ein. Das Image basierte auf Kali Linux und enthielt einen kleinen Anwendungsordner, der Persistenz, Fernzugriff und einen gestaffelten Backdoor-Download ermöglichen sollte.

Im Inneren des bösartigen Docker-Image

Der App-Ordner des Bildes enthielt drei Schlüsseldateien mit unterschiedlichen Rollen:

start.sh – ein Shell-Skript, das einen SSH-Dienst startet und die anderen beiden Komponenten ausführt.

Link – ein Open-Source-Programm (vnt), das als VPN-/Proxy-Client kompiliert/gepackt wurde und ausgehende Verbindungen zu vnt.wherewego[.]top:29872 herstellt. Dadurch kann der Angreifer den kompromittierten Host von überall aus erreichen und über ihn andere Ziele angreifen.

App – ein Rust-basierter Downloader (als vGet bezeichnet), der eine verschlüsselte vShell-Nutzlast aus einem S3-Bucket abruft und dann eine WebSocket-Verbindung zu seinem Command-and-Control-Server (C2) unter 56.155.98[.]37 herstellt.

Zusätzliche Nutzlasten an Kubernetes-Knoten geliefert

Neben dem Schadimage platzierten die Betreiber zwei weitere Komponenten auf den Knoten: einen Dropper, der eine weitere vShell-Backdoor installiert, und LinkPro, ein in Golang geschriebenes Rootkit. LinkPro läuft je nach Konfiguration in einem von zwei Modi – passiv (rückwärts) oder aktiv (vorwärts). Im passiven Modus wartet es auf die Aktivierung durch ein spezielles Netzwerkpaket; im aktiven Modus stellt es selbst Kontakt zum C2 her. Der Vorwärtsmodus unterstützt fünf Transportprotokolle (HTTP, WebSocket, UDP, TCP, DNS), während der Rückwärtsmodus die Kommunikation auf HTTP beschränkt.

Wie LinkPro bestehen bleibt

Das allgemeine Ausführungs- und Persistenzverhalten der Malware folgt einer klaren Abfolge:

• Installieren Sie das Modul „Hide eBPF“. Dieses Modul enthält die eBPF-Programme Tracepoint und Kretprobe, mit denen die Prozesse und Netzwerkaktivitäten von LinkPro verborgen werden.
• Wenn die Installation des Moduls „eBPF ausblenden“ fehlschlägt oder es deaktiviert wurde, installieren Sie eine gemeinsam genutzte Bibliothek unter /etc/libld.so und fügen Sie diesen Pfad als Fallback-Mechanismus zum Ausblenden zu /etc/ld.so.preload hinzu.
• Für den umgekehrten (passiven) Betrieb installieren Sie das Knock eBPF-Modul. Knock enthält ein XDP-Programm und ein TC-Programm, sodass der C2-Kanal erst nach dem Empfang eines bestimmten „Magic Packet“ aktiv wird.
• Stellen Sie Persistenz her, indem Sie einen systemd-Dienst erstellen.
• Führen Sie vom C2 empfangene Befehle aus.
• Deinstallieren Sie beim Herunterfahren oder bei einem Signal (SIGHUP, SIGINT, SIGTERM) die eBPF-Module und entfernen/wiederherstellen Sie die Vorladeänderung von /etc/libld.so, damit das System in seinen vorherigen Zustand zurückkehrt.

Das Magic Packet und der Klopfaktivierungsmechanismus

Die passive Aktivierung von LinkPro hängt von einem bestimmten TCP-Paket ab: Jedes TCP-Paket mit einer Fenstergröße von 54321 wird als „magisches Paket“ behandelt. Sobald Knock dieses Paket erkennt, speichert es die Quell-IP und versieht es mit einer Ablaufzeit von einer Stunde. Nachfolgende TCP-Pakete von dieser Quelle werden überwacht, und Knock schreibt gegebenenfalls die Header um, sodass der Datenverkehr des Betreibers auf den Abhörport von LinkPro (2333) umgeleitet wird. Ausgehende Pakete werden angepasst, um dem Netzwerk den ursprünglichen Port wieder anzuzeigen (Quellport wird auf 2233 umgeschrieben). Die Absicht ist einfach, aber effektiv: Dem Angreifer soll ermöglicht werden, LinkPro über jeden von der Front-End-Firewall zugelassenen Port zu erreichen, während gleichzeitig die Korrelation externer Firewall-Protokolle mit der internen Netzwerkaktivität des Hosts erschwert wird.

Wie sich LinkPro verbirgt

LinkPro verwendet eine zweistufige Verschleierungsstrategie:

Kernel/eBPF-Verbergen : Das Modul „eBPF verbergen“ installiert Tracepoint- und Kretprobe-Programme, die Systemaufrufe wie getdents (zum Verbergen von Dateien/Verzeichnissen) und sys_bpf (zum Verbergen eigener BPF-Programme) abfangen. Dieser Ansatz erfordert einen Kernel mit aktiviertem CONFIG_BPF_KPROBE_OVERRIDE.

LD_PRELOAD-Fallback im Benutzerbereich : Wenn die Kernel-Fähigkeit nicht vorhanden ist, schreibt LinkPro eine gemeinsam genutzte Bibliothek (libld.so) und platziert ihren Pfad in /etc/ld.so.preload. Da /etc/ld.so.preload bewirkt, dass die angegebene Bibliothek in jeden dynamisch verknüpften Prozess (die /lib/ld-linux.so und glibc verwenden) geladen wird, bindet die implantierte libld.so libc-Funktionen frühzeitig ein (vor dem eigenen Verhalten von glibc) und ändert die Rückgabewerte von libc-Aufrufen, um Artefakte zu verbergen, die andernfalls ihre Anwesenheit verraten würden.

Rootkit-Funktionen und Befehlssatz

LinkPro unterstützt sowohl interaktive als auch automatisierte Remote-Aktionen. Zu den implementierten Funktionen gehören:

• Starten eines /bin/bash-Pseudoterminals und Ausführen interaktiver Shell-Sitzungen.
• Ausführen beliebiger Shell-Befehle.
• Auflisten von Dateien und Verzeichnissen und Ausführen von Dateivorgängen.
• Herunterladen und Schreiben von Dateien auf die Festplatte.
• Einrichten eines SOCKS5-Proxy-Tunnels für Pivoting und Living-Off-the-Land-Proxying.

Netzwerkprotokollunterstützung und C2-Verhalten

Im aktiven (Vorwärts-)Modus ist LinkPro flexibel: Es kann über HTTP, WebSocket, UDP, TCP oder DNS kommunizieren. Im passiven (Rückwärts-)Modus ist die Kommunikation auf HTTP beschränkt, profitiert aber von der Tarnung, da LinkPro erst lauscht, nachdem das Knock Magic Packet ein temporäres einstündiges Befehlsfenster geöffnet hat.

Bereinigungs- und Deinstallationsverhalten

Wenn der Prozess Beendigungssignale empfängt, versucht LinkPro, Spuren zu beseitigen: Es deinstalliert installierte eBPF-Module und löscht oder stellt die Datei /etc/libld wieder her. Dabei wird sie in den vorherigen Zustand zurückversetzt, sodass das System unverändert erscheint. Diese gezielte Bereinigungsroutine deutet darauf hin, dass ein Betreiber darauf bedacht ist, die forensischen Spuren langfristig zu minimieren.

Betriebskontext und Zuordnung

Die Kampagne nutzte einen hochgradig gefährlichen Jenkins-Exploit, bösartige Container-Images, mehrere Backdoor-Varianten und Tarnung auf Kernel-Ebene – eine Kombination, die auf einen motivierten, fähigen Betreiber hindeutet. Eine eindeutige Zuordnung wurde bisher nicht veröffentlicht; das Toolset und die offensichtliche Nutzung des Angriffs für Proxying und dauerhaften Fernzugriff deuten jedoch stark auf finanziell motivierte Aktivitäten hin (Pivoting, Proxying für weitere Angriffe oder Weiterverkauf des Zugriffs).

Kernelabhängigkeit und Fallback-Verhalten

Da LinkPro für seine verdeckte Kernel-Interception auf BPF-Kprobe-Override-Funktionen angewiesen ist, wendet es die Verbergungstechnik auf Kernel-Ebene nur an, wenn der Host-Kernel CONFIG_BPF_KPROBE_OVERRIDE verfügbar macht. Wo diese Kernel-Fähigkeit fehlt, greift LinkPro bewusst auf die Shared-Library-Methode LD_PRELOAD zurück, um sich im Benutzerbereich zu verstecken und so die Verborgenheit in einer Vielzahl von Umgebungen sicherzustellen.

Schlussbemerkung

LinkPro demonstriert, wie moderne Angriffe Containerkompromittierung, Staged Loader, Kernel-Instrumentierung (eBPF) und clevere Netzwerktricks (Aktivierung von Magic Packets und Port-Rewriting) kombinieren können, um Tarnung und Flexibilität zu gewährleisten. Erkennung und Behebung erfordern eine sorgfältige Überprüfung auf nicht autorisierte eBPF-Programme, unerwartete Einträge in /etc/ld.so.preload, ungewöhnliche systemd-Dienste und Netzwerkverbindungen zur angegebenen Infrastruktur (forensische Indikatoren sind die IP 56.155.98[.]37, die Ports 29872, 2333, 2233 und der entfernte Docker-Image-Name kvlnt/vv).