PHP后门需综合权限审计、日志回溯和行为监控才能彻底清除，不能仅靠删除文件；其常伪装成备份或缓存文件藏于可写目录，特征包括异常修改时间、高危函数调用、非标准权限与极小体积。
PHP后门不是靠“删一次”就能解决的，它往往意味着系统已被长期渗透，单纯删除文件只是表面处理，必须结合权限审计、日志回溯和行为监控才能真正清除。
怎么识别可疑的PHP后门文件
后门文件通常伪装成正常文件，比如 wp-config.php.bak、cache.php、index1.php 或藏在 uploads/、cache/ 等可写目录下。它们常见特征包括：
- 文件修改时间与网站更新时间明显不符（例如深夜自动变更）
- 包含
eval(、base64_decode(、system(、shell_exec(、assert(、preg_replace(/e)等高危函数调用 - 文件名无意义但权限为
644或604，且属主是www-data或apache（而非部署用户） - 文件体积极小（几百字节），但实际执行逻辑复杂
Linux下快速全盘检索PHP后门的命令组合
别只依赖 find 扫描扩展名，要结合内容特征和路径风险等级。以下命令需在 Web 根目录或整个 /var/www 下谨慎运行：
find /var/www -type f -name "*.php" -size -200c -exec grep -l "eval\|base64_decode\|shell_exec\|system\|assert\|preg_replace.*[eE]" {} \; 2>/dev/null
说明：
立即学习“PHP免费学习笔记（深入）”；
-
-size -200c过滤超小文件（多数一句话后门在此范围） -
2>/dev/null屏蔽权限不足报错，避免干扰结果 - 若发现
uploads/目录下存在.php文件，直接视为异常（该目录应禁用PHP解析） - 注意：
preg_replace的/e修饰符在 PHP 7.0+ 已废弃，但仍有大量后门使用兼容写法如preg_replace('/.*/e', $_POST['x'], '')
子目录隐藏后门的典型藏匿位置和处理方式
攻击者常利用 CMS 插件机制、缓存目录、临时上传区或版本控制残留来隐藏后门，比如：
-
wp-content/plugins/advanced-cache.php（伪装成 WP Super Cache 的缓存文件，但实际是独立后门） -
themes/twentytwentythree/inc/compat.php（主题子目录中伪造的“兼容文件”） -
.git/hooks/pre-commit或.svn/wc.db附近新建的config.php（利用版本库目录绕过常规扫描） -
vendor/composer/autoload_static.php被注入恶意代码（Composer 自动加载机制易被篡改）
处理原则：
- 所有非标准路径下的
.php文件，先stat查看 ctime/mtime，再md5sum对比原始包哈希 - CMS 系统务必从官网重下完整安装包，用
diff -r对比核心目录，不要仅删“看着可疑”的文件 - 确认后门来源后，立即检查
access.log中对应时间点的请求，找上传入口（如未校验的头像上传、XMLRPC 接口、插件后台文件上传）
删完后门还可能反复出现？重点检查这几个地方
如果清理后不久又出现新后门，说明攻击链未切断：
- Web 服务器配置是否允许
.htaccess覆盖？攻击者可能通过上传恶意.htaccess开启php_flag engine on，让.jpg后缀也能执行PHP - 数据库里是否存有持久化后门？例如 WordPress 的
wp_options表中theme_mods_*或cron字段注入 base64 编码的代码 - 是否有定时任务残留？检查
crontab -u www-data -l和/etc/cron.d/下的非法条目 - PHP 的
auto_prepend_file是否被劫持？查看phpinfo()输出或php -i | grep auto_prepend
真正的清理不是找到一个文件就结束，而是把上传通道、执行环境、持久化手段全部堵死。否则删十次，第十一秒又回来。
