网站木马扫描：怎样记录变更与复盘
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0239de635d2e.html
📄
网站木马扫描：怎样记录变更与复盘
把每次网站木马扫描当成一次可追溯的运维事件来记录：扫描前保存当前文件与数据库状态，扫描中记录工具、范围、时间和命中结果，处理后记录删除或隔离了哪些文件、改了哪些配置，复查时用同一范围和同一工具再扫一遍并对比差异。这样做的目的不是留痕本身，而是当木马再次出现时，能判断它是残留、重新入侵，还是误报。
观察：扫描前先固定基线
没有基线的扫描记录几乎无法复盘。开始扫描前，至少固定三项内容：
- 文件层面：记录核心目录的文件数量、最近修改时间分布，或对整站做一次哈希清单。可用
find配合sha256sum生成列表并保存到站外。 - 数据层面：导出当前数据库结构，记录用户表、文章表等关键表的行数。
- 环境层面：记录 Web 服务器版本、PHP 或运行环境版本、已安装插件或扩展及其版本号。
这些数据是后续判断"变了什么"的唯一依据。只记录"扫描发现 3 个可疑文件"是不够的，因为无法确认这 3 个文件是新增的，还是一直存在只是这次才被规则命中。
判断：区分可能原因与已定位原因
扫描报告里出现可疑文件，只是现象，不是结论。同一个现象可能有多种解释：
- 文件被判定为木马，可能是真的被植入了后门，也可能是主题或插件自带的混淆代码，还可能是扫描规则误报。
- 页面被跳转，可能是木马注入，也可能是服务器配置被改，或 CDN 缓存了旧内容。
- 文件修改时间异常，可能是入侵写入，也可能是正常的自动更新或缓存生成。
记录时要把"疑似"和"已确认"分开写。确认手段包括：比对哈希是否与官方发行版本一致、查看文件内容是否包含可疑的请求执行函数、检查访问日志中该文件是否被外部调用过。只有拿到这些证据，才能把"可能原因"升级为"已定位原因"。
处理：记录动作而不只是结果
处理阶段最容易漏记的是操作细节。建议按下面的格式逐条记录，每条包含时间、对象、动作、执行人、依据：
- 隔离而非直接删除：把可疑文件移动到站外目录，保留原路径和哈希，便于后续比对。
- 记录修改过的配置项：例如
.htaccess中新增的重定向规则、计划任务中新增的条目。 - 记录账号变更：是否重置了管理员密码、是否删除了陌生账号、是否更换了密钥。
- 记录补丁与升级：升级了哪个组件、从哪个版本到哪个版本。
假设某次扫描在 /uploads/ 下发现一个 PHP 文件，内容包含接收外部参数的执行逻辑。处理记录应写明：文件路径、哈希值、移动到的隔离目录、判断依据（该目录本不应出现可执行脚本）、以及是否同步检查了同目录下其他文件。这样下次扫描时才能确认同类文件是否再次出现。
复查：用同一条件对比，而不是重新开始
复查的关键是可比性。如果第一次用工具 A 扫全站，第二次用工具 B 只扫部分目录，两次结果无法对比。复查时应保持：
- 相同的扫描范围，或明确标注范围变化及原因。
- 相同的工具与规则版本，或记录规则更新情况。
- 相同的基线对象，即与扫描前保存的哈希清单对比，而不是只看工具报告。
复查通过的标准可以设为：可疑文件为零，且核心目录哈希与已知干净版本一致，且访问日志中不再出现对已隔离文件的调用请求。如果仍有命中，先判断是残留（同一哈希再次出现）还是新变种（新哈希、新路径），两者的处理方向不同。
把上述观察、判断、处理、复查四段写成一份固定模板，每次扫描填一份，按日期存档。下一步可以直接做一件事：为当前站点生成一份文件哈希基线并保存到站外，之后每次木马扫描都以它为对比起点。
