VoidLink Rootkit 源码泄露：一个 AI 写出的内核级隐身框架长什么样

核心架构：LKM + eBPF 的混合设计

VoidLink rootkit在技术实现上最值得关注的一点，是其采用了LKM与eBPF相结合的混合架构。这种双管齐下的设计，在已知的Linux内核威胁中并不常见。

传统的Linux rootkit开发通常遵循单一技术路径：要么依赖LKM直接修改系统调用表，要么利用eBPF挂钩内核追踪点，或者在用户态通过LD_PRELOAD进行劫持。VoidLink则另辟蹊径，它整合了LKM与eBPF的优势，构建了一个协同工作的双组件系统。Elastic安全团队的分析报告指出，这种混合设计在野外的恶意软件样本中极为罕见。

其具体分工如下：

简而言之，LKM模块负责拦截并篡改netstat命令的查询结果，而eBPF模块则专门用于隐藏ss命令的探测。这种分而治之的策略源于一个关键的技术差异：netstat与ss这两个网络诊断工具访问内核数据的方式截然不同。netstat通过读取/proc/net/tcp等proc文件系统接口获取信息，因此使用kretprobe钩子篡改seq_file的计数器即可有效欺骗它。然而，ss命令直接通过Netlink套接字与内核的socket诊断接口通信，传统的kretprobe劫持方法对此完全无效。

开发者最初尝试使用kretprobe劫持inet_sk_diag_fill函数来应对ss命令，但发现此方法会导致内核不稳定。源码中的注释明确指出了转向eBPF的原因（译文）：「ss命令的隐藏功能由eBPF模块实现（更稳定）」。

最终实现的eBPF方案设计精巧。它在__sys_recvmsg函数的入口和返回处分别挂载钩子。入口钩子负责记录用户态接收缓冲区的地址；当函数返回时，返回钩子会遍历缓冲区中的Netlink消息链。当发现需要隐藏的端口所对应的消息时，它并不直接删除该消息（以免破坏消息链结构），而是采用了一种巧妙的“吞噬”技巧：将前一条消息的长度字段扩大，使其覆盖目标消息。这样，ss命令的解析器在遍历消息链时，就会将被覆盖的条目视为前一条消息的填充数据而自动跳过。

这一“吞噬”技巧的实现依赖于bpf_probe_write_user这个BPF辅助函数——该函数本用于内核调试，却被VoidLink创造性地滥用于操纵Netlink缓冲区。Elastic的报告强调，这种直接操作用户态Netlink缓冲区的手法，在公开的恶意软件分析文献中极少被记载。

四代进化：从粗暴到精密

泄露的源码清晰地展示了至少四代rootkit的迭代过程，每一次升级都伴随着与内核安全机制的对抗。

第一代（CentOS 7 / kernel 3.10）是最原始的版本，代码量1148行，手法直接：修改系统调用表。在内核3.10时代，kallsyms_lookup_name()函数是公开导出的，定位系统调用表非常容易。修改时需要临时关闭CPU的写保护位（操作CR0寄存器），这是rootkit开发中的经典手法。这一代还有一个值得注意的细节：它会暴力枚举GCC编译器优化可能产生的符号名后缀（如.isra.0、.constprop.5），每种后缀尝试20个变体，这表明开发者在实际部署中确实遇到了符号被重命名的问题。

第二代（kernel 5.x）被迫调整策略。从内核5.7开始，kallsyms_lookup_name()不再导出，系统调用表的写保护也更强。因此，第二代采用了rootkit圈内流行的“kprobe把戏”：注册一个指向kallsyms_lookup_name的kprobe，内核在注册过程中会自动解析出函数地址并存储在kp.addr字段中，读取该地址后立即注销kprobe。系统调用劫持的方式也从直接修改系统调用表，转变为更隐蔽的ftrace钩子。

第三代（生产版）引入了模块参数，允许操作者在加载模块时直接指定要隐藏的进程ID和端口，无需等待ICMP命令通道建立。它在两条Netfilter钩子链上同时注册，确保在各种网络配置和iptables规则下都能可靠接收命令。最关键的是，它将隐藏ss命令的任务正式移交给了独立的eBPF组件。

第四代（「Ultimate Stealth v5」）是最成熟的版本，集成了多项高级规避技术：

• 延迟初始化：模块加载时仅完成基本符号解析并立即返回“成功”，真正的钩子安装工作在三秒后通过delayed_work悄悄进行。这使得在模块加载瞬间进行扫描的安全工具会误判其为“干净”模块。
• 反调试定时器：每五秒扫描一次进程列表，检测strace、gdb、bpftool、rkhunter等13种调试和取证工具。
• 进程保护：通过ftrace劫持do_send_sig_info函数，拦截所有发送给受保护进程的SIGKILL、SIGTERM等致命信号。函数返回成功，但信号实际并未投递，导致管理员误以为kill命令已生效。
• 模块伪装：模块元数据被伪装成AMD的内存加密驱动amd_mem_encrypt，在云实例和虚拟机上不易引起怀疑。模块名还使用XOR加密存储，防止简单的字符串扫描发现伪装名。

ICMP 隐蔽通道

所有版本的VoidLink都内置了一个基于ICMP的隐蔽命令与控制通道。操作者发送特制的ICMP Echo Request数据包，rootkit的Netfilter钩子会在内核正常处理这些包之前将其拦截，解析并执行命令后直接丢弃，不返回任何ICMP Reply。

识别机制依赖于ICMP头部echo.id字段中的一个“魔数”（默认为0xC0DE），命令数据则使用单字节XOR加密（默认密钥为0x42）。生产版支持多达10种命令，包括隐藏进程/端口、提权（将目标进程的UID/GID直接设为0）以及自毁。

其运行时密钥轮换功能值得注意：操作者可以在运行中更换魔数和加密密钥，此后所有命令必须使用新值。这意味着，即使防御者发现了初始的0xC0DE签名，攻击者只需更换密钥即可继续维持控制。控制脚本icmp_ctl.py的v2版本甚至包含一个“探测模式”，会遍历一个常用魔数列表（如0xC0DE、0xDEAD、0xBEEF、0xCAFE、0xFACE），试图重新定位密钥被轮换后的rootkit。

然而，该通道存在一个固有弱点：所有命令包都被静默丢弃（NF_DROP）。正常的ICMP Echo Request会收到回复，而发送给rootkit的命令包则“有去无回”。安全研判认为，一个能够关联ICMP请求与响应的网络监控系统，可以检测到这种异常的ping模式。

AI 辅助开发的微观证据

如果说Check Point从宏观层面证实了VoidLink由AI辅助开发（恢复了冲刺规划文档、TRAE IDE工件等），那么Elastic的源码分析则从微观层面，为这一结论提供了密集的证据。

最具说服力的证据隐藏在CentOS 7版本的分阶段重构标注中。文件头部有一个结构清晰的变更日志，读起来像一系列LLM对话的轮次记录：「修复安全问题」（Phase 1）、「改进隐身」（Phase 2）、「添加兼容性」（Phase 3）、「提升稳定性」（Phase 4）、「添加防御机制」（Phase 5）。代码中的具体修改都标有[1.1]、[2.3]、[5.2]等标签，对应特定阶段的修复编号。

注释风格也透露出AI的痕迹。例如，在一个仅有三行的XOR解密循环上方，明确标有「XOR解密」——有经验的内核开发者通常不会为如此简单的代码添加注释。此外，每个源文件都使用相同的Unicode盒线字符（═══）分隔章节，这种高度一致且带有装饰性的格式，是LLM生成代码的典型特征。

ebpf_test/目录提供了最生动的证据。从hide_ss.bpf.c到hide_ss_v9.bpf.c，10个版本的逐步迭代，多个版本中还保留着被注释掉的“方法尝试”标注，读起来极似思维链推理留下的痕迹。

当然，VoidLink并非纯AI创作。控制脚本中出现了真实的阿里云IP地址（8.149.128[.]10和116.62.172[.]147），表明它曾在真实目标上被使用。编译好的.ko文件针对特定内核版本，启动脚本load_lkm.sh中的memfd扫描逻辑也说明，它是更大攻击工具链中的一环。研判认为，最可能的开发模式是人机协作：人类定义需求并进行真实环境测试，AI生成初始实现，再根据错误报告迭代修复。

根据Check Point和Sysdig的分析，开发者使用了字节跳动的TRAE IDE（一个基于VS Code分支的AI编程工具，免费提供Claude和GPT-4o访问）。整个项目从2025年11月27日启动，到12月4日达到功能可用状态，用时不到一周。一个原本可能需要三个团队耗时30周的开发计划，被单人与AI协作压缩到了短短几天。

Sysdig 发现的额外能力

Elastic的分析聚焦于rootkit源码本身，而Sysdig威胁研究团队在1月的独立分析中，还发现了一项此前未被记录的技术——服务端Rootkit编译。

LKM rootkit一直面临一个难题：内核模块必须针对特定内核版本进行编译，跨版本部署困难。VoidLink的解决方案很巧妙：由C2服务器按需编译。植入体先将目标机器的内核详细信息发送到C2，C2随后返回一个针对该内核版本定制的模块。这使得植入体本身可以保持小巧，rootkit代码可在服务端随时更新，无需在目标机器上安装庞大的编译工具链。

整个框架还会根据目标内核版本自动选择部署策略：内核6.x使用远程编译的eBPF程序，内核5.x使用eBPF + LKM混合模式，更老的内核则使用远程编译的LKM模块。

威胁态势评估

将VoidLink置于更广阔的背景下观察，它标志着eBPF rootkit正在成为一个不容忽视的威胁类别。2025年10月，Synacktiv披露了LinkPro rootkit，同样利用eBPF隐藏进程并通过“魔术包”激活后门。FortiGuard Labs在2025年底也报告了BPFDoor的151个新样本，以及Symbiote rootkit的新变种，它们都在升级自身的eBPF过滤能力。

安全研判显示，VoidLink的出现与这些趋势共同表明，eBPF这把“双刃剑”正被越来越多地武器化。它本是Linux内核强大的可观测性工具（Cilium、Tetragon等知名项目都依赖它），但同样的能力也使rootkit得以在内核中近乎隐形地运行。更令人担忧的是，AI辅助开发极大地降低了技术门槛。过去编写内核级rootkit需要多年的内核编程经验，而现在，一个懂概念但缺乏实现能力的攻击者，配合LLM进行迭代，就能产出功能完善、历经多代演进的rootkit。

检测与防御要点

尽管VoidLink进行了层层伪装，但Elastic的报告也指出了几个可行的检测切入点：

• 模块完整性检查：rootkit会从内核模块链表（lsmod）中删除自己，但/sys/module/下的sysfs条目可能依然存在。比较lsmod输出与ls /sys/module/的差异，可能发现隐藏的模块。此外，在没有AMD硬件的系统上出现amd_mem_encrypt模块，是一个强烈的异常信号。
• ftrace钩子扫描：检查/sys/kernel/debug/tracing/enabled_functions文件，对__x64_sys_getdents64、vfs_read等函数上异常的ftrace钩子保持警惕。但需注意，VoidLink的vfs_read钩子会过滤对该文件的读取，因此可能需要从可信的内核内存或离线镜像中进行检查。
• eBPF程序枚举：使用bpftool prog list命令可以枚举所有加载的BPF程序。附着在__sys_recvmsg等关键系统调用上的kprobe/kretprobe程序，在生产环境中极不寻常。监控bpf_probe_write_user辅助函数的使用情况，也是一个有效的检测点。
• 行为交叉验证：比较ps aux的输出与/proc/目录下的进程条目，或者对比netstat、ss和/proc/net/tcp的输出。如果eBPF组件未加载，或不同组件的隐藏列表不同步，那么不同视角之间的不一致性，就是rootkit活动的明显标志。
• ICMP流量异常：关联网络中的ICMP Echo Request与Reply，调查那些没有收到回复的ping包。

在防御层面，Elastic建议启用Secure Boot和内核模块签名、利用Linux 5.4+内核的lockdown模式、通过Auditd监控init_module/finit_module系统调用，以及使用seccomp或LSM策略来限制bpf()系统调用的使用。

来源：互联网