LD_PRELOAD后门本质是滥用动态链接预加载机制实现函数劫持，通过覆盖malloc、connect等libc函数达成隐蔽持久化；排查需重点检查/etc/ld.so.preload文件、进程environ变量、可疑.so符号及内存映射行为。
Linux 上的动态库预加载劫持后门，本质是滥用 LD_PRELOAD 或 /etc/ld.so.preload 机制实现函数覆盖，不改二进制、不启新进程、难被常规杀软捕获。它不像 rootkit 那样深入内核，但比普通木马更隐蔽——ps 看不到它，netstat 查不到它的连接，连 lsof -p 都可能漏掉被劫持的内存分配行为。
检查 /etc/ld.so.preload 是否被篡改
这是最直接、最常被利用的全局劫持入口。该文件每行一个绝对路径，系统启动所有动态链接程序前都会强制加载其中的 .so 文件。
- 执行
ls -l /etc/ld.so.preload：若文件存在且非空，立刻检查内容；若权限异常（如可写但属 root），高度可疑 - 用
file /path/to/lib.so检查每个条目是否为合法ET_DYN类型共享库；若报错cannot be preloaded: ignored，说明该条目曾被尝试注入但失败，需追溯日志 - 对比已知可信基线：比如从干净镜像或备份中提取该文件哈希，运行
sha256sum /etc/ld.so.preload核对 - 注意隐藏字符：攻击者可能在行尾加空格、制表符或 Unicode 零宽字符绕过简单
cat查看，建议用xxd /etc/ld.so.preload或od -c /etc/ld.so.preload检查原始字节
扫描进程级 LD_PRELOAD 环境变量残留
全局配置容易被发现，但攻击者更倾向用 LD_PRELOAD 环境变量单点注入关键服务（如 sshd、nginx、数据库），尤其配合 cron、systemd service 或 shell 启动脚本持久化。
- 对重点进程查环境：
cat /proc/<pid>/environ | tr '\0' '\n' | grep LD_PRELOAD</pid>；别只查主进程，也查子进程（如 nginx worker、php-fpm child） - 检查 systemd 服务定义：
systemctl show --property=Environment <service-name></service-name>和systemctl cat <service-name></service-name>，留意Environment=LD_PRELOAD=...或ExecStartPre中的导出操作 - 排查用户级持久化：检查
~/.bashrc、~/.profile、/etc/profile.d/*.sh中是否含export LD_PRELOAD=，特别是伪装成“性能优化”或“调试工具”的注释 - 注意变量继承链：某个父进程设了
LD_PRELOAD，其 fork 出的所有子进程都会继承——哪怕你没在子进程启动命令里显式写
识别被劫持的 libc 函数调用行为
预加载后门通常 hook malloc、free、connect、sendto、getaddrinfo 等函数，用于内存窃取、网络隧道或 DNS 劫持。不能只看“有没有加载”，要看“它干了什么”。
- 用
ltrace -e "malloc+free+connect+sendto+getaddrinfo" -p <pid></pid>实时观察函数调用流向；若看到大量异常地址返回、超长参数或非预期目标 IP，立即暂停进程并取证 - 检查符号覆盖：运行
objdump -T /lib/x86_64-linux-gnu/libc.so.6 | grep "malloc\|free"获取 libc 原始符号地址，再用cat /proc/<pid>/maps</pid>找出预加载库的内存段，用gdb --pid <pid></pid>附加后执行info proc mappings+x/10i <malloc_addr></malloc_addr>确认是否跳转到可疑地址 - 警惕“无文件”注入：有些后门不落地
.so，而是通过memfd_create+mmap在内存中构造共享库并dlopen，此时/proc/<pid>/maps</pid>会出现[anon:.so]或memfd:字样段，需结合strace -e trace=memfd_create,mmap,dlopen -p <pid></pid>捕获
验证 preload 服务是否被滥用于启动恶意库
preload 服务本身安全，但攻击者可能伪造其白名单或修改 /etc/preload.conf 引导它提前加载恶意库的代码段——虽然它不劫持函数，却能提升后门加载速度和隐蔽性。
- 确认服务状态：
systemctl is-active preload；若未启用却被攻击者手动启动过，检查journalctl -u preload --since "2 weeks ago"中有无异常日志 - 检查白名单生成逻辑：
ls -la /var/lib/preload/下的preloads和cache文件，用strings提取其中的二进制路径，确认是否包含非系统路径（如/tmp、/dev/shm、/var/tmp） - preload 不会加载任意
.so，但它会预读常用程序的代码页；若发现vim、ls等小工具的 cache 文件体积异常大（>10MB），可能是被注入了额外数据段 - 真正危险的是把恶意
.so放进 preload 白名单并诱导系统频繁调用——比如写个假/usr/local/bin/ssh-wrapper，让 preload 把它和某个恶意库一起缓存，下次调用就更快落地
预加载后门最难缠的地方不在技术多高深，而在于它混迹于合法机制之中：同一套 LD_PRELOAD，运维用来调试内存泄漏，攻击者用来偷凭证。排查时别只盯着“有没有”，要盯“谁在用、何时用、用在哪几个进程、加载的库是否经过签名或哈希校验”。没有自动化的银弹，只有对每个可疑路径做字节级确认的习惯。
