核心要点（TL;DR）
- 先隔离取证再清理，直接删文件会丢失溯源线索。
- 首页篡改多为WebShell或模板注入，重点查可写目录与上传点。
- 用find按时间与权限筛异常文件，比全盘扫描更快定位。
- 溯源看访问日志中的POST与异常UA，锁定上传与执行入口。
凌晨收到监控告警，打开网站发现首页被替换成博彩页面，或者被插入一段跳转代码——这是运维和站长最不愿面对的场景。很多人第一反应是删文件、重装系统，结果入口没找到，几天后又被篡改一次。本文按实战顺序给出6步应急处理与溯源思路，每步都附可执行命令和检查清单，帮你既恢复首页，又找到真正的入侵入口。
第一步：隔离取证，别急着删文件
首页被篡改挂马后，最先要做的是控制影响面并保留证据。直接删除被篡改文件会让溯源失去最关键的时间点和内容特征。
- 记录发现时间、篡改页面完整源码（
cp index.php /root/evidence/index.php.bak），截图保存。 - 将站点切换为维护页，或临时下线解析，避免继续向访客投放恶意代码。
- 导出近7天Web访问日志、系统登录日志（
last、/var/log/secure）到独立目录。 - 若涉及用户数据或支付，同步启动内部通报流程。
取证阶段不要重启服务、不要批量删除文件，否则内存中的异常进程和文件时间戳都会丢失。
第二步：定位篡改点，判断是文件还是链路
先确认篡改发生在源站文件、数据库还是解析链路，方向错了后面全是无用功。
- 直接登录服务器查看首页文件内容：
tail -n 50 /www/wwwroot/site/index.php，搜索iframe、script、eval等可疑片段。 - 用
curl -I http://127.0.0.1对比本机与公网返回内容，若本机正常而公网异常，优先怀疑CDN、DNS或反向代理被劫持。 - 检查数据库中的文章、配置表是否被写入恶意脚本，CMS类站点常见于模板表与SEO配置表。
- 核对文件修改时间：
stat index.php，与告警时间比对。
第三步：查杀WebShell与后门文件
首页被篡改通常伴随WebShell存在。按“时间+权限+特征”三个维度筛查效率最高。
find /www/wwwroot -type f -mtime -7 -name "*.php" -ls find /www/wwwroot -type f -perm 777 -ls grep -rniE "eval\(|assert\(|base64_decode\(|$_POST\[" /www/wwwroot --include=*.php
- 重点检查上传目录、缓存目录、图片目录中出现的php/jsp文件。
- 检查
.htaccess、web.config是否被加入伪静态劫持规则。 - 用D盾、河马等工具交叉扫描，人工复核工具报出的高危文件。
- 对确认的WebShell先改名隔离而非直接删除，保留样本用于溯源。
第四步：清除恶意代码并恢复首页
清理要彻底但可回滚。建议先整站打包备份，再动手修改。
- 从可信备份或版本库恢复被篡改的首页与模板文件。
- 删除确认的WebShell与异常文件，清理计划任务：
crontab -l、ls -l /etc/cron.*。 - 检查启动项与异常进程：
ps aux --sort=-%cpu | head，核对/etc/rc.local。 - 重置CMS后台、数据库、FTP、SSH全部口令，并强制下线所有会话。
- 清理后再次全量扫描，确认无残留后恢复站点访问。
第五步：修复入口漏洞，堵住再次被黑的路径
不清除入口，清理只是延迟下一次被黑。按以下清单逐项核对：
| 检查项 | 风险点 | 处置动作 |
|---|---|---|
| CMS与插件版本 | 已知漏洞被批量利用 | 升级到最新稳定版 |
| 上传功能 | 任意文件上传 | 限制后缀、重命名、目录禁执行 |
| 后台入口 | 弱口令、无验证码 | 改口令、加二次验证、限制IP |
| 目录权限 | 777可写可执行 | 改为755/644，属主统一 |
| 数据库账号 | 高权限直连 | 最小权限、仅本地访问 |
在源站前部署WAF可拦截大部分上传与注入尝试，AegisX的Web防护与恶意文件检测能力可在这一层做兜底，减少人工排查压力。
第六步：日志溯源，还原入侵时间线
溯源目标是找到“第一个WebShell是怎么写进来的”。以篡改时间为锚点向前推24到72小时。
- 筛POST与上传请求：
grep -E "POST|upload" access.log | awk '{print ,}' | sort | uniq -c | sort -rn | head。 - 关注异常User-Agent、扫描器特征路径、后台登录成功记录。
- 关联系统日志中的异常登录与提权行为，检查是否被横向移动。
- 整理时间线：首次写入时间、来源IP、利用的接口与漏洞，形成书面报告。
若确认是批量扫描利用已知漏洞，建议封禁来源网段并持续观察一周。
行动建议
首页被篡改挂马不是“删掉就好”的问题，而是完整的应急响应流程：先取证隔离，再定位篡改点，查杀WebShell，彻底清理恢复，修复入口漏洞，最后用日志还原入侵路径。建议把这6步整理成团队检查清单，平时做好异地备份、最小权限和WAF防护，真出事时才能按流程快速止损。
常见问题（FAQ）
网站首页被篡改后，第一步到底该做什么？
第一步是隔离与取证，而不是立刻删除被篡改文件。先记录篡改时间、备份被篡改页面源码与服务器当前状态，再视情况将站点切到维护页或下线解析。保留原始文件与日志，后续定位入口和报案都依赖这些证据。
怎么快速找到网站里的WebShell？
优先按时间与权限筛查：用find定位近期修改的php/jsp文件，检查上传目录、缓存目录中权限为777或属主异常的文件，再结合grep搜索eval、assert、base64_decode等危险函数。最后用D盾、河马等工具交叉扫描确认，避免漏杀。
首页被篡改一定是服务器被入侵了吗？
不一定。常见原因还包括CMS后台弱口令被登录、模板文件被直接编辑、DNS或CDN被劫持、以及第三方JS被污染。排查时应先确认篡改发生在源站文件还是解析链路，再决定是查服务器还是查域名与CDN配置。
清理完恶意代码后如何防止再次被黑？
必须修复真实入口：升级CMS与插件、修改全部后台与数据库口令、关闭不必要的上传与执行权限、限制目录禁止脚本执行，并在源站前部署WAF。只清文件不补漏洞，通常几天内会再次被篡改。
溯源时重点看哪些日志？
重点看Web访问日志中的POST请求、异常User-Agent、上传接口调用与后台登录记录，结合系统登录日志与定时任务变更。按篡改时间向前推24到72小时，定位首次写入WebShell的请求IP与路径，再关联其他服务器排查横向移动。