排查lkm rootkit后门需交叉验证：比对lsmod与/sys/module/数量差异，检查sys_call_table函数指针异常，溯源dmesg加载记录，分析非标.ko文件，并在可信环境挂载比对哈希与符号偏移。
排查内核模块（LKM）中的Rootkit级身份后门，不能只依赖lsmod输出——攻击者早已把恶意模块从内核链表中摘除，使其“不可见”。必须结合底层符号比对、内存状态验证和加载痕迹溯源，分步交叉确认。
检查模块列表一致性
正常情况下，lsmod显示的模块数应与/sys/module/目录下实际存在的子目录数量一致。若明显不等，说明有模块被隐藏：
- 运行
lsmod | wc -l统计可见模块行数 - 运行
ls /sys/module/ | wc -l统计内核已加载但未暴露的模块数 - 若后者显著更多（如多出5个以上），需重点排查
dmesg | grep -i 'insmod\|module'中近期可疑的加载记录
验证系统调用表是否被篡改
Rootkit常劫持sys_getdents64、sys_openat等关键函数，以过滤进程或文件列表。直接读取内核符号地址并比对指针值是有效手段：
- 执行
cat /proc/kallsyms | grep sys_call_table获取系统调用表起始地址 - 使用
volatility -f memdump.raw linux_check_syscall（需内存镜像）或自编C模块读取该地址处的函数指针 - 重点检查
sys_getdents64是否指向ffffffff81..范围外的地址（如0xffff...xxx），这类地址通常属于动态加载模块
扫描异常模块加载痕迹
即使模块已脱链，其加载行为仍可能残留于内核日志或文件系统：
- 运行
dmesg -T | grep -i 'loading module\|insmod\|init_module'，关注时间戳异常靠前或来源不明的模块名 - 检查
/lib/modules/$(uname -r)/kernel/下是否有非标准子目录（如extra/、mal/），再用file和strings分析其中ko文件 - 搜索
/tmp、/dev/shm、/var/tmp中是否存在.ko文件：find /tmp /dev/shm /var/tmp -name "*.ko" -type f 2>/dev/null
从干净环境挂载分析
若怀疑当前系统已被深度控制，lsmod、dmesg等命令输出本身可能已被劫持。此时需借助外部可信环境：
- 使用Live CD或救援系统启动，挂载原系统根分区（如
mount /dev/sda1 /mnt） - 检查
/mnt/lib/modules/$(uname -r)/中是否有签名异常或哈希不匹配的ko文件 - 导出
/mnt/boot/System.map-$(uname -r)，与官方内核映射比对sys_call_table等符号偏移是否一致
