PHP后门需人工逐层验证，不可依赖一键扫描：查文件时间戳异常（stat对比Modify/Change）、搜混淆函数组合（base64_decode/gzinflate等）、审动态执行函数（assert/call_user_func）、检Web服务器配置劫持（.htaccess/Nginx）、查数据库恶意选项或含PHP标签的内容。
PHP后门不能靠“一键扫描工具”彻底清除，尤其是混淆过、嵌套在正常业务逻辑里的后门——必须人工逐层验证可疑点。
怎么看文件修改时间异常
攻击者常改文件时间戳掩盖痕迹，但 Linux 下 stat 能暴露真实修改时间（不受 touch 伪造干扰）：
- 用
find /var/www -type f -name "*.php" -mtime -7找近 7 天新增或改动的 PHP 文件 - 对每个结果执行
stat -c "%y %n" filename.php，重点看Modify和Change时间是否不一致（Change更晚说明属性被人为调整过） - 忽略 CMS 自动更新产生的批量修改（如 WordPress 插件升级），聚焦孤立文件、无版本记录的文件、上传目录（
uploads/、cache/）下的 PHP 文件
怎么识别 base64+gzinflate 或动态函数调用类后门
这类后门不直接含 eval 或 system 字样，但运行时会解密执行任意代码：
- 搜索
base64_decode、gzinflate、str_rot13、urldecode组合出现的 PHP 文件：grep -r "base64_decode.*gzinflate|gzinflate.*base64_decode" /var/www --include="*.php" - 检查
call_user_func、call_user_func_array、create_function（PHP 7.2+ 已废弃）、assert（尤其参数是变量）的调用上下文——正常业务极少用这些函数动态执行字符串 - 发现类似
assert($_POST['x'])或eval(base64_decode($_GET['a']))的代码，直接删文件；若在核心文件里（如wp-includes/functions.php），先备份再删对应行，再校验官方 SHA256 值
怎么查隐蔽的 .htaccess 或 Nginx 配置劫持
后门不一定在 PHP 文件里，可能通过 Web 服务器配置把请求重写到恶意脚本：
立即学习“PHP免费学习笔记（深入）”；
- 检查网站根目录及子目录下的
.htaccess文件，搜RewriteRule+php或proxy:关键词，特别警惕匹配wp-admin或login但指向非标准路径的规则 - Nginx 用户检查
server块中是否有location ~ .php$ { fastcgi_pass ... }被篡改，或存在location / { proxy_pass http://127.0.0.1:xxx; }类似反向代理配置 - 对比当前配置与 Git 历史或备份中的原始版本，差异处优先审查
怎么确认数据库里没藏后门触发点
WordPress 等 CMS 常被注入恶意 option 或 post_content，通过钩子加载后门：
- 查 WordPress：执行 SQL
SELECT * FROM wp_options WHERE option_name LIKE '%theme%' OR option_value LIKE '%base64%' OR option_value LIKE '%eval%'；重点看theme_mods_*、active_plugins、auto_update_core等字段值是否被篡改 - 查所有含 PHP 标签的 post 内容：
SELECT ID, post_content FROM wp_posts WHERE post_content LIKE '%<?php %' OR post_content LIKE '%<script%' OR post_content REGEXP 'eval\(|system\(|shell_exec\(' - 数据库里清理后，立刻重置管理员密码、禁用未知插件、清空
wp_options中的recently_edited等缓存字段
真正难清除的不是明文后门，而是那些和业务逻辑混在一起的条件型后门——比如只在特定 User-Agent 或 Referer 下才解密执行，或者依赖某个未公开的 cookie key。这种必须结合 Web 日志回溯请求特征，再反向定位代码，不能只靠静态扫描。
