你清除了网站的木马文件，改了所有密码，觉得安全了。一周后，木马又回来了。你开始怀疑：是不是后门没清干净？很多入侵事件中，攻击者不会只留一个后门。他们会在不同的角落藏好几个备用后门，等你清理掉一个，还有另一个在暗中运行。
今天讲5个步骤，帮你系统排查WebShell。
WebShell是什么
WebShell是以PHP、JSP、ASP等脚本文件形式存在的命令执行环境，黑客通过Web访问它，就能控制你的服务器。通常放在正常的Web目录里，伪装成普通文件。
第一步：找特征文件
黑客喜欢把WebShell藏在容易忽略的地方，比如临时目录（/tmp）、图片上传目录，或使用混淆文件名（如system.php、shell.php、1.jpg.php）。
目标：找出创建时间、修改时间、所有者与正常文件明显不符的异常文件。WebShell通常由Web进程创建，文件所有者往往是www-data或apache，而非管理员。
bash
# 最近7天被修改的PHP文件 find /var/www/html -name "*.php" -mtime -7 -type f # 检查包含可疑函数的文件 grep -r --include="*.php" -E "(eval|base64_decode|assert|system|exec|passthru|shell_exec|gzinflate)" /var/www/html
注意WebShell可能使用多层编码隐藏自身，如base64_decode嵌套gzinflate，或使用str_rot13绕过简单匹配。
第二步：查看异常文件权限与所有者
WebShell通常通过Web服务漏洞上传，文件所有者和Web进程用户一致（如www-data或apache）。检查/uploads/、/images/等本应只有图片的目录，是否存在PHP、JSP等可执行脚本。
bash
# 检查上传目录中的可执行文件 find /var/www/html/uploads -name "*.php" -type f # 检查没有正常扩展名但被执行的文件 find /var/www/html -type f -name "*.php.ppp" -o -name "*.php.*"
有时攻击者会把.ppp配置为可执行扩展，*.php.*的文件也可能被解析。
第三步：从Web访问日志排查
如果已确定木马存在的时间点，查对应时段的Web日志：
bash
grep "2026-06-20" /var/log/nginx/access.log | grep -E "\.php|\.jsp"
重点特征：
如果文件在日志中出现的时间段内没有任何正常业务访问，而WebShell被反复调用，几乎可以确定是后门。
第四步：检查定时任务和后门持久化
清理掉WebShell后，如果没过几天又出现，通常是因为有定时任务在自动下载。黑客常用crontab添加定时任务，定期从远程服务器拉取木马。
bash
cat -A /var/spool/cron/crontabs/root
用crontab -l有时看不到隐藏内容，用cat -A能显示不可见字符，发现被隐藏的恶意定时任务。还要检查/etc/cron.d/、/etc/cron.hourly/等目录。
另一种持久化方式：修改.bashrc或/etc/profile，每次用户登录时自动执行恶意脚本。
bash
cat /root/.bashrc | grep -E "(curl|wget|python|perl)"
如果发现不明外联请求，用netstat -anpt查看活跃连接，结合微步在线等威胁情报平台查询可疑IP是否被标记为C2或矿池地址。
第五步：检查隐藏进程和目录挂载
bash
cat /proc/$$/mountinfo | grep -E "(tmp|\.k|\.s)"
如果发现恶意进程，先解除挂载umount /proc/可疑PID，再杀掉进程、删除文件。
同时检查/tmp、/var/tmp、/dev/shm等临时目录，攻击者经常把木马文件放在这里：
bash
ls -la /tmp/ ls -la /var/tmp/
真实案例
一个WordPress网站被上传了WebShell，清理后第二天又出现。排查发现/var/spool/cron/crontabs/root里有一条定时任务，每5分钟从某IP下载shell.php并重命名为system.php。删除定时任务和恶意文件，升级所有插件，再也没复发。
最后一句
排查WebShell的逻辑很简单：找出不认识的、不该有的、不该被执行的东西。关键是把5个步骤串起来。如果你已经掌握了文件查找、日志分析和进程检查的方法，下次再看到system.php时，就不会慌张了。那只是一个文件，而你正在准备彻底清除它。