rootkit检测不能仅依赖单次扫描，因其可劫持rkhunter等工具输出；须用静态busybox交叉验证ls/ps/netstat命令是否被篡改，并检查ld_preload、/etc/ld.so.preload、内核模块、initramfs、grub及systemd持久化项。
不能只靠一次扫描就认为后门已清，Rootkit的顽固性在于它能让检测工具“失明”——rkhunter 和 chkrootkit 的输出本身可能已被劫持。
必须用静态工具交叉验证 ls、ps、netstat 等命令是否被篡改
攻击者替换 /bin/ls 或通过 LD_PRELOAD 劫持 readdir() 后，你看到的目录列表和进程列表全是过滤过的。此时依赖系统自带命令等于在假情报上做判断。
- 从可信来源下载静态编译的
busybox（如官方二进制或 Alpine 镜像中提取），上传到服务器并执行：./busybox ls -la /bin/、./busybox ps aux、./busybox netstat -tulpn，比对输出是否与系统命令一致 - 检查关键命令是否被硬链接或符号链接覆盖：
ls -l /bin/ls /usr/bin/ps /usr/bin/netstat - 验证动态链接行为：
ldd /bin/ls查看是否加载了异常.so；检查/etc/ld.so.preload是否存在且内容可疑 - 若发现
/bin/ls指向/tmp/.x/ls或类似路径，基本可确认用户态 Rootkit 已驻留
绕过 lsmod 伪造，直接读取内核模块原始数据
内核态 Rootkit（如 Reptile）常从 module_list 链表中脱链，导致 lsmod 完全不可见。但内核内存映射仍保留痕迹，需跳过用户态接口直取底层。
- 用
cat /proc/modules和cat /sys/module/*/initstate 2>/dev/null | grep -v "live"双向比对模块状态，异常模块可能不显示在lsmod但存在于/proc/modules - 检查
/lib/modules/$(uname -r)/extra/和/lib/modules/$(uname -r)/updates/下是否存在未知.ko文件，尤其是文件名含drv、mod、hook或随机字符串的 - 运行
find /lib/modules -name "*.ko" -exec modinfo {} \; 2>/dev/null | grep -E "(description|author|license)" | grep -i -B1 -A1 "unknown|rootkit|reptile|beurk"快速筛出可疑元信息
检查 rkhunter 和 chkrootkit 自身是否被污染
这两款工具都是 Perl 或 C 写的本地扫描器，一旦系统被深度控制，它们的二进制、脚本、甚至配置文件都可能被修改，导致“扫自己却报干净”。
- 确认
rkhunter路径真实性和完整性：which rkhunter→ls -l $(which rkhunter)→sha256sum $(which rkhunter)，再与官网发布哈希比对 - 检查
rkhunter的数据库是否被篡改：ls -l /var/lib/rkhunter/db/，重点看filehashes.dat修改时间是否早于疑似入侵时间 -
chkrootkit默认不校验自身，且会释放临时二进制到/tmp执行；若/tmp挂载了noexec，它会静默跳过关键测试（如chkproc），输出大量TESTING而非结论 - 运行
sudo chkrootkit -x | grep -E "(INFECTED|WARNING|TESTING)"，重点关注重复出现的bindshell、sniffer、ifconfig模块结果，它们比单次INFECTED更值得深挖
内存与启动项中藏得最深的残留点
很多 Rootkit 在清除后仍通过 initramfs、GRUB 配置或 systemd 服务实现开机复活，这类残留不会出现在文件扫描或进程列表里，但每次重启都会重建后门。
- 检查 initramfs 是否被注入：
lsinitrd /boot/initramfs-$(uname -r).img | grep -E "\.(ko|sh|bin)"，尤其注意非标准路径下的模块 - 审查 GRUB 启动参数：
cat /proc/cmdline看是否有异常init=/bin/bash或rd.driver.preload=加载可疑驱动 - 排查 systemd 持久化项：
systemctl list-unit-files --type=service | grep -E "enabled|disabled" | grep -i -E "(backdoor|shell|remote|auto)"，再查对应 service 文件内容 - 检查 crontab 和 at job：
crontab -l（当前用户）、sudo crontab -l（root）、sudo ls -la /etc/cron.*、sudo atq
真正难清理的不是某个 .ko 文件，而是那些让检测失效的底层机制——比如被篡改的 syscall_table、挂载在 /proc/sys/kernel/modprobe 的恶意路径、或早已写死在 eBPF map 里的隐藏钩子。这些无法靠特征扫描发现，只能靠行为反推：如果静态 busybox 能看到而系统命令看不到的进程持续存在，那说明内核调用已被劫持，此时该考虑重装内核或整机恢复，而非继续“查”。
