摘要：投递链、生产实践与实验的位置 本文是 360 Netlab 《银狐云端“生死簿”：从“无条件返回”到“黑名单”机制》 的后续分析，承接前文四阶段时间线。本轮实验确认了一个新的阶段——第五阶段：Referer 的时间窗变种。这不是第二阶段白名单机制的简单失效，而是白名单判定增加了时间窗口，命中后的返回内容也发生了变化：第二阶段命中返回样本下载地址；第五阶段命中且处于 00:00—08:00 时，返回 https://www.360.com/。具体何时发生这一转变，现有材料尚无法确定。持续生产又分为两部分：先以 Referer 请求头传递候选域名，随后改用 h 请求参数。 前文还原的银狐投递链由几部分共同组成：仿冒下载页面负责引流并触发请求；relays.json 提供中转池；调度接口 api.

2026年9月，360威胁情报中心对银狐仿冒投递链进行持续性追踪，结合历史样本与本轮抓包，梳理出其投递与对抗演化的四个阶段：无条件返回、白名单限制、基于白名单的批量探测，以及当前的黑名单机制。 最早阶段，访问中转节点即可获得恶意样本下载地址，服务端不区分请求来源。随后，银狐引入白名单机制：仅当请求头 Referer 指向在投仿冒域名时，api.php 才下发真实载荷，其余请求拿不到有效载荷。利用这一特征，我们对最近注册的二级域名进行了批量遍历探测，识别出一批新投放的仿冒域名。 批量探测之后，我们在 9 月 12 日凌晨的双站抓包中，观察到同一台 api.php 出现两种结果；当日 04:35 UTC 的七组对照复测确认：云端决策模型已切换为“黑名单”——只有被拉进失效名单的域名才返回微信官方安装包等无害素材，名单之外的一切（在投域名、全新域名、甚至不带 Referer 的请求）照常下发真实载荷。推测批量探测可能被银狐侧感知，策略切换发生于其后。