应检查/etc/pam.d/sshd和/system-auth等文件是否被篡改，重点排查含pam_exec.so、pam_permit.so及宽松策略的auth行；同时校验pam_unix.so等核心模块的哈希值与官方一致性。
确认 /etc/pam.d/ 下哪些文件被篡改过
攻击者常修改 /etc/pam.d/sshd 或 /etc/pam.d/system-auth，插入万能密码逻辑（比如 auth [success=done default=ignore] pam_exec.so /tmp/.backdoor.sh）。这类改动不会改变文件大小或 mtime，但会破坏认证流程的预期顺序。
实操建议：
- 用
rpm -V openssh-server（CentOS/RHEL）或dpkg --verify openssh-server（Debian/Ubuntu）校验原始包配置文件是否被改 —— 注意：只对包管理器安装的 PAM 配置有效，手动修改的/etc/pam.d/custom-service不在此列 - 逐行比对关键文件与已知基线：
diff -u /etc/pam.d/sshd /backup/pam.d/sshd.bak。没备份？可从同版本干净镜像中提取标准配置作参考 - 重点盯
auth类型行，尤其是含pam_exec.so、pam_permit.so、auth [default=ignore]这类宽松策略的语句 —— 正常系统极少直接用pam_permit.so做主认证
检查 PAM 模块本身是否被替换
万能密码后门更常见于底层模块（如 pam_unix.so），而非配置文件。一旦模块二进制被替换成带后门的编译版，所有引用它的服务（sshd、su、login）都会受影响，且配置文件里完全看不出异常。
实操建议：
- 运行
md5sum /lib64/security/pam_unix.so（RHEL/CentOS）或md5sum /lib/x86_64-linux-gnu/security/pam_unix.so（Debian/Ubuntu），与官方包提供的哈希比对。别信本地 rpm/dpkg 数据库 —— 攻击者可能已篡改数据库 - 用
strings /lib64/security/pam_unix.so | grep -i "fuckyou\|pam\|sshlog"快速扫描硬编码的万能密码或日志路径 —— 大量后门会直接把密码明文写进二进制 - 检查模块依赖：
ldd /lib64/security/pam_unix.so。异常输出（比如指向/tmp/.libz.so）说明被 LD_PRELOAD 类手法劫持
验证 PAM 认证链是否绕过 shadow 校验
真正的 PAM 后门往往不记录日志、不报错，只是在某个条件满足时悄悄返回 PAM_SUCCESS。单纯看登录成功与否无法判断，必须主动触发测试。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
实操建议：
- 用非 root 用户尝试万能密码登录：
ssh -o PubkeyAuthentication=no user@host，密码输pam、fuckyou、123456等常见后门口令 —— 注意关掉密钥登录，避免干扰 - 临时启用 PAM 调试：
echo 'auth [default=1 success=ignore] pam_echo.so debug msg="PAM auth step: $PAM_TYPE">> /etc/pam.d/sshd，再登录观察/var/log/secure是否出现该日志 —— 若没输出，说明认证根本没走完预期链路 - 用
pamtester sshd user authenticate（需装pamtester包）脱离 SSH 进程单独测认证模块，输入可疑密码看返回值是否异常为PAM_SUCCESS
为什么不能只靠 grep 日志或进程排查
因为 PAM 后门运行在用户态认证阶段，不启新进程、不监听端口、不写常规日志。它就藏在 sshd 进程的内存里，执行完立刻释放上下文。你用 ps、netstat、journalctl 都看不到它——除非它自己主动落盘（比如往 /tmp/.sshlog 写密码）。
所以最危险的点是：你查遍了进程、端口、定时任务、启动项，却漏掉了 /lib64/security/pam_unix.so 文件本身的二进制完整性。这个文件只要被换掉一次，所有基于 PAM 的登录方式就全失效。
