Cloudflare 用 GNN 加 LLM 抓恶意脚本：四个真实攻击行动的检测方法拆解

一句话结论

Cloudflare 公开了 Client-Side Security 的机器学习检测管线如何在真实电商流量里抓到四个恶意攻击行动、八个恶意载荷：同批样本经 VirusTotal 和 URLScan 复核，七个在 VirusTotal 完全没有记录，URLScan 对全部八个都不给恶意判定，而 Page Shield ML 在线上流量里全部命中。对做电商或任何有第三方脚本的网站，这篇的价值在于两块：一套可借鉴的「GNN 粗筛 + LLM 复核 + 前沿模型陪审团」检测架构，和四类攻击的完整手法拆解。

为什么传统扫描器漏报

一个现代电商店面上可以看起来完全健康，而恶意 JavaScript 在底下干活：抽走联盟佣金、劫持搜索和点击、篡改分析数据，或者向远程服务器请示下一步执行什么。页面加载正常、商品正常、结账正常——但浏览器可能正在做站长从未授权的事。

这批载荷的检测是自动化的，人只在系统标记后做验证。事后用安全扫描工具复核：八个载荷里七个在 VirusTotal 完全缺失，URLScan 对任何一个都不给恶意判定；Page Shield ML 在线上流量里抓到了全部八个。

一个具体例子：安全研究界多年前就记录过 Lnkr 家族，其中一个特定载荷版本在 URLScan 上被索引了两年半，一直挂着「无分类」标签，包括 2024 年 1 月的一次直接扫描期间。而 Page Shield ML 独立地在一家在线零售商的店面流量里发现了完全相同的字节。

这里有个对防御者要害的判断：一个哈希可以在它背后的代码被判定为恶意之前很久就已存在。如果你的防御在等那个标签，你已经晚了。你需要能拆解 JavaScript 本身、能规模化判断它的 ML。

检测架构：GNN 粗筛、LLM 复核、教师陪审团

这四个行动没有通用签名、没有共同隐藏手法。一个除非设备、国家、时间、来源或浏览器状态匹配否则保持休眠；一个把无点击的联盟请求藏进不可见 iframe；其他的拦截点击、压制监控、或按条件从远程服务器加载更多代码。要抓它们，必须看这些部件如何协同：脚本何时醒来、藏了什么、拦了什么、下一步取什么。检查页面一次不够——这些脚本就是为「正确受害者出现前保持安静」设计的。

同一个 GNN（图神经网络）此前已抓过恶意 npm 包和一个在野 Magecart 支付窃取器。它不把 JavaScript 当平文本处理，而是当图推理：一棵连接代码符号的语法树，暴露谁调用谁、攻击者埋了什么、还有什么在回连。这个结构帮它跨压缩、重命名和部分混淆识别可疑模式，不依赖已知 URL 或字节签名。

GNN 标记为可疑的脚本（占全部分析流量不到 0.3%）交给 Workers AI 上的轻量 LLM 做在线第二意见，进一步压低误报同时保住召回。LLM 与 GNN 结论一致时才告警客户。

对最复杂的脚本，Cloudflare 用一组前沿模型做「教师」（自动评审团集合），约六个不同家族的领先模型，含跑在 Workers AI 上的开放权重模型。每个模型作为独立智能体、在各自全新会话里分析同一段可疑脚本；需要时它们的智能体工具访问权限允许用受限 JavaScript 求值器拆开小片段、揭示隐藏行为。

前沿模型之间会有分歧，尤其在最刁钻的脚本上。分歧被当作信号而不是噪音：每个标签是一票，按模型在 Artificial Analysis Intelligence Index 上的得分加权，产出四类标签的概率分布——良性、支付窃取（magecart）、其他恶意软件、挖矿。人工评审员因此只需要看被标为恶意或没有明确三分之二多数的脚本。这些标签分布再回喂 GNN 训练，帮它区分越来越细的案例。

攻击一：下班时间联盟佣金劫持

手法：移动设备加时间门控、动态页面监控、点击拦截、多天冷却。

设想一个安静的周日下午：购物者在手机上点了一个商品。脚本没有正常跟随点击，而是从攻击者预选列表里挑一个商品或落地页开新标签，把原标签送进联盟路由。店面看起来一切正常。如果购物者完成购买（当场或以后），这次绕路就劫持了归因——销售和佣金记到一个没有做出推荐的账户上。

店家可能给一笔没挣到的佣金。更糟：如果是一个正经合作伙伴带来的推荐，强制请求可能把功劳错记，把提成从真正干活伙伴那里转走。伤害能超出单笔佣金——不再信任归因系统的伙伴，可能连背后的零售商也不再信任。

共发现五个相关脚本构建：两个活跃、三个捕获时处于暂停。每个活跃变体用不同的门控组合才行动：访客设备与本地时间、这招最近跑过没有、商品按钮出现了没有、真有人点了没有。这套规则迷宫让短暂自动化访问看不到恶意行为。活跃脚本用 MutationObserver 盯着首屏后动态出现的商品瓦片和按钮，拦下晚到元素的点击——加载一次 HTML 就停的爬虫完全错过重定向路径。

点击被拦后，脚本往 localStorage 写三天冷却（该设备休眠数日），然后执行双标签机动：把攻击者选的商品页弹进新标签稳住购物者，原标签则快速走一趟攻击者的联盟跟踪链接再回店，在后台种下归因 cookie。控制台掩蔽和自检代码让检查更难。

投放走营销供应链：确认的一条路径是两个标签管理器接力。投放域名还做了伪装——adtargett[.]com 比 1998 年注册的正牌广告域 adtarget[.]com 多一个 t，2025 年注册，首页自称「Adtarget.com 绩效营销代理」。

攻击二：零点击隐形归因

这个连点击都不需要。购物者打开预订页、看看选项、从不碰广告——条件满足时，脚本已经通过隐藏 iframe 或自点链接发出了联盟请求，让之后的销售看起来像别人推荐的。

脚本先调一个公共 IP 地理定位服务，但忽略返回的一切——包括购物者国家。拿不到成功响应就静默停止（fail-closed，可能帮助逃过网络受限沙箱）。真正用的决策依据是内嵌的三个 TradeDoubler 配置块（AU/US/UK），各含联盟 URL 和起止时间；脚本用 JavaScript 算出加尔各答时区、检查时间窗、按固定奇偶小时规则三选一。选定后写一小时的节流 cookie，把联盟 URL 装进屏外 iframe、抑制 referrer；iframe 失败一两秒就造一个隐藏链接程序化点击兜底。混淆方式简单有效：连属性名都逐字符拼装。

攻击三：老搜索劫持者改行当店面后门

Lnkr 家族多年前因藏在流氓浏览器扩展里、劫持谷歌必应搜索赚广告钱出名。现在攻击者把这套代码库改成了店面前门。

跑在店面上（而非搜索引擎）时，老的搜索重定向模块保持休眠，新用途是回传遥测，更危险的是给攻击者开了扇远程门：随时在客户浏览器里下载执行新 JavaScript，不碰服务器一个文件。它还带着扩展时代的老手艺：有人在谷歌输入 virus 或 popup 这类词就自断。

这个脚本直接嵌进商家 HTML。初始入侵路径无法确定；实践中直插 HTML 通常走被入侵的管理凭据、未授权模板编辑或被感染的第三方主题/插件。

载荷是个模块化工具箱，含活跃与休眠代码。老模块（透明点击覆盖层、搜索查询拦截器、扩展商店链接改写器、typosquat 域名重定向）只在特定目标站醒来，在这个店面保持关闭。活跃分支专注规避、遥测与远程控制。

它对特定条件才运行：精确目标店面、窄移动屏幕、访问头两页带活动标签。在笔记本、公司网络、云厂商和加密隧道网络环境上休眠——最可能调试页面的人永远看不到它触发。它还在选定的美国城市和地区休眠，靠一份 325 条 IP 字符串手工黑名单躲开自动化扫描器。全过之后才动手：拆掉店面的九个监控分析工具、替换广告和分析身份、回连。交付域名 sdk-amazonaws[.]com 是 2024 年注册的山寨，与正牌亚马逊 AWS 域无关，还叠了一个模仿流行电商营销平台的子域名——双重品牌信任叠加，专门为糊弄快速标签审查设计。

主激活漏斗伪代码长这样：顶层窗口、精确 host、无挑战页；无 _cart_dr 与 _logo_alt cookie；视口宽小于 477 且会话第 1-2 页；utmMedium 在 ppc/cpc/sms/paid 之列；一个看似随机实为恒真的门；IP 属美国、是移动、非商业、非云、非代理、非加密隧道、非 Tor、非威胁；地区不在纽约/加州之列；城市不在排除名单；IP 前缀不在 325 条黑名单。全过才执行载荷。

与复杂主斗篷形成鲜明对比，次要信标分支完全绕过这些门：第二页起就写一个 600 天过期的持久 cookie，向 maper[.]info 发零像素图片请求——给攻击者一个全店访客的持久计数器，同时把高风险劫持逻辑严格藏在移动斗篷后面。

攻击四与四条教训

四个行动合起来讲了一个升级的故事：攻击者换了目标、投放路径和伪装，但浏览器仍必须执行他们的逻辑。四条教训：

行为打败签名。 这些行动追求不同的变现方式，但每个载荷都得在浏览器里行动：观察事件、查状态、改页面、调度任务、发网络请求、加载下一阶段。结构分析找的就是这种「敌意载荷必须携带的逻辑」——URL、签名和目标都会变，逻辑跑不掉。

选择性执行是攻击的一部分，不是脚注。 设备、时间、地理、来源、会话、网络和冷却门控都能击败「访问一次拍静态快照」的爬虫。持续可见性重要，因为攻击可能只对某一个浏览器、某一个状态、某一刻出现。

混淆抬高分析成本，但没阻止检测。 自卫循环、控制台压制、调试器陷阱、轮换字符串表、死分支都让分析更麻烦。Page Shield ML 仍在这些障碍下浮出了全部四个行动。

上下文补全画面。 孤立看正常的代码，一旦把静态分析和动态上下文连起来——怎么到达的、什么浏览器状态激活了它、开了什么连接、运行时实际做了什么——就会显出恶意角色。

对站点负责人的操作要点

Cloudflare Client-Side Security 在所有套餐里提供这种可见性：安全设置里开「持续脚本监控」可追踪店面第一方和第三方脚本；自动化恶意脚本检测与告警在 Client-Side Security Advanced 里。脚本活动与检测管理直接在 Cloudflare 控制台。

如果你运营电商或任何挂第三方脚本的站点，这篇的启示可以直接转化成动作清单：盘点你的标签管理器链路（本案例两条投放路径都走它）；对投放域名做相似度审查（本案例三次 typosquat 都是「多一个字母/叠品牌」的简单招数）；确认你的检测手段是持续性的而非快照式的。

原文信息

• 作者：Juan Miguel Cejuela、Zhiyuan Zheng、Denzil Correa（Cloudflare Page Shield 团队）
• 来源：Cloudflare 官方博客
• 原文发布日期：2026-09-16

原文地址：