排查LKM Rootkit需验证内核运行时状态一致性：比对lsmod与/sys/module数量差异、分析dmesg模块日志、检查sys_call_table函数指针异常、交叉验证ps与/proc进程数及名称。
排查内核模块（LKM）中的 Rootkit，关键不是“找一个文件”，而是验证内核运行时的真实状态是否被篡改。重点在于发现不一致：模块存在但不可见、系统调用指向异常、进程列表来源冲突、内核符号与实际内存不符。
比对模块可见性差异
正常情况下，lsmod 列出的模块应与 /sys/module/ 目录内容基本一致。Rootkit 常通过从内核模块链表中摘除自身节点来隐藏：
- 执行 lsmod | wc -l 记下模块数量
- 执行 ls /sys/module/ | wc -l 获取实际加载模块数
- 若后者明显更多（如多出 5 个以上），说明有模块被 lsmod 过滤掉
- 进一步检查 ls /sys/module/ 中陌生或命名可疑的目录（如 z0mb13、drv_k、hidden_mod）
检查内核日志中的模块加载痕迹
即使模块被隐藏，加载过程仍可能留下内核环缓冲区记录：
- 运行 dmesg | grep -i 'module\|insmod\|init_module'
- 关注含 “loading”、“initialized”、“registered” 等关键词的行
- 提取疑似模块名，再反查 /sys/module/<name> 是否存在
- 注意时间戳异常的条目——比如系统重启后几分钟内出现未预期的模块初始化日志
验证系统调用表是否被劫持
多数 LKM Rootkit 会挂钩 sys_getdents64、sys_kill 等关键函数以实现隐藏或提权：
- 先获取系统调用表地址：cat /proc/kallsyms | grep sys_call_table
- 使用 volatility -f memdump.raw linux_check_syscall（需内存镜像）或编写轻量内核模块读取对应索引处的函数指针
- 重点检查
__x64_sys_getdents64、__x64_sys_kill、__x64_sys_openat的实际地址 - 若某函数指针指向
/tmp、/dev/shm或非内核代码段（如地址不在0xffffffff80000000起始范围），高度可疑
交叉验证进程枚举结果
Rootkit 若在 VFS 层或 task_struct 链表做手脚，会导致不同工具看到的进程数不一致：
- 统计 ps aux | wc -l 和 ls /proc/[0-9]* 2>/dev/null | wc -l
- 运行 volatility -f memdump.raw linux_psxview（如有内存转储）
- 若
ps显示 120 个进程，而/proc下只有 80 个 PID 目录，或psxview报告多个“Not found in proc”条目，说明进程已被脱链或目录项被过滤 - 此时应结合 cat /proc/*/comm 2>/dev/null | sort -u 查看是否存在异常进程名（如 .kthreadd、ksyslogd）
