linux排查隐藏进程需多维度交叉验证：检查/proc是否被篡改、使用静态ps或直接读取/proc、分析内核模块与ebpf、关联网络端口及定时任务、内存镜像分析，确保工具未被污染。
Linux中发现异常进程，尤其是隐藏进程，不能只依赖ps或top这类常规命令——因为恶意进程常通过rootkit、内核模块篡改系统调用、劫持procfs等方式绕过标准工具。排查需从用户态、内核态、文件系统、网络行为多维度交叉验证。
检查/proc目录是否被篡改
正常情况下，/proc是内核提供的虚拟文件系统，每个运行中的进程对应一个数字子目录（如/proc/1234）。但rootkit可能隐藏特定PID的目录，或伪造/proc内容。
- 用
ls -la /proc | wc -l统计总进程数，对比ps aux | wc -l结果是否明显偏少 - 手动遍历
/proc/[0-9]*，检查是否存在“空目录”（无exe、cmdline、status等关键文件）或权限异常（如属主为未知UID） - 执行
cat /proc/sys/kernel/pid_max确认PID上限，再用find /proc -maxdepth 1 -regex "/proc/[0-9]+" | wc -l看实际可见PID数量是否接近上限
绕过ps/top：使用原始系统调用或静态二进制
攻击者常hook libc的getdents64等函数，使动态链接的ps失效。可尝试更底层的方式：
- 用静态编译的
ps（如从干净环境拷贝）或busybox ps，避免依赖被劫持的glibc - 直接读取
/proc并解析：for pid in /proc/[0-9]*; do echo "$pid: $(cat $pid/comm 2>/dev/null)"; done | sort - 用
strace -f -e trace=clone,fork,vfork,execve ps aux 2>&1 | grep -E 'clone|execve'观察ps本身是否漏掉了fork事件
检查内核模块与系统调用劫持
隐藏进程常依赖恶意内核模块（LKM）或eBPF程序干扰进程列表生成逻辑：
- 运行
lsmod比对已知安全基线，关注名称可疑（如hide、root、knark、adore）或无签名模块 - 检查
/lib/modules/$(uname -r)/kernel/下是否有非官方模块，尤其extra/或updates/目录 - 用
sysctl kernel.modules_disabled确认模块加载是否被禁用（若为0，说明仍可加载）；结合dmesg | tail -50查看最近内核日志中是否有模块插入痕迹 - 检查eBPF程序：
bpftool prog list和bpftool map list（需bpftool支持），留意非系统路径加载的程序
关联行为分析：网络+文件+内存线索
即使进程名被隐藏，其行为仍会暴露线索：
- 用
ss -tunlp或netstat -tunlp查监听端口，再用lsof -i :PORT反查进程——若返回“can't identify protocol”或PID为空，极可能被隐藏 - 检查定时任务：
crontab -l、systemctl list-timers --all、/etc/cron.*/*、/var/spool/cron/，寻找启动可疑二进制的入口 - 扫描内存镜像（需提前配置）：
volatility -f memdump.raw linux_pslist（配合kdump或LiME采集），该方式不依赖/proc，可发现内核级隐藏进程 - 检查异常文件访问：
auditctl -w /bin -w /usr/bin -p wa -k bin_exec临时启用审计，再用ausearch -k bin_exec | ausearch -m execve追溯可疑执行链
排查隐藏进程本质是打破攻击者的“可见性控制”，核心在于用不同视角交叉印证。不要迷信单一命令输出，优先保证排查工具自身未被污染（如用静态二进制、离线镜像、可信宿主机远程分析），再结合行为特征缩小范围。
