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

首页

业界动态

热心网友

转载

2026-04-15

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

VoidLink这个rootkit最值得玩味的地方，在于它同时动用了两种内核级技术来达成隐身目的，这种组合拳在实战中可不多见。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

通常来说，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，但发现这法子会导致内核不稳定。源码注释里留了一句大实话（从中文翻译过来）：「ss命令隐藏由eBPF模块实现（更稳定）」。

最终实现的eBPF方案相当精巧。它在__sys_recvmsg函数的入口和返回处各挂一个钩子。入口钩子负责记下用户态接收缓冲区的地址；等到函数返回时，再遍历缓冲区里的Netlink消息链。当发现需要隐藏的端口对应的消息时，它并不直接删除这条消息（那样会破坏整个消息链的结构），而是耍了个花招：把前一条消息的长度字段“撑大”，让目标消息被“吞掉”。这样一来，ss的解析器在遍历消息链时，就会把被吞掉的条目当作前一条消息的填充数据，直接跳过。

这个“吞噬”技巧的实现，依赖的是bpf_probe_write_user这个BPF辅助函数——这个函数原本是给内核调试工具用的，结果被VoidLink拿来做了创造性的滥用。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（ping请求）包，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协作——人类定义需求并在真实系统上测试，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编译（Serverside Rootkit Compilation, SRC）。

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包。