PHP后门需从权限链、执行入口和持久化痕迹三方面根除，而非仅删文件；重点检查编辑器篡改的functions.php等模板文件、动态解码后门、数据库option表及隐藏进程。
PHP后门不是靠“删文件”就能根除的，尤其编辑器漏洞（如 VS Code 插件、Sublime FTP 插件、WordPress 主题编辑器）生成的后门往往藏在合法文件里、混淆执行、或通过动态函数调用绕过静态扫描——直接删 shell.php 只是表象，真正要动的是权限链、执行入口和持久化痕迹。
检查哪些文件被编辑器漏洞篡改过
编辑器类后门（比如通过 WordPress 后台「外观 → 主题编辑器」或 FTP 插件上传）通常会修改已有 PHP 文件，在末尾追加或插入恶意代码块。重点盯这些位置：
-
functions.php（尤其是子主题或当前激活主题） -
index.php、header.php、footer.php等模板文件底部 -
wp-config.php（常被注入eval(base64_decode(...))或create_function） - 所有最近 7 天内
mtime或ctime异常变更的 PHP 文件（用find /var/www -name "*.php" -mtime -7 -ls快速定位）
别只搜 system( 或 exec( —— 攻击者早改用 call_user_func、array_map、preg_replace('/.*/e')（PHP 5.5+ 已废但仍有旧环境）、甚至字符串拼接绕过关键字检测。
识别并清除动态加载型后门（eval + base64 + gzinflate 套娃）
这类后门不显眼，整段代码像随机字符串，实际是多层解码后才触发 shell。典型特征：
立即学习“PHP免费学习笔记（深入）”；
- 单行超长字符串（>200 字符），含
base64_decode、gzinflate、str_rot13组合 - 变量名伪装成配置项：如
$wp_v、$wp_d、$wp_f - 出现在
if(0)、if(false)包裹块里，或紧跟注释末尾（如// end of theme后直接跟恶意代码）
实操建议：把可疑文件丢进在线 PHP 解混淆工具（如 unphp.net），但更稳妥的是本地用 php -r "echo base64_decode('xxx');" 逐层还原；确认是 shell 后，**不要只删那一行**——先查该文件是否被其他文件 include 或 require，再检查数据库 option 表（wp_options）里有没有存着动态代码（如 theme_mods_ 或 custom_css 字段）。
堵住编辑器漏洞入口（WordPress 最常见）
后门反复出现，90% 是因为后台编辑权限没关死。WordPress 默认允许管理员通过「外观 → 主题编辑器」修改任意 PHP 文件——这等于给攻击者留了白名单级后门通道：
- 在
wp-config.php加上define('DISALLOW_FILE_EDIT', true);（强制禁用后台编辑器） - 删除不用的主题/插件，尤其名称带
backup、test、child的——很多是攻击者上传的傀儡主题 - 检查用户列表：
SELECT * FROM wp_users WHERE user_login NOT IN ('admin', 'your_real_user');，删掉未知管理员账号 - 禁用 FTP 插件自动写入权限：确保
wp-content目录属主是 web server 用户（如www-data），而非ftpuser，且权限不高于755（目录）/644（文件）
VS Code / Sublime 的 FTP 插件若保存凭据在明文配置里，也会被拖库复用——检查 .vscode/settings.json 和 SFTP-config.json 是否硬编码了服务器密码。
后门可能不在 PHP 文件里——查数据库和隐藏进程
高级后门会避开文件系统，把 payload 存进数据库或内存：
- 查
wp_options表中option_name含theme_mods、widget、_transient的记录，用HEX(option_value)看是否有可疑 base64 片段 - 运行
ps aux | grep -i "php.*-r"，找非常规命令行 PHP 调用（如php -r "eval($_POST[x]);"） - 检查 crontab：
crontab -l和/etc/crontab，看是否有每分钟 curl 某个远程 PHP 的任务 - 用
lsof -i :80或netstat -tulpn | grep :80确认没有非 Apache/Nginx 进程在监听 HTTP 端口
最麻烦的是 WebShell 通过 fsockopen 或 cURL 回连 C2，流量混在正常请求里——这时候得看 access.log 里高频访问的非常规路径（如 /wp-includes/js/tinymce/wp-tinymce.php?x=1），再结合时间戳比对对应 PHP 文件的修改时间。
