VoidLink Rootkit Uses eBPF and Kernel Modules to Hide Deep Inside Linux Systems

A new and technically advanced rootkit called VoidLink has emerged as a serious threat to Linux systems, blending Loadable Kernel Modules (LKMs) with extended Berkeley Packet Filter (eBPF) programs to hide deep inside the operating system’s core.

First documented by Check Point Research in January 2026, VoidLink is a cloud-native Linux malware framework written in Zig.

It features a modular command-and-control structure with over 30 plugins and multiple stealth layers, making it one of the most capable Linux rootkits seen in recent years.

What makes VoidLink alarming is how quickly it was built. Check Point Research found that a single developer produced the full framework through AI-assisted workflows using the TRAE integrated development environment, going from concept to a working implant in under a week.

The rootkit disguises itself under the module name vl_stealth, or in some variants amd_mem_encrypt, impersonating a legitimate AMD memory driver to avoid raising suspicion on cloud servers.

Elastic Security Labs analysts identified the malware’s deeper architecture after obtaining a data dump containing VoidLink’s source code, compiled binaries, and deployment scripts.

Researchers noted that the dump revealed a multigenerational rootkit framework developed and tested across real systems from CentOS 7 to Ubuntu 22.04.

Every source file was annotated in Simplified Chinese, and infrastructure references pointed to Alibaba Cloud IP addresses — 8.149.128[.]10 and 116.62.172[.]147 — firmly linking the operation to a Chinese-speaking threat actor.

The rootkit’s impact is significant. VoidLink hides running processes, network connections, and files from administrators while receiving commands through a covert ICMP channel with no visible ports or traffic.

Its most recent variant, dubbed Ultimate Stealth v5, introduces delayed hook installation, anti-debugging timers, process kill protection, and XOR-obfuscated module names, making forensic investigation extremely difficult.

VoidLink is not a standalone tool. Its boot loader script, load_lkm.sh, scans for fileless implants running from anonymous memory file descriptors and hides them on activation, confirming VoidLink is designed to shield a companion implant — likely a reverse shell — already running on the compromised target.

A Two-Layer Hiding System

The most technically striking feature of VoidLink is its hybrid design, splitting duties between two distinct components.

Most Linux rootkits rely on a single concealment method — an LKM, an eBPF program, or an injected shared library. VoidLink deploys both simultaneously, with each component handling the role it performs most reliably.

Using the Linux kernel’s function tracing framework, the LKM component hooks system calls, intercepts getdents64 directory listings to conceal files and processes, and filters /proc/modules and /proc/kallsyms output to erase its own traces.

It also runs a covert command channel through Netfilter hooks, silently processing XOR-encrypted operator instructions hidden inside ordinary ping packets with no reply generated.

The eBPF component covers a gap the LKM cannot reach: hiding active connections from the ss command. Unlike netstat, which reads from /proc/net/tcp, the ss utility queries the kernel through Netlink sockets — a data path outside the LKM’s control.

VoidLink’s eBPF program hooks __sys_recvmsg and modifies Netlink responses in userspace memory. Rather than deleting hidden entries — which would corrupt the message chain — it swallows them by extending the previous message’s length field, causing the ss parser to skip the hidden connection as padding.

This approach required genuine iteration to develop. The developers worked through at least 10 eBPF program versions — from hide_ss_v1.bpf.c through hide_ss_v9.bpf.c — before this stable method emerged, demonstrating real testing cycles on live systems.

Security teams should take several steps to limit exposure to rootkits like VoidLink. Enforcing Secure Boot and kernel module signing blocks unauthorized LKMs from loading.

Enabling kernel lockdown mode, available since Linux 5.4, restricts sensitive kernel operations even for root users. Auditing init_module and finit_module syscalls via Auditd surfaces unexpected module activity early.

Restricting the bpf() syscall through seccomp profiles and enabling kernel.unprivileged_bpf_disabled reduces eBPF abuse risk. Regularly cross-referencing ps, ss, and direct /proc directory entries can expose hidden activity even when individual monitoring tools report nothing suspicious.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.