VoidLink rootkit uses eBPF and kernel modules to hide deep inside Linux systems

VoidLink is an advanced Linux malware framework that blends classic kernel rootkit techniques with eBPF-based stealth, giving attackers a deeper and more flexible way to hide on compromised systems. Security researchers say the malware targets cloud and server environments, where Linux remains the backbone for containers, virtual machines, and enterprise workloads.

Check Point Research first documented VoidLink in January 2026 and described it as a cloud-native malware framework built for stealth, persistence, and modular expansion. The company said the framework appeared to come from a Chinese-affiliated development environment and included many in-progress builds, debug artifacts, and signs of rapid iteration.

Elastic Security Labs has now published a deeper technical analysis after reviewing a data dump that contained VoidLink source code, binaries, and deployment material. Elastic said the dump revealed multiple generations of the framework and showed how the operators combined Loadable Kernel Modules and eBPF to hide processes, files, modules, and active network connections in ways that frustrate normal system inspection tools.

What makes VoidLink different

Most Linux rootkits rely on one main concealment method. VoidLink uses two at the same time. Elastic said the kernel module handles classic hiding tasks such as filtering /proc data, intercepting directory listings, and concealing kernel module traces, while the eBPF component covers a gap the kernel module cannot handle as cleanly by manipulating data returned through Netlink so the ss command misses active connections.

That hybrid design matters because administrators often trust cross-checking tools such as ps, netstat, ss, and direct reads from /proc. VoidLink appears designed to break that trust model. Elastic said the malware hides different artifacts at different layers, which means defenders may see a clean result in one tool while the rootkit quietly suppresses the same evidence somewhere else.

Elastic also said VoidLink includes a covert ICMP-based command path, anti-debugging timers, delayed hook installation, process kill protection, and obfuscated module naming in newer variants. Some variants reportedly used the name amd_mem_encrypt to look more legitimate on Linux systems.

Check Point’s earlier findings still matter

Check Point’s January report framed VoidLink as a broader malware ecosystem, not just a rootkit. The researchers said the framework included more than 30 plugins and used a modular structure built for long-term access in Linux cloud infrastructure. They also said one developer appeared to build the framework rapidly with AI-assisted workflows using the TRAE development environment.

The company stopped short of saying the tool had already reached mass deployment, but it did say the pace of change and the number of development artifacts suggested active refinement for real-world use. That makes Elastic’s later source-code-based analysis especially important because it adds technical depth to the original threat picture.

How the rootkit hides activity

Elastic said the LKM component hooks core kernel paths to hide files, processes, and module traces. It intercepts getdents64 for directory listings and filters views such as /proc/modules and /proc/kallsyms to erase signs of its presence. The same component also processes XOR-encrypted instructions delivered through ICMP packets, which helps it receive commands without exposing a normal listening port.

The eBPF side solves a different problem. Elastic said ss gets connection data through Netlink rather than from /proc/net/tcp, so a normal kernel hook cannot hide those records cleanly. VoidLink’s eBPF logic instead modifies returned Netlink structures in memory so hidden entries look like padding and get skipped by the parser. Elastic said the developers iterated through multiple eBPF versions before reaching a stable method.

That level of iteration suggests disciplined testing rather than a one-off proof of concept. Elastic’s write-up describes a framework that matured across several generations and multiple Linux distributions, including CentOS 7 and Ubuntu 22.04.

VoidLink at a glance

Why defenders should pay attention

• VoidLink targets Linux infrastructure that often supports cloud and container workloads.
• Its dual stealth model can undermine standard cross-checking between user-space and kernel-visible tools.
• The framework appears modular and built for expansion, which means operators can adapt it over time.
• Newer variants show anti-analysis improvements that make incident response harder.

What admins can do now

Security teams should focus on hardening the paths VoidLink abuses.

• Enforce Secure Boot and kernel module signing where possible so unauthorized LKMs cannot load easily. Elastic and broader Linux hardening guidance support this approach.
• Enable kernel lockdown mode on supported systems to limit sensitive kernel operations.
• Audit init_module and finit_module activity so unexpected kernel module loading stands out earlier.
• Restrict eBPF exposure by disabling unprivileged BPF where possible and tightening syscall controls in hardened environments.
• Compare outputs from ps, ss, and direct /proc inspection during investigations because one clean result may not mean the host is clean.

FAQ