ld_preload隐藏的进程未消失，仅使ps/top等命令显示被篡改的/proc视图；须检查/etc/ld.so.preload、ld_preload环境变量、pam配置，定位已加载恶意so的进程，并用busybox/ss/strace/内核接口绕过劫持验证真实状态。
LD_PRELOAD 隐藏的进程本身不会“消失”，只是让 ps、top、ls 等命令看到的是被篡改后的 /proc 视图——所以不能只查进程列表，得绕过劫持验证真实状态。
检查 /etc/ld.so.preload 是否被篡改
这是系统级预加载入口，优先级高于环境变量，一旦存在即全局生效：
- 运行
ls -l /etc/ld.so.preload—— 正常应返回 “No such file”；若存在，且大小非零（如 18 字节），立即检查内容 - 执行
cat /etc/ld.so.preload 2>/dev/null，输出类似/tmp/.x.so、/var/run/ldhook.so或含随机字符路径，基本确认被写入 - 注意：该文件只认纯路径行，空格、
#注释或无效字符会导致加载失败，但攻击者可能故意填入“看似无害”的路径干扰判断
扫描 LD_PRELOAD 环境变量的异常注入点
环境变量影响范围更细粒度，常见于服务启动上下文，容易被漏掉：
- 当前会话中运行
echo $LD_PRELOAD，若指向/tmp、/dev/shm、./或用户家目录下的.so文件，高度可疑 - 检查 systemd 服务：用
systemctl show --property=Environment --all 2>/dev/null | grep PRELOAD，重点看sshd、crond、nginx等服务是否被硬编码设置 - 搜索 shell 初始化文件：
grep -r "LD_PRELOAD=" ~/.bashrc /etc/profile.d/ /etc/environment 2>/dev/null，特别留意export LD_PRELOAD=...这类持久化语句 - PAM 模块也常被利用：
grep -A5 "LD_PRELOAD" /etc/security/pam_env.conf，若出现DEFAULT=@{HOME}/.mal.so类规则，即为典型手法
定位已加载恶意库的真实进程（不靠 ps）
被劫持的进程名仍显示为合法服务（如 sshd、bash），但其内存中已映射恶意 .so：
- 先找可疑
.so路径：比如从/etc/ld.so.preload或$LD_PRELOAD中拿到路径/tmp/.logd.so - 确认它是否被进程加载：
grep -l "/tmp/.logd.so" /proc/[0-9]*/maps 2>/dev/null | cut -d'/' -f3，输出的 PID 就是已被劫持的进程 ID - 查该 PID 的真实身份：
cat /proc/PID/cmdline | tr '\0' ' '和ls -l /proc/PID/exe，重点关注sshd、login、bash、python等常驻或提权进程 - 若发现
sshd子进程（每个连接一个）加载了恶意库，说明认证链已被污染，需重启sshd服务而非仅 kill 单个进程
绕过劫持验证底层行为（关键验证步骤）
所有依赖 libc 的命令（ps、netstat、ls）都可能被篡改，必须用未被劫持的路径或工具交叉验证：
- 用静态链接版 busybox 验证监听端口：
busybox ss -tuln，对比ss -tuln输出差异；若 busybox 多出一个端口（如:4444），说明该监听正被隐藏 - 用
strace直接抓系统调用：strace -e trace=bind,listen -f -s 256 /usr/sbin/sshd -D 2>&1 | grep -E "bind|listen"，观察是否出现非常规地址绑定（如bind(3, {sa_family=AF_INET, sin_port=htons(5555), ...})） - 读内核原始接口：
cat /proc/net/tcp /proc/net/tcp6 2>/dev/null | awk '{print $2,$10}' | while read ip_port state; do echo "$ip_port $(printf "%d" 0x${state})"; done | grep "0000000A"（0A表示 LISTEN 状态），绕过所有用户态过滤
真正难处理的不是找到那个 .so，而是它可能已被多个关键进程加载，且删除前需确认没有服务正在动态调用它；lsof /path/to/malicious.so 有输出时，直接 rm 会失败，此时必须先终止对应进程或整机重启——这点最容易被忽略。
