VoidLink Rootkit Hides Deep in Linux Using e Uses Kernel

A new and technically sophisticated rootkit, named VoidLink, presents a serious threat to Linux systems. This malware leverages both Loadable Kernel Modules (LKMs) and extended Berkeley Packet Filter (eBPF) programs to achieve deep stealth within the operating system’s kernel, as detailed in

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.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.