钓鱼网站分析及反制实战

Abstract: 一次钓鱼攻击的全链路拆解——从 DNS 溯源、WAF 绕过、HAR 流量分析，到数据投毒和云基础设施举报下架。

1. Background

WARNING:不要点击链接或输入隐私信息

许久不联系的老师突然发来这么个链接，附带一句：

【校园舞蹈比赛】麻烦帮投一下2号，谢谢！
http://www.meituan.com.data.zhihu.com.pic.cdjubao.org/1Gq5clwKm8gJJ9oaQ%2500wKHp6fDaCp3d4lz7j4aAQfTx?id=a49&_wwv=1127777&f=pupt11141&x9w4r4
支持一下2号，很快就第一名了！每人可以投2票！

URL 长到离谱，大部分人基本不会仔细看
而且这种“帮忙投票”的场景也算人之常情
再加上又是熟人/老师发来的，很容易上当

这篇文章记录了我拿到这个链接之后干了什么：

诱饵捕获 + 沙盒侦察 → WAF 指纹绕过 → 实时载荷提取 → HAR 流量取证 → 脏数据投毒 → 云基础设施举报下架
~~（原来这些动作都是有这么抽象的专有名词的啊，但这也太黑话了点，gptish 还是 claudish 来着）~~

探路 → 门卫分析 → 找漏洞 → 抓包分析 → 投脏数据 → 断人域名

安全边界：所有涉及可疑参数的测试必须在沙盒或隔离虚拟机中进行。绝对不要在宿主机的社交 App 里扫描恶意二维码或输入真实信息。

2. 侦察与隔离

2.1 URL 欺骗——子域名套路

钓鱼链接长这样：

1	http://www.meituan.com.data.zhihu.com.pic.cdjubao.org/...

一眼扫过去，meituan.com、zhihu.com——两个国民级平台。大部分人看到这就不往下读了。

但实际解析逻辑不是从左往右的。DNS 从右往左解析：真正的域名是 cdjubao.org。左边那一堆全是子域名噪声，被骗重灾区。

经验法则：遇到可疑 URL，从右往左读。TLD ( Top-level Domain ) 后面的第一个点之前的部分，才是真正的域名拥有者。

2.2 基础设施侦察

第一站：WHOIS。

数据很清楚：

字段	值	说明
注册商	NameSilo, LLC	隐私保护注册商，一次性域名首选
注册日期	2026-02-27	发现时才注册了 8 天
Name Server	`june.ns.cloudflare.com`	DNS 走了 Cloudflare CDN
DNSSEC	未签名	没有额外 DNS 安全措施

8 天。 这就是一次性域名的标准剧本：便宜注册、跑完钓鱼活动、在被举报之前跑路。NameSilo（默认开隐私保护）+ Cloudflare CDN + 阿里云香港源站的组合是经典套路——绕过大陆的 ICP 备案要求，同时保持目标人群的低延迟。

可以说是有bear来（）

3. WAF（ Web Application Firewall ）绕过

3.1 拦截页

沙盒桌面浏览器首次访问：直接被拦。

页面加载了 punishpage.min.js 并跳转到 1688.com。这不是普通 403——是阿里云 WAF 的拦截页，说明源站跑在阿里云防护层后面。

现代钓鱼套件不是随便挂在互联网上就完事的。它们会做环境指纹检测：只对匹配特定画像的流量返回真实载荷——QQ/微信内置浏览器 UA + 大陆 IP。其他的一律给假页面。

这也是为什么 VirusTotal 和 urlscan.io 之类的自动扫描器把这些网站评为安全的原因：它们用海外 IP 和桌面浏览器 UA 访问，直接触发 HTTP 400/307 重定向，根本看不到真正的钓鱼页。

urlscan.io 抓到的页面标题是 gdfqqovxhq 这种随机乱码——这是自动化钓鱼打包工具的典型特征。

3.2 注入正确的 User-Agent

解法很直接：扔掉默认的移动端模拟 UA，在 DevTools → Network conditions 里直接注入一个高仿的 Tencent 专用 User-Agent。

1
2
3

Mozilla/5.0 (Linux; Android 13; M2102K1C Build/TKQ1.220829.002; wv) 
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/114.0.5735.277 
Mobile Safari/537.36 V1_AND_SQ_8.9.71_3494_YYB_D QQ/8.9.71.12145 NetType/WIFI

关键认证信号在尾巴：QQ/8.9.71.12145。这是 QQ 内置 WebView 的标识符。没这个，WAF 大门就是不开。

DevTools Network conditions 面板——注入了自定义 QQ UA

UA 到位，大门打开，页面就渲染了。

4. 载荷逆向

4.1 页面到底是什么

钓鱼站伪装成一个 “校园舞蹈比赛投票页”~~（ u1s1，是真劣质，什么年代了，就不能搓得像一点吗）~~。没有二维码扫描环节——受害者直接在 QQ 聊天消息里点链接。

服务器检测到 User-Agent：如果识别到 QQ 内置 WebView，页面悄悄重定向到真正的载荷，托管在 http://tuixcdolo.cgpf.top.cdn.cloudflare.net/。加载出来的是一个粗糙拼凑的投票页，假数据倒是做得有模有样，几万票、九万多访客，足以骗不少人了。

实际的凭证收割机制很直白：点投票按钮 → 弹窗要求输入手机号 → 收到短信验证码 → 提交“登录验证投票”。

这个两步流程就是整个操作的核心。

我的想法是走完整个凭证提交流程但不暴露真实信息。

方案： 用虚拟短信平台（ SMSOnline ）生成一个隔离的一次性手机号，接收它发来的验证码。

DevTools 里开着 Preserve log，我走完了整个流程——输手机号、收验证码、提交——然后导出了完整的 HAR 文件。

4.2 HAR 分析——追踪数据外传端点

HAR ( HTTP Archive ) 文件记录了浏览器会话中的每一个网络请求。拿着假手机号（18470552326）和验证码（448433），在 HAR 里全局搜索，立刻就能定位这些值流向了哪里。

VS Code 中的 HAR 文件——手机号 18470552326 出现在 v_post.asp 的 POST 载荷中

VS Code 中的 HAR 文件——验证码 448433 出现在 v_submit.asp 的 POST 载荷中

钓鱼套件用的是干净利落的两步数据外传模式：

步骤	端点	方法	载荷
1. 收集手机号	`/v_post.asp`	POST	`sex=on&t5=[手机号]&ud=&address=1&toip=&name=`
2. 收集 OTP/凭证	`/v_submit.asp`	POST	`cid=undefined&ud=undefined&p=undefined&ddid=111814&pass=[验证码]`

两个端点都打到 szopcdekli.bcdefghijkl.shop.cdn.cloudflare.net 这个 CDN 节点——一个 Cloudflare 代理的子域名，藏住了真实源站 IP。凭证明文传输，没加密，没混淆。那意为何就很明显了。

关于那个"验证中"转圈：OTP (One-time Password) 提交之后，页面会显示一个假的 QQ 验证转圈动画，带倒计时（30-120 秒）。后台 get_n.asp 不断发 XHR (XMLHttpRequest) 轮询。

受害者还在傻等，以为有什么事在发生。其实啥也没有。

凭证在第一次提交时就已经发走了。这个转圈纯粹是表演，拖延时间，让受害者反应过来之前多等一会儿。

Gemini 3.1 Pro 写了个小 Python 脚本来自动化 HAR 分析——喂进去 HAR 文件加上你的测试手机号和 OTP，它会遍历每一个请求查找你的数据：

def analyze_har_for_phishing(har_file_path, target_phone, target_code):
    with open(har_file_path, 'r', encoding='utf-8') as f:
        har_data = json.load(f)

    entries = har_data.get('log', {}).get('entries', [])
    malicious_endpoints = []

    for entry in entries:
        request = entry.get('request', {})
        url = request.get('url', '')
        method = request.get('method', '')

        post_data = request.get('postData', {})
        post_text = urllib.parse.unquote(post_data.get('text', ''))
        query_text = urllib.parse.unquote(str(request.get('queryString', [])))

        is_suspicious = False
        if target_phone in post_text or target_code in post_text:
            is_suspicious = True
            payload = post_text
        elif target_phone in query_text or target_code in query_text:
            is_suspicious = True
            payload = query_text

        if is_suspicious:
            malicious_endpoints.append({
                "url": url, "method": method,
                "payload": payload,
                "ip": entry.get('serverIPAddress', 'N/A')
            })

输出确认了两个数据外传端点，都是 POST 到 Cloudflare 代理的 CDN 后端。

5. 主动反制

5.1 数据投毒

两个端点和它们的载荷结构都摸清了，下一步就是降低它们已经收集到的数据的价值。

思路：用假但看起来真的中国手机号和6 位 OTP 灌满两个端点。手机号遵循真实的运营商号段（移动、联通、电信），能过后端的基础正则校验。这样它们数据库里的信噪比就会暴跌——后面想拿这些数据搞账号接管的人，得在几千条废数据里大海捞针。

USER_AGENTS = [
    "Mozilla/5.0 (Linux; Android 13; M2102K1C Build/TKQ1.220829.002; wv) "
    "AppleWebKit/537.36 ... QQ/8.9.71.12145 NetType/WIFI WebP/0.3.0 Pixel/1080"
]

def generate_fake_data():
    prefixes = ['138', '139', '150', '151', '152', '158', '159',
                '182', '183', '187', '188', '130', '131', '132',
                '155', '156', '185', '186', '133', '153', '180', '181', '189']
    phone = random.choice(prefixes) + ''.join(random.choices(string.digits, k=8))
    code = ''.join(random.choices(string.digits, k=6))
    return phone, code

def attack_worker(thread_id):
    session = requests.Session()
    phone, code = generate_fake_data()
    headers = {
        "User-Agent": random.choice(USER_AGENTS),
        "Content-Type": "application/x-www-form-urlencoded",
        "X-Forwarded-For": f"{random.randint(1,255)}.{random.randint(1,255)}"
                           f".{random.randint(1,255)}.{random.randint(1,255)}"
    }
    payload_post = f"sex=on&t5={phone}&ud=&address=1&toip=&name="
    payload_submit = f"cid=undefined&ud=undefined&p=undefined&ddid=111814&pass={code}"

    r1 = session.post(POST_URL, data=payload_post, headers=headers, timeout=5)
    r2 = session.post(SUBMIT_URL, data=payload_submit, headers=headers, timeout=5)
    if r2.status_code == 200:
        print(f"[Thread-{thread_id}] [+] Poisoned: {phone} | {code}")

跑这个得注意几点：

存在限流：同一个出口 IP 开太多并发线程会撞上 CDN 的限流器或者触发 “5 秒盾”。并发压低点（5-10 个线程），提交之间可以加个短 sleep。
效果也没有想象中那么好：除非你 7×24 跑，不然后端完全可以按时间过滤掉异常值、清洗数据。投毒降低了数据质量但拦不住整个操作。有点聊胜于无的作用吧~~（主观来说挺爽的倒是）~~。
X-Forwarded-For 头：随机化来掩盖源 IP。后端大概率会记录这个头做地理过滤。

5.2 我告老师了😋

比起往数据里掺沙子，直接掐掉基础设施才是 ROI 更高的操作。两条路：

1. Cloudflare 滥用举报

去 https://abuse.cloudflare.com/phishing 提交。附上：

完整的钓鱼 URL
CDN 后端主机名（szopcdekli.bcdefghijkl.shop.cdn.cloudflare.net）
显示明文凭证外传的 HAR 截图，目标 API 端点清晰可见
结构化的 IoC 表格

2. NameSilo 注册商举报

发邮件到 abuse@namesilo.com，附上域名（cdjubao.org）、简短描述"Credentials Phishing"，以及相同的证据。NameSilo 通常在验证后 24 小时内发出 clientHold（暂停 DNS 解析）。

Cloudflare Trust & Safety 自动回执——工单 #21984966

关于 Cloudflare 的响应：他们的自动回执说得很清楚——Cloudflare 是透传 CDN，不是托管商，没法直接删除托管内容。但他们能做的是把域名从自己的网络上踢掉，迫使流量直接打到裸源站 IP（也就是阿里云香港节点 47.76.241.235），这会大幅降低交付效率并移除 CDN 层的 IP 匿名化。要想彻底下架，注册商（NameSilo）举报才是更有效的路径——一个 clientHold 直接杀死 DNS 解析。

6. 信息存档

类型	值	说明
前端欺骗 URL	`http://www.meituan.com.data.zhihu.com.pic.cdjubao.org`	入口——假校园投票页
后端 C2 CDN 节点	`szopcdekli.bcdefghijkl.shop.cdn.cloudflare.net`	藏在 Cloudflare 代理后面
凭证 API 1	`/v_post.asp`	POST——手机号外传
凭证 API 2	`/v_submit.asp`	POST——OTP/密码外传
源站 IP	`47.76.241.235`	阿里云香港（不走 CDN 时暴露）
注册商	NameSilo, LLC	滥用举报：`abuse@namesilo.com`
域名年龄	8 天	2026-02-27 注册，2026-03-07 发现

7. 总结收获

这次操作确认了几件事：

子域名套路依然有效。 普通用户看 URL 是从左往右的，看到第一个认识的品牌名就停了。真正的 TLD 在最右边，大多数人根本不看那里。防范方法就是简单的模式识别——但你得先知道要去看。

环境指纹检测已经是标配了。 这些钓鱼网站拒绝向任何不像真实 QQ WebView + 中国 IP 的流量展示真实页面。这就是为什么自动化扫描服务把这些站评为安全的原因——它们过不了指纹检测，根本看不到恶意内容。手动调查 + 正确的 UA 是唯一可靠的检测手段。

整套技术栈就是为了躲避而设计的。 NameSilo（隐私保护注册）+ Cloudflare CDN（IP 匿名化）+ 阿里云香港源站（低延迟、不需要 ICP 备案）。

打基础设施比打数据更有用。 跑 500 条假凭证提交确实很爽但实际影响有限。一份证据充分的注册商滥用举报，效果比投毒强得多。下架 > 投毒。