Abstract: A full-cycle walkthrough of a credential-harvesting phishing campaign — covering DNS forensics, WAF bypass, HAR traffic analysis, data poisoning, and cloud infrastructure takedown.

1. Overview

My teacher sent a link like this all of a sudden. The message read:

DO NOT CLICK THE LINK OR ENTER YOUR INFORMATION

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

The URL was long enough that most people wouldn’t read it carefully. And the scenario is common in daily life.

This post documents what happened when I got this link.

The full chain covers: bait capture and sandboxed reconnaissance → WAF fingerprint bypass → live payload extraction → HAR-based traffic forensics → dirty data poisoning → cloud infrastructure abuse reporting.

Safety Boundary: All testing with suspicious parameters must be performed inside a sandbox or isolated VM. Never scan malicious QR codes or enter real credentials from your host machine’s native social apps.

2. Recon & Isolation

2.1 URL Spoofing — The Subdomain Trick

The bait URL looked like this:

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

At a glance, it reads meituan.com and zhihu.com — two well-known Chinese platforms. Most users stop reading there.

The actual resolution logic doesn’t work left-to-right. DNS parses from right to left: the real domain is cdjubao.org. Everything to the left is subdomain noise — crafted specifically to hit the brand-recognition blindspot of non-technical users.

Rule of Thumb: To find the real domain in any suspicious URL, read it right-to-left. Stop at the first dot after the TLD. That’s who actually owns it.

2.2 Infrastructure Reconnaissance

First stop: WHOIS.

The data tells a clear story:

Field Value Significance
Registrar NameSilo, LLC Privacy-shielding registrar, popular with throwaway domains
Creation Date 2026-02-27 8 days old at time of discovery
Name Servers june.ns.cloudflare.com DNS routed through Cloudflare CDN
DNSSEC Unsigned No additional DNS security

Eight days. This is the playbook for throwaway domain infrastructure: register cheap, run the campaign, abandon before takedowns catch up. The combination of NameSilo (privacy protection enabled by default) + Cloudflare CDN + Alibaba Cloud Hong Kong origin server is a classic stack — it dodges mainland China’s ICP registration requirement while keeping latency low for the target demographic.

3. WAF ( Web Application Firewalls ) Evasion

3.1 The Block Page

First access attempt from the sandbox desktop browser: immediate block.

The page loads punishpage.min.js and redirects to 1688.com. This isn’t a generic 403 — it’s an Alibaba Cloud WAF interception page, which means the origin is running behind Aliyun’s protection layer.

Modern phishing kits don’t just sit open on the internet. They deploy environment fingerprinting: only serve the real payload to traffic that matches a specific profile — QQ/WeChat in-app browser UA + mainland China IP. Everything else gets a decoy block.

This is also why automated scanners like VirusTotal and urlscan.io rate these sites clean: they come from overseas IPs with desktop browser UAs, triggering HTTP 400/307 redirects before ever seeing the actual phishing page. The page title that urlscan.io fetches is random gibberish like gdfqqovxhq — a telltale sign of automated phishing kit packing tools.

3.2 Injecting the Right User-Agent

The fix is surgical: ditch the default mobile emulation UA, inject a high-fidelity Tencent-specific User-Agent directly via DevTools → Network conditions.

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

The authentication signal is the tail: QQ/8.9.71.12145. That’s the QQ in-app WebView identifier. Without it, the WAF gate stays shut.

With the correct UA in place, the gate opens. The page renders.

4. Reverse Engineering the Payload

4.1 What the Page Actually Is

The phishing site is dressed as a “campus dance competition voting page.” There’s no QR code scan in this flow — the victim clicks the link directly from the QQ chat message. The server detects the incoming User-Agent: if it identifies a QQ in-app WebView, the page silently redirects to the actual payload hosted at http://tuixcdolo.cgpf.top.cdn.cloudflare.net/. What loads is a crudely assembled voting page — convincing fake stats, tens of thousands of votes, over ninety thousand visitors. The actual credential-harvest mechanism is straightforward: click the vote button, get prompted to enter a phone number, receive an SMS verification code, then submit it to “log in and verify your vote.” That two-step sequence is the entire operation.

I needed to walk through the full credential submission flow without exposing real data. Solution: a virtual SMS platform (SMSOnline) to generate an isolated, disposable phone number and receive the verification code it would send.

With Preserve log enabled in DevTools, I walked through the entire flow — phone number entry, OTP receipt, submission — and exported the complete HAR file.

4.2 HAR Analysis — Tracing the Exfiltration Endpoints

A HAR (HTTP Archive) file captures every network request made during a browser session. With the fake phone number (18470552326) and verification code (448433) in hand, a global search through the HAR immediately surfaces where those values went.

The kit uses a clean two-step exfiltration pattern:

Step Endpoint Method Payload
1. Phone collection /v_post.asp POST sex=on&t5=[PHONE_NUMBER]&ud=&address=1&toip=&name=
2. OTP/credential collection /v_submit.asp POST cid=undefined&ud=undefined&p=undefined&ddid=111814&pass=[VERIFICATION_CODE]

Both hit the backend CDN node at szopcdekli.bcdefghijkl.shop.cdn.cloudflare.net — a Cloudflare-proxied subdomain that hides the actual origin IP. Credentials transmitted in plaintext, no encryption, no obfuscation. The backend just collects rows.

On the “verifying” loop: After OTP submission, the page shows a fake QQ verification spinner with a countdown (30–120 seconds). In the background, get_n.asp fires repeated XHR polls. The victim waits, thinking something is happening. Nothing is — the credentials were already sent on first submission. The loop is theatre to buy time before the victim realizes something is wrong.

Gemini 3.1 Pro wrotes a small Python script to automate the HAR analysis — feed it the HAR file plus your test phone number and OTP, and it walks every request looking for your values:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
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')
            })

Output confirmed two exfiltration endpoints, both POST to the Cloudflare-proxied CDN backend.

5. Active Countermeasures

5.1 Data Poisoning

With both endpoints identified and their payload structure known, the next step is to degrade the value of whatever data they’ve already collected.

The idea: flood both endpoints with fake-but-plausible Chinese phone numbers and 6-digit OTPs. The phone numbers follow real carrier prefixes (China Mobile, China Unicom, China Telecom) so they pass any basic regex validation on the backend. The signal-to-noise ratio in their database drops — whoever later tries to use that data for account takeover has to sift through thousands of dead entries.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
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}")

A few things to keep in mind with this approach:

  • Rate limiting is real: Too many concurrent threads from one exit IP will hit the CDN’s rate limiter or trigger a “5-second shield.” Keep concurrency low (5–10 threads) and add a small sleep between submissions.
  • The honesty check: Unless you run this 24/7, the backend can just filter outliers and clean the data. Poisoning degrades quality but doesn’t stop the operation. It’s a speed bump, not a wall.
  • The X-Forwarded-For header: Randomized to mask the source IP. The backend likely logs this header for geo-filtering purposes.

5.2 Infrastructure Takedown

The higher-ROI move is cutting off the infrastructure entirely rather than polluting data. Two vectors:

1. Cloudflare Abuse Report
Submit at https://abuse.cloudflare.com/phishing. Include:

  • The full phishing URL
  • The CDN backend hostname (szopcdekli.bcdefghijkl.shop.cdn.cloudflare.net)
  • HAR screenshots showing plaintext credential exfiltration with the target API endpoints clearly visible
  • Structured IoC table

2. NameSilo Registrar Report
Email abuse@namesilo.com with the domain (cdjubao.org), a short description of “Credentials Phishing,” and the same evidence. NameSilo typically issues a clientHold (suspension of DNS resolution) within 24 hours of verification.

On Cloudflare’s response: Their automated acknowledgment clarifies that Cloudflare is a pass-through CDN, not a hosting provider — they cannot remove the hosted content directly. What they can do is drop the domain from their network, forcing traffic to the raw origin IP (in this case the Alibaba Cloud Hong Kong node at 47.76.241.235), which significantly degrades delivery and removes the CDN-based IP anonymization. For full takedown, the registrar (NameSilo) report is the more effective vector — a clientHold kills DNS resolution entirely.

6. Threat Intelligence — IoC Archive

For anyone who encountered this campaign or wants to add these indicators to a blocklist:

Type Value Notes
Spoofing URL (Frontend) http://www.meituan.com.data.zhihu.com.pic.cdjubao.org Entry point — fake campus voting page
C2 CDN Node (Backend) szopcdekli.bcdefghijkl.shop.cdn.cloudflare.net Hidden behind Cloudflare proxy
Credential API 1 /v_post.asp POST — phone number exfiltration
Credential API 2 /v_submit.asp POST — OTP/password exfiltration
Origin IP 47.76.241.235 Alibaba Cloud Hong Kong (when not behind CDN)
Registrar NameSilo, LLC Abuse: abuse@namesilo.com
Domain Age 8 days Registered 2026-02-27, discovered 2026-03-07

7. Takeaways

A few things this exercise confirmed:

The subdomain trick still works. Ordinary users read URLs left-to-right and stop at the first recognizable brand name. The actual TLD is at the far right and most people never look there. The fix is simple pattern recognition — but you have to know to look.

Environment fingerprinting is increasingly standard. The kit refused to serve the payload to anything that didn’t look like a real QQ WebView from a Chinese IP. This is exactly why automated scanning services rate these sites clean — they fail the fingerprint check before seeing any malicious content. Manual investigation with the right UA is the only reliable detection method.

The full stack is designed for evasion. NameSilo (privacy-shielded registration) + Cloudflare CDN (IP anonymization) + Alibaba Cloud HK origin (low latency, no ICP requirement) — every layer adds friction for defenders. The chain isn’t accidental.

Infrastructure attacks beat data attacks. Running 500 fake credential submissions is satisfying but ultimately low-impact. A single well-documented abuse report to the registrar with clear evidence of credential exfiltration does more. Takedown > poisoning.

References