真实入口常藏于可写目录如/cache/、/upload/，伪装成bak或配置文件；需用find命令筛查小PHP文件，检查access.log、数据库JS注入、.user.ini及php.ini配置，并严格限制目录权限与PHP函数。
先定位真实入口，别急着删文件
挂马后最常见错误是直接删除 shell.php 或 1.php 就以为完事——但攻击者很可能已通过数据库、定时任务或隐蔽的 .user.ini 持久化控制权。真实入口往往藏在：/www/wwwroot/your-site.com/cache/、/upload/、/images/ 这类可写目录里，名字伪装成 index.php.bak、wp-config.php（内容却是 eval(base64_decode(...))）。
- 用这条命令快速筛出高危小文件：
find /www/wwwroot -name "*.php" -type f -size -50k -exec grep -l "eval\|base64_decode\|gzinflate\|file_get_contents.*http" {} \; 2>/dev/null - 发现可疑文件后，别只看文件名，用
head -n 20 文件路径查看开头——木马常把解密逻辑藏在前几行 - 重点检查
access.log中对这些文件的 POST 请求，时间点常和管理员登录异常吻合
查完文件还得查数据库和配置项
很多木马不落地，而是把恶意 JS 注入到数据库的 content 字段或模板字段里，刷新页面就自动加载；还有些通过修改 php.ini 或站点根目录下的 .user.ini 绕过限制。
- 导出数据库 SQL 文件，用文本编辑器全局搜索：
<script>、iframe src=、document.write、eval( - 检查每个站点的
.user.ini是否被篡改：正常应含open_basedir=/www/wwwroot/xxx:/tmp/:/proc/，若为空或指向/就是危险信号 - 进宝塔「软件商店 → PHP → 设置 → 配置修改」，确认
disable_functions已填满：system,exec,passthru,shell_exec,proc_open,popen,assert,call_user_func——PHP 7.4+ 默认为空，极易被忽略
清理后立刻堵住复活通道
删完木马却没收紧权限，等于给攻击者留了扇虚掩的门。宝塔界面看着方便，但底层仍是 Linux 权限模型，必须手动加固。
- 在「网站 → 设置 → 网站目录」中，确保勾选「禁止访问 .user.ini 文件」——否则攻击者上传新
.user.ini就能覆盖 open_basedir - 每个站点绑定独立 FTP 账号，并严格启用「限制登录目录」，避免一个站沦陷拖垮全部
- 把
/www/wwwroot/your-site.com/templates/、/caches/这类目录的 Nginx 配置加上：location ~ \.php$ { deny all; }，彻底禁止执行 PHP - 重启对应 PHP 版本服务（宝塔里点「服务 → 重启」），否则
php.ini修改完全不生效
别信“一键查杀”，日志和权限才是关键证据
护卫神、D盾、河马这些工具能扫出 70% 明显 Webshell，但绕过检测的混淆木马（比如用 str_rot13 套娃解密）或内存马根本不会落盘。真正可靠的线索永远在服务器日志和权限设置里。
tail -f /www/wwwlogs/your-site.com.log | grep "POST.*\.php"——盯住非业务路径的小 PHP 文件被 POST 调用ls -la /www/wwwroot/your-site.com/查看最近修改时间异常的文件，尤其是cache/和upload/下的 PHP- 检查是否开了
allow_url_fopen = On，这是远程加载木马的温床，关掉它几乎不影响现代 PHP 项目
最常被跳过的一步：改完所有配置后，一定要用 php -i | grep disable_functions 和 grep open_basedir /www/server/php/80/etc/php.ini 实际验证生效状态——面板上点了保存，不代表 PHP 进程读到了。
