排查LKM Rootkit需交叉验证：比对lsmod与/sys/module数量差异，检查sys_call_table函数指针异常，溯源dmesg加载记录，分析非标.ko文件，并在可信环境挂载比对哈希与符号偏移。
直接看 /sys/module/ 目录比 lsmod 更可靠
因为 Reptile 这类 LKM rootkit 会主动从内核模块链表中把自己摘除，导致 lsmod 完全看不到它，但只要模块还在内存里加载着，/sys/module/ 下通常仍会残留对应子目录（哪怕权限被设为 000）。所以排查第一步不是跑 lsmod，而是：find /sys/module -maxdepth 1 -type d | grep -v '^/sys/module$' | sort
再人工比对模块名是否可疑——比如 reptile_module、diamorphine、hideko 这类非常规命名，或与当前系统业务完全无关的名称。
dmesg 里搜 module 关键字能抓到加载痕迹
Reptile 在安装时会调用 insmod 或 modprobe，内核日志里一般会留下记录。执行：dmesg | grep -i 'module\|insmod\|modprobe'
重点关注时间戳靠近可疑事件发生点的日志行。如果输出里出现类似 reptile_module: loading out-of-tree module taints kernel 这样的内容，基本可以确认加载过。注意：部分高级 rootkit 会清空 dmesg 缓冲区，所以得尽早执行；若发现 dmesg 输出为空或明显被截断，本身就是危险信号。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
检查系统调用表是否被篡改，重点盯 getdents64 和 kill
Reptile 和 Diamorphine 都依赖劫持这两个系统调用实现文件/进程隐藏。检测方法不是反编译模块，而是用符号地址交叉验证：
• 先查正常符号地址：grep 'sys_getdents64\|sys_kill' /boot/System.map-$(uname -r)
• 再读运行时实际地址：cat /proc/kallsyms | grep 'sys_getdents64\|sys_kill'
• 如果两个地址差值明显偏离其他系统调用的偏移规律（比如差值相差几 MB），大概率已被 hook。更直接的做法是用 check_syscall_table 这类轻量工具（如 sandflysecurity 的检测模块）做一致性校验，避免手算出错。
别只信 ps 和 netstat，要手动遍历 /proc
Reptile 会通过挂载覆盖或直接 unlink /proc/[pid] 来隐藏进程，导致常规命令失效。正确做法是：
• 用 ls -lai /proc | awk '$1 ~ /^d/ && $3 > 1 {print $NF}' | sort -n 扫描所有 PID 目录是否存在异常缺失（比如中间跳号严重）
• 对每个疑似 PID，尝试 ls -l /proc/<pid>/exe</pid> 和 cat /proc/<pid>/cmdline</pid>，如果返回 No such file or directory 但该 PID 确实存在于 /proc 列表中，极可能被隐藏
• 检查网络连接时，别只信 netstat -tulnp，改用 ss -tulnp 并配合 cat /proc/net/{tcp,udp} 手动解析十六进制端口和 IP，Reptile 的 TCP/UDP 隐藏逻辑常漏掉 raw socket 层面的暴露
/proc/sys/kernel/modules_disabled 被设为 1 后，lsmod 会彻底失能，但 /sys/module/ 和 dmesg 依然可用——这个开关本身不常见，一旦出现，几乎可断定有人试图掩盖模块加载行为。 
