Illuminating VoidLink: Technical analysis of the VoidLink rootkit framework — Elastic Security Labs

Summary

Elastic Security Labs has published an in-depth technical analysis of VoidLink, a sophisticated Linux malware framework that combines traditional Loadable Kernel Modules (LKMs) with eBPF programs to maintain kernel-level persistence. The analysis is based on a data dump containing source code, binaries, and deployment scripts attributed to a Chinese-speaking threat actor, revealing at least four distinct generations of the rootkit with evolving evasion techniques. The research confirms earlier findings by Check Point that VoidLink was developed using AI-assisted workflows, with source code containing detailed Chinese comments showing iterative development phases focused on security, stealth, compatibility, stability, and defense mechanisms.

Full text

26 March 2026•Ruben Groenewoud•Remco SprootenIlluminating VoidLink: Technical analysis of the VoidLink rootkit frameworkElastic Security Labs analyzes VoidLink, a sophisticated Linux malware framework that combines traditional Loadable Kernel Modules with eBPF to maintain persistence.22 min readMalware AnalysisIntroduction During a recent investigation, we came across a data dump containing source code, compiled binaries, and deployment scripts for the kernel rootkit components of VoidLink, a cloud-native Linux malware framework first documented by Check Point Research in January 2026. Check Point's analysis revealed VoidLink to be a sophisticated, modular command-and-control framework written in Zig, featuring cloud-environment detection, a plugin ecosystem of over 30 modules, and multiple rootkit capabilities spanning userland rootkits (LD_PRELOAD), Loadable Kernel Modules (LKMs), and eBPF. In a follow-up publication, Check Point presented compelling evidence that VoidLink was developed almost entirely through AI-assisted workflows using the TRAE integrated development environment (IDE), with a single developer producing the framework, from concept to functional implant, in under a week. The data dump we obtained, which we attribute to the same Chinese-speaking threat actor, based on matching Simplified Chinese source comments and Alibaba Cloud infrastructure, contained the raw development history of VoidLink's rootkit subsystem. What Check Point described as a deployable stealth module, selected dynamically based on the target kernel version, was laid bare in our data dump as a multigenerational rootkit framework that had been actively developed, tested, and iterated across real targets, spanning CentOS 7 through Ubuntu 22.04. The rootkit components masquerade under the module name vl_stealth (or, in some variants, amd_mem_encrypt), consistent with the kernel-level concealment capabilities described in Check Point's analysis. Their architecture immediately stood out: Rather than relying on a single technique, the rootkit combines a traditional LKM with eBPF programs in a hybrid design that we’ve rarely encountered in the wild. The LKM handles deep kernel manipulation, syscall hooking via ftrace, and an Internet Control Message Protocol–based (ICMP-based) covert command channel, while a companion eBPF program takes over the delicate task of hiding network connections from the ss utility by manipulating Netlink socket responses in userspace memory. Across the data, we identified at least four distinct generations of VoidLink, each one refining its hooking strategy, evasion techniques, and operational stability. The earliest variant targeted CentOS 7 with direct syscall table patching. The most recent variant, which the developers dubbed "Ultimate Stealth v5" in their comments, introduces delayed hook installation, anti-debugging timers, process kill protection, and XOR-obfuscated module names. Check Point's second publication already established that VoidLink was developed through AI-driven workflows. The rootkit source code we analyzed corroborates and extends this finding: The source files are littered with phased refactoring annotations, tutorial-style comments that explain basic kernel concepts, and iterative version numbering patterns that closely mirror multi-turn AI conversations. Where Check Point observed the macro-level development methodology (sprint planning, specification-driven development), our data dump reveals the micro-level reality of how individual rootkit components were iteratively prompted, tested, and refined. In this research publication, we walk through the rootkit's architecture, trace its evolution across four generations, dissect its most technically interesting features, and provide actionable detection strategies. All Chinese source comments referenced in this analysis have been translated into English. Discovery and initial triage At first glance, the sheer volume of files, many with iterative version numbers, like hide_ss_v3.bpf.c through hide_ss_v9.bpf.c, suggested an active development effort rather than a one-off project. The presence of compiled .ko files for specific kernel versions, alongside three separate copies of vmlinux.h BPF Type Format (BTF) headers, confirmed that this code had been built and tested on real systems. After sorting through the dump, we identified seven logical groupings. Three stand-alone LKM variants in the root directory targeted different kernel generations: stealth_centos7_v2.c (1,148 lines, targeting CentOS 7's kernel 3.10), stealth_kernel5x.c (767 lines, targeting kernel 5.x), and stealth_v5.c (876 lines, the "Ultimate Stealth" variant with delayed initialization). Two production directories, kernel5x_new/ and lkm_5x/, contained polished variants with module parameters, eBPF companions, and versioned ICMP control scripts. An ebpf_test/ directory contained 10 sequential iterations of ss-hiding eBPF programs and six versions of process-hiding programs, each building on the last, providing a clear record of iterative development. Finally, load_lkm.sh provided boot-time persistence with a particularly interesting feature: It scanned /proc/*/exe for processes running from memfd file descriptors, a telltale sign of fileless implants. Every source file was annotated entirely in Simplified Chinese. The comments ranged from straightforward function descriptions to detailed phase-numbered fix annotations. For example, the CentOS 7 variant's header contained a structured changelog that mapped perfectly to five development phases, translated here: Phase 1: Security/logic vulnerabilities - bounds checking, UDP ports, memory leaks, byte order Phase 2: Stealth enhancements - ICMP randomization, /proc/modules, kprobe hiding, log cleanup Phase 3: Compatibility - dynamic symbol lookup, struct offsets, IPv6, kernel version adaptation Phase 4: Stability - maxactive, RCU protection, priority, error handling Phase 5: Defense mechanisms - anti-debugging, self-destruct, dynamic configuration Individual fixes throughout the code were tagged with identifiers like [1.1], [2.1], [3.3], and [5.2], each corresponding to a specific phase and fix number. We’ll return to the significance of this annotation pattern later, as it provides compelling evidence about the rootkit's development methodology. The operator scripts revealed real infrastructure. The icmp_ctl.py usage examples referenced two Alibaba Cloud IP addresses, 8.149.128[.]10 and 116.62.172[.]147, indicating that VoidLink was being used operationally against targets accessible from Chinese cloud infrastructure. The load_lkm.sh boot script hard-codes a path to /root/kernel5x_new/vl_stealth.ko and configures port 8080 to be hidden by default, further suggesting active deployment. Architecture: A hybrid approach What makes VoidLink architecturally notable is its two-component design. Most Linux rootkits rely on a single mechanism for hiding, whether that’s an LKM hooking syscalls, an eBPF program attached to tracepoints, or a shared object injected via LD_PRELOAD. VoidLink uses both an LKM and an eBPF program, each handling the task for which it is best suited. This hybrid approach is rarely seen in the wild and reflects a deliberate engineering decision. The LKM component, which masquerades under the module name vl_stealth (or, in some variants, amd_mem_encrypt), is the backbone of the rootkit. It handles tasks that require deep kernel access: process hiding via getdents64 syscall hooking, file and module trace removal via vfs_read filtering, network connection hiding via seq_show kretprobes, and the ICMP-based command-and-control channel via Netfilter hooks. These operations require manipulating kernel-internal data structures and intercepting kernel functions at a level that only a loaded kernel module can achieve. The eBPF component handles a single but critical task: hiding network connections from the ss utility. The ss command doesn’t read from /pr

Indicators of Compromise

• malware — VoidLink
• malware — vl_stealth
• malware — amd_mem_encrypt
• malware — Ultimate Stealth v5

Entities