木马查杀需绕过宝塔界面，直查文件、日志、配置、数据库四层：用find+grep筛小PHP木马；交叉分析access.log/error.log定位调用链；检查.user.ini篡改与数据库JS注入；验证Nginx二进制是否被劫持。
宝塔面板自带的「木马查杀」插件只能发现浅层特征，对混淆、分段加载、无文件型、内存驻留型木马基本无效；真要深度排查，必须绕过界面，直击文件、日志、配置、数据库四层现场。
用 find + grep 快速筛出高危小 PHP 文件
攻击者倾向把木马塞进可写目录（/upload/、/cache/、/templates/），并压缩成不到 50KB 的小文件，靠名字伪装（如 icon.jpg.php、index.php.bak）躲过常规扫描。
- 直接在 SSH 执行：
find /www/wwwroot -name "*.php" -type f -size -50k -exec grep -l "eval\|base64_decode\|gzinflate\|str_rot13\|file_get_contents.*http" {} \; 2>/dev/null - 命中结果别急着删，先用
head -n 20 文件路径看开头——解密逻辑和载荷通常就藏在这儿 - 注意双写绕过：比如
sy<code>stem(或as<code>sert(，得手动搜ystem、sert这类片段
交叉比对 access.log 和 error.log 定位真实调用链
单看 access.log 只知道“谁来了”，但看不出“干了什么”。被黑后必须把三类日志串起来看，才能还原攻击者怎么进来的、从哪执行的。
- 在
access.log中搜你刚筛出的可疑文件名，重点关注POST请求（比如POST /cache/shell.php） - 记下时间戳，去
/www/wwwroot/your-site.com/runtime/log/（ThinkPHP）或/wp-content/debug.log（WP 开启 DEBUG 后）里找同一时刻的报错——常暴露真实后门路径或解密失败堆栈 - 再翻
/www/server/nginx/logs/error.log，看有没有PHP message: PHP Warning: file_get_contents(http://...)这类远程拉取痕迹
检查 .user.ini 和数据库字段里的“无文件”后门
很多木马根本不落地：靠篡改 .user.ini 绕过 open_basedir，或把恶意 JS 注入数据库字段，页面一刷新就自动执行。
- 进每个站点根目录，运行
ls -la | grep user.ini，再cat .user.ini—— 正常应含open_basedir=/www/wwwroot/xxx:/tmp/:/proc/；若为空、被删、或写成/，就是已被篡改 - 导出全库 SQL，在文本编辑器里全局搜：
<script></script>、iframe src=、document.write、eval(—— 尤其盯wp_posts.post_content、dede_arctype.typename这类模板/内容字段 - 宝塔「网站 → 设置 → 网站目录」里必须勾选「禁止访问
.user.ini文件」，否则攻击者上传新.user.ini就能覆盖所有限制
验证 Nginx 二进制是否被劫持（2025 年底起高发）
挂马不止发生在 PHP 文件里。近一年大规模爆发的 Nginx 劫持，是直接替换 /www/server/nginx/sbin/nginx 二进制，让所有响应自动注入 JS 脚本（常见特征含 _0xd4d9 或 waf_sc）。
- 第一件事不是扫 PHP，而是运行官方检测脚本：
curl -sSO https://www.php.cn/link/8dda4f8ad13f00fbc214ee90dbcd2665 && btpython w_check.py && rm -rf w_check.py - 如果报告异常，立刻备份当前
nginx文件，然后从宝塔「软件商店 → Nginx → 卸载重装」，不要手动覆盖 - 重装后检查
nginx -V 2>&1 | grep configure输出，确认没有额外添加的非标准模块路径
真正难防的不是明面上的 shell.php，而是藏在 .user.ini 里的配置劫持、数据库字段里的 JS 注入、以及被替掉的 Nginx 二进制——这三处不查，清理完也会在几小时内复发。
