PHP后门清除需日志溯源、进程排查、权限审计和持久化检查，否则会复发；内存型后门通过eval()等函数运行，不落地文件，须查ps参数、php.ini配置、opcache状态及异常请求模式。
PHP后门不是靠“删文件”就能彻底清除的，必须结合日志溯源、进程排查、权限审计和持久化检查——否则删完半小时又回来。
怎么确认当前 PHP 进程是否被注入后门
很多后门不落地为独立 .php 文件，而是通过 eval()、assert()、create_function() 或动态加载（如 stream_wrapper_register()）在内存中运行。单纯查 Web 目录会漏掉。
- 用
ps aux | grep php看是否有异常参数，比如带-d auto_prepend_file=或指向非常规路径的-c配置 - 检查
php.ini中的auto_prepend_file、auto_append_file、extension_dir和已启用的扩展（php -m），特别留意非标准命名的 .so/.dll（如curl2.so、syslogx.so） - 运行
php --ri opcache，若opcache.enable开启但opcache.validate_timestamps=0，攻击者可能已缓存恶意 opcode，需重启 PHP-FPM 或清空 opcache（opcache_reset()）
Apache/Nginx 日志里哪些字段能锁定后门入口
关键不是看“有没有访问 shell.php”，而是找**异常请求模式**：高频、低 UA、无 referer、参数含 base64/十六进制/长 eval 字符串、URL 中混用大小写或双写编码（如 %253C%2573%2563%2572%2569%2570%2574）。
- Apache：
access.log里重点筛"POST.*HTTP/1.1" "Mozilla/4.0"（伪造旧 UA）、"GET.*base64_decode.*HTTP"、"POST.*eval.*\(".*HTTP" - Nginx：
log_format必须包含$request_body（需开启lua_need_request_body on;或用echo_read_request_body），否则 POST 内容不可见；否则只能靠$args抓 URL 参数里的可疑 payload - 别忽略
error.log：PHP Warning: preg_replace(): /e modifier is deprecated这类报错常出现在利用旧版正则后门的请求中；include(): open_basedir restriction异常绕过也可能暴露路径遍历尝试
Web 目录下哪些“看似正常”的文件其实高危
后门常伪装成备份、缓存、插件或 CMS 自生成文件，靠名字判断基本无效。
立即学习“PHP免费学习笔记（深入）”；
- 检查修改时间异常的新文件：
find /var/www -name "*.php" -type f -mtime -7 -ls（尤其注意wp-cache.php、cache_config.php、tmp_*.php） - 查找隐藏文件：
find /var/www -name ".*.php" -o -name ".php*"（如.user.ini可被用来设置auto_prepend_file，无需 PHP 重启） - 用
grep -r "eval\|assert\|system\|passthru\|exec\|shell_exec\|base64_decode\|gzinflate" /var/www --include="*.php"，但注意混淆变种：str_rot13、urldecode套娃、变量拼接（$a="e"."val"; $a(...)）
删完后必须验证的三件事
删文件只是第一步，没做这三步等于白干。
- 检查 crontab：
crontab -l和/etc/crontab，攻击者常用它每分钟 wget 新后门 - 检查用户启动项：
systemctl --user list-unit-files --state=enabled（Linux）或launchctl list（macOS），后门可能注册为用户级 service - 重置所有数据库账户密码，并查
mysql.user表里是否有非 root 的 super 权限账号（SELECT * FROM mysql.user WHERE Super_priv='Y';），部分后门通过数据库 UDF 持久化
最麻烦的不是找到后门，而是它可能改过 PHP 源码编译参数、打过内核模块补丁、或在 initramfs 里埋了钩子——普通运维手段够用的前提是：你还没被提权到 root 且没动底层。
