VoidLink Linux Rootkit Framework — eBPF + LKM Hybrid Persistence with ICMP C2
VoidLink Linux Rootkit Framework (TL-2026-0284), also tracked as VoidLink, is a high-severity malware campaign, first published 2026-03-25. It carries a reported China nexus and is not formally attributed, affects Linux CentOS 7, maps to 21 MITRE ATT&CK techniques (T1001, T1005, T1014), and is covered by 9 detection rules and 22 indicators of compromise.
Key facts for TL-2026-0284
- Threat ID
- TL-2026-0284
- Also known as
- VoidLink, Ultimate Stealth v5
- Severity
- HIGH
- Status
- ACTIVE
- Category
- MALWARE
- First published
- 2026-03-25
- Last reviewed
- 2026-03-25
- Attribution confidence
- NONE
- Nation-state nexus
- China
- Motivation
- UNKNOWN
- Target sectors
- government, technology, cloud-services, telecommunications, defense, critical-infrastructure
- Target regions
- Asia-Pacific, Global
- Detection rules
- 9
- Indicators of compromise
- 22
Malware and tooling in VoidLink Linux Rootkit Framework
Malware and tooling: TRAE SOLO AI Assistant
VoidLink is a sophisticated Linux rootkit framework attributed to a Chinese-speaking threat actor that combines Loadable Kernel Modules (LKM) with eBPF programs to achieve stealth persistence, process/network hiding, and covert ICMP-based command-and-control. Four generations of the framework target CentOS 7, Linux kernel 5.x, and Ubuntu 22.04, with C2 infrastructure hosted on Alibaba Cloud. Evidence strongly suggests AI-assisted development using the TRAE IDE, producing 88,000+ lines of code in approximately one week.
How VoidLink Linux Rootkit Framework works
VoidLink represents a significant advancement in Linux rootkit design, combining traditional Loadable Kernel Module (LKM) techniques with modern extended Berkeley Packet Filter (eBPF) programs to create a hybrid stealth framework that evades both legacy and contemporary detection tools.
**Architecture Overview**
The framework operates as a dual-component system. The LKM component handles core rootkit functions: process hiding via getdents64 syscall hooking through ftrace, file and module trace removal via vfs_read filtering, network connection hiding via seq_show kretprobes, signal interception for process protection, and ICMP-based command-and-control through Netfilter hooks. The eBPF component specifically targets the ss utility through a novel "swallowing" technique — hooking __sys_recvmsg at entry and return to capture userspace buffer addresses and then walk Netlink message chains, extending the previous message's nlmsg_len field to absorb hidden socket entries.
**Four Generations of Development**
Generation 1 (CentOS 7): stealth_centos7_v2.c (1,148 lines) targeting kernel 3.10, using direct syscall table modification via CR0 register manipulation with a flexible symbol finder handling GCC compiler optimization suffixes (.isra, .constprop, .part).
Generation 2 (Kernel 5.x): stealth_kernel5x.c (767 lines) replacing direct syscall hooking with the ftrace framework and employing the "kprobe trick" for symbol resolution after kallsyms_lookup_name() became unexported in kernel 5.7.
Generation 3 (Production): Located in kernel5x_new/ and lkm_5x/ directories, adding configurable module parameters (init_pids, init_ports, stealth flag) and dual Netfilter hook registration on both NF_INET_PRE_ROUTING and NF_INET_LOCAL_IN chains.
Generation 4 ("Ultimate Stealth v5"): stealth_v5.c (876 lines) implementing delayed initialization (3-second deferral via schedule_delayed_work()), anti-debugging timers firing every 5 seconds to detect forensic tools (strace, ltrace, gdb, perf, bpftool, bpftrace, systemtap, crash, kdb, trace-cmd, ftrace, sysdig, dtrace), process kill protection by hooking do_send_sig_info to discard SIGKILL/SIGTERM/SIGSTOP/SIGINT/SIGHUP/SIGQUIT for protected PIDs, and XOR-obfuscated module names at runtime.
**ICMP C2 Protocol**
The C2 channel operates over ICMP Echo Requests intercepted by Netfilter hooks. Packets matching the magic identifier 0xC0DE are silently dropped (NF_DROP) before the kernel processes them. The protocol uses a 64-byte icmp_cmd structure with a command byte, length field, and 62-byte XOR-encrypted payload (key: 0x42). Version 5 supports 10 commands including GIVE_ROOT (0x11) for privilege escalation via prepare_creds()/commit_creds(), SET_KEY (0x20) for runtime credential rotation, and commands for process hiding, port hiding, IP hiding, module discovery, and self-destruction.
**Evasion Techniques**
Delayed Initialization: mod_init() returns successfully after resolving only kallsyms_lookup_name via the kprobe trick, with actual hook installation deferred by 3 seconds via schedule_delayed_work() to evade synchronous module-load security checks. Module Masquerading: Copies legitimate AMD Memory Encryption (SME/SEV) driver metadata and description strings. Fileless Integration: load_lkm.sh scans /proc/*/exe for processes running from memfd file descriptors, auto-hiding them upon rootkit activation.
**AI-Assisted Development**
Source code contains phase-numbered refactoring annotations structured as: Phase 1 (security/logic vulnerabilities), Phase 2 (stealth enhancements), Phase 3 (compatibility), Phase 4 (stability), Phase 5 (defense mechanisms). Tutorial-style comments, chain-of-thought reasoning traces, and consistent Unicode box-drawing headers across all files indicate LLM-assisted development using the TRAE SOLO AI assistant. Check Point Research documents this as the first evidently documented case of a sophisticated malware framework authored almost entirely by AI, with development starting late November 2025 and producing a first functional implant by December 4, 2025 — approximately one week to reach 88,000+ lines of code.
**Attribution**
Attributed to a Chinese-speaking threat actor based on Simplified Chinese source code comments, Chinese-language instruction documents and sprint plans, and Alibaba Cloud infrastructure. OPSEC failures exposed development timelines, technical specifications, and design documentation. The actor employed Spec Driven Development (SDD) methodology with AI-generated 20-week development plans across three internal teams.
MITRE ATT&CK techniques used in TL-2026-0284
command-and-control
T1001 Data Obfuscation; T1095 Non-Application Layer Protocol; T1573 Encrypted Channel
collection
defense-evasion
T1014 Rootkit; T1027 Obfuscated Files or Information; T1036 Masquerading; T1070 Indicator Removal; T1140 Deobfuscate/Decode Files or Information; T1205 Traffic Signaling; T1564 Hide Artifacts
discovery
T1049 System Network Connections Discovery; T1057 Process Discovery; T1082 System Information Discovery
execution
T1059 Command and Scripting Interpreter; T1106 Native API
privilege-escalation
T1068 Exploitation for Privilege Escalation; T1548 Abuse Elevation Control Mechanism
impact
persistence
T1547 Boot or Logon Autostart Execution
defense-impairment
Affected products and versions in VoidLink Linux Rootkit Framework
- Linux — CentOS 7
Vulnerable versions: kernel 3.10 - Linux — Linux Kernel 5.x
Vulnerable versions: 5.x series - Canonical — Ubuntu 22.04
Vulnerable versions: kernel 6.2 - Linux — Cloud Environments
Vulnerable versions: AMD hardware with SME/SEV
Remediation for VoidLink Linux Rootkit Framework
Immediate actions
- Block Alibaba Cloud IPs 8.149.128.10 and 116.62.172.147 at perimeter firewall
- Check for suspicious kernel modules: lsmod | grep -E 'vl_stealth|amd_mem_encrypt'
- Compare lsmod output against /sys/module/ directory contents for hidden modules
- Inspect /sys/kernel/debug/tracing/enabled_functions for suspicious ftrace hooks
- Run bpftool prog list to detect kprobe/kretprobe programs attached to __sys_recvmsg
- Cross-reference process counts: ps aux vs /proc/ directory entries
- Compare listening ports across netstat, ss, and /proc/net/tcp for discrepancies
- Check for boot persistence: inspect load_lkm.sh in startup scripts
Workarounds
- Disable unnecessary kernel module loading on production servers
- Restrict eBPF program loading to CAP_BPF/CAP_SYS_ADMIN processes
- Block ICMP Echo Requests at host firewall where not operationally required
- Enable Secure Boot with kernel module signature verification
Longer-term hardening
- Deploy kernel integrity monitoring (AIDE, Tripwire) for /sys/module/ and /sys/fs/bpf/
- Implement auditd rules tracking init_module, finit_module, delete_module syscalls
- Monitor syslog for bpf_probe_write_user helper invocations
- Deploy YARA rules targeting VoidLink module descriptions and function names
- Restrict kernel module loading to signed modules (CONFIG_MODULE_SIG_FORCE)
- Implement eBPF program allowlisting where supported
- Verify amd_mem_encrypt module presence only on AMD systems with SME/SEV support
- Deploy EDR with kernel-level behavioral detection capabilities
Timeline of VoidLink Linux Rootkit Framework
- VoidLink development initiated by Chinese-speaking threat actor using TRAE SOLO AI assistant with Spec Driven Development methodology
- Generation 1 (CentOS 7) rootkit completed: stealth_centos7_v2.c (1,148 lines) with direct syscall table modification via CR0
- First functional VoidLink implant produced — approximately one week from project initialization to working malware
- Generation 2 (Kernel 5.x) development: stealth_kernel5x.c (767 lines) replacing syscall hooking with ftrace framework and kprobe trick
- Check Point Research publishes initial documentation on VoidLink as first documented AI-authored malware framework
- Generation 3 (Production) deployed with configurable module parameters and dual Netfilter hook registration
- eBPF component undergoes rapid iteration — 10 versions of hide_ss.bpf.c developed for ss utility evasion via swallowing technique
- Generation 4 'Ultimate Stealth v5' (stealth_v5.c, 876 lines) introduces delayed initialization, anti-debugging timers, and XOR-obfuscated module names
- VoidLink framework observed in active use with C2 infrastructure on Alibaba Cloud IPs 8.149.128.10 and 116.62.172.147
- Threadlinqs Intelligence publishes comprehensive analysis of VoidLink rootkit framework
- Elastic Security Labs publishes 'Illuminating VoidLink' — detailed technical analysis of all four generations and eBPF components
- As of 2026-05-29, VoidLink remains an active threat: Cisco Talos attributes ongoing campaigns to China-nexus actor UAT-9921 (active since ~2019) hitting tech/financial sectors, with victims since Sept 2025 and no takedown or arrests reported. The AI-built rootkit framework is still evolving, adding on-demand tooling and Windows plugin support.
Sources cited for VoidLink Linux Rootkit Framework
- Elastic Security Labs — Illuminating VoidLink: Technical analysis of the VoidLink rootkit framework
- Check Point Research — VoidLink: First documented AI-authored malware framework
- MITRE ATT&CK — Rootkit (T1014)
- MITRE ATT&CK — Kernel Modules and Extensions (T1547.006)
- MITRE ATT&CK — Non-Application Layer Protocol (T1095)
- Linux Kernel eBPF Documentation
- TRAE IDE — AI-Assisted Development Tool by ByteDance
Threats related to VoidLink Linux Rootkit Framework
- Daxin Rootkit Resurfaces After 13 Years: China-Linked Kernel Backdoor Found Alongside New Pre-Auth 'Stupig' DLL on Taiwan Manufacturer's Network
- Daxin Kernel Rootkit Resurfaces in Taiwan Alongside New Stupig Pre-Auth SYSTEM Backdoor
- Showboat (EvaRAT): PRC-Backed Modular Linux Post-Exploitation Framework Targeting Middle East Telecom Firms Since 2022
- Backdoor.Stupig — Windows Login-Screen Keyboard-Layout Provider Backdoor Grants SYSTEM Access, Deployed Alongside Resurfaced Daxin
Detection coverage for TL-2026-0284
As of 2026-03-25, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0284 across Splunk SPL, Microsoft KQL and Sigma, covering 22 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.