Sysdig 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“.
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 KByte 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.
Info: Weitere Details finden sich hier: https://www.sysdig.com/blog/voidlink-threat-analysis-sysdig-discovers-c2-compiled-kernel-rootkits
#Sysdig
