C2-kompilierte Kernel-Rootkits und neue Tarnmechanismen

Sysdig, der Marktführer für Echtzeit-Cloud-Sicherheit, hat VoidLink, ein in China entwickeltes Linux-Malware-Framework zur gezielten Attacke auf Cloud-Umgebungen, untersucht. Vorausgegangen war dieser technisch tiefgehenden Analyse die Aufdeckung von VoidLink durch Check Point Research am 13. Januar 2026 .

In der eigenen Analyse war es Sysdig möglich, Loader-Kette, Rootkit-Interna und Kontrollmechanismen detailliert unter die Lupe zu nehmen und zu dekonstruieren – inklusive bislang nicht dokumentierter Fähigkeiten und neuer „Indicators of Compromise“.

Kernerkenntnisse der Analyse

VoidLink fällt vor allem durch fünf Punkte auf:

• Serverside Rootkit Compilation (SRC): Der C2-Server kompiliert Kernel-Module „on demand“ für die konkrete Kernel-Version des Ziels, wodurch sich die Kernel-Portabilität praktisch unbegrenzt skalieren lässt.
• Zig als Basis: Die Dropper sind sehr klein (u. a. ein 9 KB großer Dropper im Executable and Linkable Format (ELF)) und in Zig umgesetzt. Damit ist VoidLink die erste entdeckte Chinesisch-sprachige Malware in Zig.
• Adaptive Evasion: Die Malware erkennt Security-Produkte und passt Verhalten und Beacon-Timing dynamisch an – inklusive dreifach redundanter Control Channels.
• Kernel-level Stealth: Rootkit-Mechaniken kombinieren je nach Kernel-Version eBPF und/oder Loadable Kernel Modules und setzen auf gezieltes Verbergen von Ports, PIDs, Dateien und Modulen.
• Trotzdem detektierbar via Runtime: Fileless-Execution und Syscall-/Behavior-Patterns sind für Runtime Detection (z. B. Falco, Sysdig Secure) sichtbar.

Technische Einordnung: Rootkit-Mechaniken, Steuerkanäle und Abwehrmaßnahmen

Rootkit: Stealth je nach Kernel und Kernel-Module aus dem C2

Angepasste Deployment-Strategie: Auf Kernel 6.x wird per Remote kompiliertes eBPF verwendet, auf Kernel 5.x eine Hybrid-Lösung aus eBPF und LKM und auf älteren Kerneln wird per Remote kompiliertes LKM verwendet, das via finit_module geladen wird.

Serverside Rootkit Compilation (SRC): passgenaue Module „on demand“

Anstatt Kernel-Module mitzuliefern, sendet das Implantat Kernel-Informationen (z. B. Release, zu versteckende Ports sowie Compiler-/Header-Verfügbarkeit) per POST an /compile. Es erhält ein exakt für das Ziel kompiliertes Modul (eBPF oder LKM inkl. Base64-Daten) zurück. So bleibt das Implantat klein, der Rootkit-Code kann serverseitig aktualisiert werden und die Kernel-Kompatibilität wird ohne lokale Build-Tools erreicht.

LKM-Stealth: Hooks, Tarnung und Symbol-Workarounds

Im LKM-Teil setzt das Rootkit u. a. auf Syscall- und kretprobe-Hooks (z. B. getdents/getdents64, tcp*_seq_show, netlink_recvmsg, inet_sk_diag_fill, vfs_read), um Ausgaben von ls/find/netstat/ss zu manipulieren. Zudem kann es sich aus Standardlisten entfernen (unsichtbar für /proc/modules/lsmod), sich mit MODULE_INFO(intree, „Y“) als „in-tree“ tarnen und löst Symbolzugriffe auf Kernel 5.7+ über kprobe-basierte Workarounds.

Control Channels: lokal, eBPF-Maps und ein ICMP-Covert Channel

Für die Steuerung nutzt VoidLink drei Kanäle: ein lokales prctl-Magic Interface (0x564C/„VL“) ohne Netzwerk, Updates von BPF-Maps zur dynamischen Nachpflege versteckter Ports/PIDs/Filenames sowie einen ICMP-Covert Channel über Echo-Pakete (Type 8) mit Magic ID 0xC0DE. Auffällig dabei ist ein eingebetteter Python-Control-Client direkt in der Binary, der Out-of-Band-Kontrolle ermöglicht, selbst wenn HTTP-C2 blockiert ist.

Self-Destruct: Forensik-Erschwerung auf Knopfdruck

Über einen ICMP-Befehl (0xFE) kann VoidLink eine umfassende Spurenbeseitigung auslösen: Es deaktiviert Hiding-Regeln, löscht Logs (u. a. auth/syslog/audit), entfernt Shell-Historien, bereinigt typische Artefaktpfade (/tmp, /var/tmp, /dev/shm) und löscht sich anschließend selbst per unlink(self_path).

Cloud-native Fokus: Container, Kubernetes und Cloud-Metadata

Die Malware erkennt typische Cloud-/Container-Umgebungen (z. B. Docker-Indikatoren, Kubernetes ServiceAccount Tokens sowie Cloud-Metadata-Endpunkte wie 169.254.169.254 bzw. 100.100.100.200) und bringt Plugins für Container Escape sowie Kubernetes Privilege Escalation mit, die auf häufige Fehlkonfigurationen und riskante Mounts/Privilegien abzielen.

Empfohlene Maßnahmen zum Schutz

• Runtime Detection zur Erkennung von fileless Execution und Prozess-Masquerading (z. B. memfd_create + execveat)
• Monitoring von eBPF-Ladevorgängen über den bpf-Syscall
• Audits von Kernel-Modulen außerhalb der Baseline (insbesondere bei finit_module aus temporären Verzeichnissen)
• Prüfung von ICMP-Traffic auf Anomalien (u. a. Magic ID 0xC0DE)
• Monitoring unerwarteter Zugriffe auf Cloud-Metadata
• Härtung von Container-Policies (keine privilegierten Container, Docker-Socket-Zugriff einschränken)
• Credential-Rotation bei IOC-Treffern (SSH-Keys, Cloud-Creds, Kubernetes Service Accounts).

Fazit

VoidLink stellt eine neue Qualitätsstufe bei Linux-Malware dar. Die Kombination aus einer mehrstufigen, weitgehend „dateilosen“ Infektionskette, adaptiver Erkennung von Security-Produkten und einem Rootkit, das je nach Kernel-Version unterschiedliche Stealth-Mechanismen nutzt, macht diese Bedrohung besonders schwer greifbar. Besonders hervorzuheben ist dabei die serverseitige, zielgenaue Rootkit-Kompilierung („SRC“), die die Kernel-Kompatibilität skaliert, ohne das Implantat aufzublähen oder lokale Build-Tools zu benötigen. Gleichzeitig zeigen die beschriebenen Laufzeit-Indikatoren, dass eine verhaltensbasierte Runtime-Erkennung sowie die strikte Kontrolle von eBPF- und Kernelmodul-Aktivität erforderlich sind.

Erkennung mit Sysdig Secure und Falco

Für Sysdig Secure sind bereits mehrere Regeln verfügbar, die u. a. Rootkit-Installation und fileless Malware erfassen, darunter: Fileless Malware Detected (memfd), Linux Kernel Module Injection Detected, New Kernel Module Created and Loaded, eBPF Program Loaded into Kernel sowie weitere verhaltensbasierte Signale. Für Falco  wird zudem eine Standard-Regel hervorgehoben, die fileless execution via memfd_create detektiert.