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

挂马检测工具怎样记录改动前后的基线：先固化页面指纹再比对

用挂马检测工具记录改动前后的基线，核心做法是：在确认页面干净时，对关键文件与页面内容生成可复核的指纹清单，把文件名、大小、修改时间、内容哈希和关键片段一起存档；之后每次扫描都用同一口径重新生成，只把“指纹发生变化”的条目列为待查对象。基线不是一次扫描结果，而是一份可重复比对的证据链。

准备阶段：确定基线覆盖哪些对象

基线范围决定后续比对是否有意义。对已有项目，优先覆盖这些对象：

• 对外可访问的页面：首页、栏目页、文章页、表单页的HTML输出。
• 可执行或可被解析的文件：.php、.js、.html、模板文件、配置文件。
• 常被挂马利用的位置：页脚、统计代码、外链区块、上传目录中的脚本文件。
• 服务器侧线索：新增或近期被改动的文件列表、异常进程与计划任务。

这里的关键判断是：基线要记录“内容”而不只是“存在”。只记录文件列表，无法发现同一文件被插入一行混淆脚本；只记录修改时间，也无法发现攻击者回填时间戳。因此至少同时保留大小、修改时间和内容哈希，并另存一份关键片段的文本快照。

实施阶段：生成可比对的指纹清单

在确认当前页面无异常的前提下生成基线。若此时页面已经被挂马，基线会把恶意内容当成正常状态，后续比对就失去意义。所以第一步应先用挂马检测工具或人工检查确认干净，再固化基线。

可执行的步骤示例（假设项目位于网站根目录，使用常见命令行工具）：

1. 对目标目录生成哈希清单：find . -type f -name "*.php" -exec sha256sum {} \; > baseline_sha256.txt。
2. 同时记录文件属性：find . -type f -printf "%p %s %TY-%Tm-%Td %TH:%TM\n" > baseline_meta.txt。
3. 对重点页面保存正文快照：抓取页面HTML后去掉动态参数，只保留结构文本，存为独立文件。
4. 把上述文件放到Web根目录之外，并设置只读权限，避免被篡改。

比对时使用同一命令重新生成清单，再用diff或哈希比对找出差异。判断规则可以这样设定：哈希不同即进入人工复核；只有修改时间变化而哈希一致，通常属于重新部署或时间戳变动；哈希一致但文件属性异常，需要结合服务器日志判断。

验证阶段：区分“改动”与“挂马”

基线比对会报出大量差异，其中多数来自正常更新。验证的目的不是消灭差异，而是把差异归类。对每一条哈希变化，按以下顺序核查：

• 该文件是否在本次发布范围内？发布记录能对应的，归为正常改动。
• 变化内容是新增外链、混淆字符串、eval、base64_decode、异常跳转，还是普通文案调整？前者优先按可疑处理。
• 变化是否集中出现在页脚、模板、上传目录等挂马高发位置？集中出现时提高优先级。
• 同一时间段是否有其他文件被改动？成批改动比单文件改动更值得追查。

需要注意，哈希变化本身不是挂马证据。它只说明内容与基线不同。把“可能原因”和“已经定位的原因”分开记录：未结合日志与代码内容前，只能写“疑似被篡改”；只有在文件中确认了恶意代码并找到对应访问记录，才能写“已定位”。

维护阶段：让基线跟得上正常改动

基线一旦长期不更新，正常发布也会被反复报为异常，最终导致告警被忽略。维护规则应当明确：每次正常发布后，重新生成受影响文件的指纹并归档；保留旧基线版本，便于回溯某次改动是发布引入还是外部引入。

建议维护时保留三项记录：基线生成时间、对应发布版本、生成时的检查结论。这样当挂马检测工具再次报出差异时，可以快速判断是“发布带来的变化”还是“无发布记录的变化”。后者才是排查重点。

下一步可以直接执行：选一个当前确认干净的页面目录，按上面的命令生成第一份哈希清单和属性清单，存在Web根目录之外，然后在下一次发布后再生成一份并比对。第一次比对的结果，就是这套基线方法是否适合你项目的直接验证。