一份可用的挂马检测报告,核心不是给出“有木马”三个字,而是展示能支撑定位与处置的证据链:可疑文件路径与哈希、命中特征、首次与最近出现时间、访问触发条件、外链或跳转目标、进程与网络连接、以及检测工具的原始输出。缺少这些证据,报告只能算告警,不能作为清理和复验依据。
判断报告是否合格,可以先看它能否回答四个问题:哪里、是什么、怎么触发、影响范围。对应到具体字段,建议至少包含以下内容。
eval与base64_decode的嵌套调用。只写“恶意代码”不够,要能指出命中了哪条规则。网页挂马通常表现为页面被插入脚本或iframe。报告应展示:被篡改页面的URL、插入代码的原文片段、该代码加载的外部地址、以及页面在什么条件下才输出这段代码(例如仅对搜索引擎爬虫或特定User-Agent返回)。如果工具只给出“发现恶意脚本”而不给触发条件,排查时很容易复现失败。
服务器层面的挂马更多体现在进程、定时任务和启动项。报告应展示:可疑进程的启动命令与父进程、监听端口、对外连接的目标地址、关联的定时任务或服务项。这类证据需要与系统日志交叉核对,单靠一个进程名不能定性。
拿到报告后,按以下顺序核对,能较快区分误报与真实挂马。
验收信号是:清理后重新扫描,同一路径与哈希不再命中;用相同触发条件请求页面,返回内容中不再出现原恶意片段;服务器上不再有指向报告所列地址的活动连接。
仅有“检测到恶意代码”的提示、仅有文件名相似、仅有某个IP出现在日志中,都不足以认定挂马。文件名可以被伪造,IP可能是正常业务接口,日志中的单次请求也可能是扫描器探测。报告需要把文件、行为、时间三类证据相互印证,才能支撑处置决策。
另外,第三方检测平台的判定结果与站内自查结果口径可能不同:平台可能基于快照或爬虫视角,站内自查基于服务器实际文件。两者不一致时,应以服务器文件哈希和实际请求响应为准,并记录差异,而不是直接采信其中一方。
下一步建议:拿现有报告对照上面的字段清单,把缺失项补齐后再决定是否清理;若报告只给结论不给原始输出,应改用能导出文件路径、哈希与命中规则的检测方式重新取证。