📍 WDQWDWQD987AAAAA:216.73.216.230
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /68b7b31e579f.html
📄

网站恶意代码检测：异常开始时间怎样确定

确定异常开始时间，不能只看“第一次发现”的日期，而要用多份独立记录交叉验证：文件修改时间、服务器访问日志、搜索引擎抓取记录、页面存档和监控告警。取其中最早且能相互印证的时间点，作为异常开始时间的保守估计。

先区分三种时间：发现时间、植入时间、生效时间

这三个时间经常被混为一谈，判断结果会差出很多天。

• 发现时间：你或监控工具第一次看到异常页面、告警或跳转的时间。它只是调查起点，不是异常开始时间。
• 植入时间：恶意代码被写入文件或数据库的时间，通常对应文件修改时间、数据库写入记录。
• 生效时间：恶意代码开始对外输出内容、执行跳转或被搜索引擎抓取到的时间，通常对应访问日志和抓取记录。

排查目标是找到“植入时间”和“生效时间”中较早的那个，而不是发现时间。如果代码植入后长期未被访问，生效时间会明显晚于植入时间，此时应以植入时间为准。

按观察、判断、处理、复查四步定位

观察：先收集不改动

在清理之前先留证据，否则时间线会被自己破坏。需要收集的内容包括：

• 可疑文件的修改时间、创建时间、大小，用 ls -l --time-style=full-iso 或主机面板的文件时间列查看。
• Web 访问日志中可疑 URL 或可疑参数的首次出现记录，按时间排序取最早一条。
• 数据库内容型异常，查对应表的写入时间字段或 binlog。
• 搜索引擎抓取记录：在搜索控制台查看异常 URL 的首次抓取时间，或在网页存档服务中查看该页面的历史快照。
• 站内监控、备份、版本控制记录：如果项目使用 Git，用 git log -p --follow 文件路径 查看该文件最后一次正常提交的时间。

判断：用交叉验证缩小范围

单个时间戳不可靠，原因很多：文件被复制、打包、解压会重置修改时间；日志可能轮转或缺失；服务器时区与本地时区不一致。因此要遵循两条规则。

1. 取最早的可信时间。如果文件修改时间是 3 月 2 日，访问日志中恶意跳转首次出现在 3 月 5 日，页面存档在 3 月 4 日还是正常内容，那么植入时间应取 3 月 2 日，生效时间在 3 月 4 日至 5 日之间。
2. 多个来源指向同一时间才算确认。只有文件时间、没有日志和存档佐证时，只能作为“疑似植入时间”，需要继续找旁证。

假设一个例子：某页面 4 月 10 日的存档快照正常，4 月 12 日的快照出现异常脚本，文件修改时间为 4 月 11 日 02:17，访问日志中该脚本首次被请求是 4 月 11 日 09:40。此时可以判断异常开始时间在 4 月 10 日至 11 日 02:17 之间，保守取值 4 月 10 日之后、4 月 11 日凌晨之前。这是假设示例，实际以自己站点的记录为准。

还要注意时区统一。服务器日志常用 UTC，主机面板可能显示本地时间，比较前先换算到同一时区，否则会凭空多出或少了几个小时。

处理：记录判断依据再清理

清理前把时间线写下来：每个证据的来源、时间、指向的结论。清理时同步记录操作时间，便于后续复查时区分“原有异常”和“清理动作造成的改动”。如果异常涉及数据库内容，先导出相关记录再删除。

复查：验证时间线是否闭合

清理完成后，回到同一批证据上复查：

• 可疑文件是否已恢复为正常版本，修改时间是否更新为清理时间。
• 访问日志中是否还有对旧恶意路径的请求，首次请求时间是否早于你判断的植入时间。如果更早，说明时间线需要往前修正。
• 页面存档或抓取记录中，异常内容是否在判断的时间点之后才出现。
• 监控告警是否不再触发，持续观察一段时间再确认。

常见误判与对应的检查项

把发现时间当成开始时间，是最常见的错误，会导致遗漏更早被篡改的文件。备份文件、压缩包解压后的文件时间往往不可信，需要与版本控制记录对照。日志被轮转或清空时，不要直接断定“没有更早记录”，可以查备份日志、CDN 或反向代理日志、数据库 binlog 作为补充。

如果所有记录都缺失，只能给出一个区间而不是精确时间点，并在结论中写明依据不足。此时优先恢复最近一次可信备份，再通过对比备份与当前文件的差异，反推被改动的范围和时间线索。

下一步：把上面列出的证据来源整理成一张时间线表，按时间从早到晚排列，标出每条证据的可信度，再决定是否需要继续往前追溯。