How a `.cn` Phishing Site Was Taken Down in Hours via Tencent — and Ignored by Google for 3 Days
A customer flagged a phishing site impersonating a Japanese consumer brand. The page lived at a .cn apex with a randomized subdomain — typical of single-use kit deployments. We submitted it to two takedown channels at the same time and watched what happened.
| Channel | Submitted | First action | Site removed |
|---|---|---|---|
| phish.report → Tencent abuse | 2026-04-25 | acknowledgment within 1 working day | ~24 hours later |
| Google Safe Browsing | 2026-04-25 | (none observed) | 3+ days, never responded |
This isn't a one-off. It's a pattern I've seen repeatedly when phishing infrastructure sits inside Chinese hosting / DNS ecosystems, and it changes how you should design your takedown stack if any of your customers, employees, or brand mentions might cross that boundary.
What's actually happening
Google Safe Browsing is a browser warning system, not a takedown service. When you submit a URL, Google evaluates whether to add it to the Chrome / Safari / Firefox phishing blocklist. The site keeps running on its origin host; only the visit warning gets deployed. Median delay for that warning is 24–72 hours, but for .cn-hosted infrastructure with no Western-CDN front, Google's incentive to act drops further — they have no leverage on the origin and minimal user impact in their primary markets.
Tencent's abuse channel is fundamentally different. Tencent runs DNSPod (registrar), Tencent Cloud (hosting), QQ Browser blocklist, WeChat security, and the phishing classifier inside Tencent computer manager. When their abuse desk acts, the site can disappear from DNS resolution, hosting can pull the page, and Chinese browsers and chat clients add the warning — all in one chain. For phishing infrastructure they're closer to than the registrar of any other channel, this is the fastest takedown path that exists, period.
The gap between these two channels is the operational reality nobody publishes. Most "anti-phishing best practices" guides recommend submitting to Google Safe Browsing as the front-line action and treating registrar abuse as a secondary track. For Western-hosted phishing that's roughly correct. For .cn / Tencent-hosted, you have it inverted.
The submission stack we now run
After this case, the order we run for any Chinese-infrastructure phishing site:
- phish.report submission — auto-routes to Tencent abuse + a few other channels phish.report's contact database knows. This is the fastest single action because phish.report has a maintained mapping (and the 24-hour SLA we observed). Free, no account required for the basic flow.
- Direct Tencent DNS Abuse Complaint Platform — tencentcloud.com/report-platform/dnsabuse. Use this when the domain is unambiguously registered through DNSPod / Aceville Pte Ltd. Their official SLA is one working day for an acknowledgment; site removal commonly follows within another 24 hours if the evidence package is clean.
- 12321 (中国互联网协会反诈骗中心) — 12321.cn. The MIIT-backed reporting center. Submission via their WeChat official account
12321 举报中心is the fastest path; a paste of the URL + screenshot is enough for them to forward to the right downstream. This carries less infrastructural authority than Tencent's own desk but adds regulatory pressure that hosts can't ignore long-term. - 360 网址举报 (
fuwu.360.cn/jubao/wangzhi) — handles the 360 Browser / 360 Total Security blocklist. Roughly 12–24 hour reflection. - Cloudflare phishing report in parallel — abuse.cloudflare.com/phishing — only matters if there's a CF proxy in front. For pure
.cninfrastructure usually irrelevant. - Google Safe Browsing + Microsoft SmartScreen — fire-and-forget. They cover Western browsers, which the kit's victim base may or may not use. Don't wait on these.
The point: Google Safe Browsing isn't deprecated, it's just the wrong primary tool for Chinese infrastructure. Run it in parallel as cheap insurance, but don't gate progress on it.
A finding that surprised us about phish.report's public API
While building this stack into our automation, we benchmarked phish.report's public GET /api/v0/hosting?url=<URL> endpoint against a sample of 50 production phishing candidates we had observed in CT logs that week. The endpoint returns a list of {name, role, report_uri} for the URL's hosting and registrar, drawn from phish.report's curated abuse contact database.
Hit rate on our sample: 0%. Every cheap-TLD candidate (.top, .xyz, .buzz, .cn, .link) returned null. Meanwhile, the same endpoint returned full structured data for google.com, github.com, vercel.app, amazon.com — established commercial domains.
Our reading: phish.report's public hosting endpoint is curated against the registrar/hosting providers most likely to be on the legitimate side of the lookup. The kit-operator long tail (cheap registrars in China and beyond, churn-pricing TLDs, parked-then-flipped infra) is where active phishing actually concentrates, and that's exactly where the public mapping is sparse. The success in our customer case ran through phish.report's full takedown flow, not through a simple API mapping — the human-in-the-loop submission and downstream-channel relationships are the real product, not the public lookup.
Practical implication for anyone integrating: don't assume GET /hosting will return useful routing data for active phishing URLs. Either use phish.report's authenticated case API (which actually triggers the submission flow) or maintain your own abuse-contact mapping for the cheap-TLD long tail.
What this changes about our product roadmap
Three concrete shifts on the OpenBait side based on this:
1. Detection precision over takedown integration. We initially thought "wrap phish.report's hosting endpoint" was the highest-leverage takedown improvement. The 0%-hit-rate result inverted that. We're investing in detection-side signals first — specifically, identifying kit-operator certs that issue Let's Encrypt with multiple brand-touching SANs in one cert (a classic fan-out fingerprint that the existing CertStream pipeline wasn't scoring). That work landed in production this week.
2. China-channel coverage as a first-class feature, not an afterthought. Most international brand-protection vendors (Memcyco, Bolster, Axur, Fortra/PhishLabs) are strong on Western channels and weak on Chinese ones — there's no English-language abuse-channel intuition built into their automation, no fixed reporter relationship with 12321 or DNSPod, no Mandarin-speaking ops desk. For Japanese mid-market customers whose customer base or brand mentions cross into China, this matters. We're prioritizing Tencent / 12321 / 360 templates with the same status as our existing GoDaddy / Namecheap / Cloudflare ones.
3. Honesty about Google Safe Browsing as a primary signal. It still belongs in the stack as parallel coverage for Western browsers, but anyone designing a takedown SLA against "Google Safe Browsing response time" is going to be unhappy when a real attack lands on .cn / .ru / .kp infrastructure where Google has no leverage. The honest framing: Safe Browsing is a victim-protection layer, not a takedown layer.
What you can take from this
If you're running brand protection in-house, three things to verify on your own infrastructure before the next attack:
- Have you ever successfully had a
.cnsite taken down? If no, your stack will fail you the day a Chinese-hosted attack hits. Test it now: there are continuously-running phishing kits you can submit to Tencent / 12321 today and observe response time on your own. - What's your registrar-to-channel routing logic? A naive WHOIS lookup will get you the registrar of record but won't tell you which abuse channel actually responds. Map your top 10 active registrars by case volume to their actual fastest response channel, including fallback paths. phish.report's per-registrar contact pages are a free starting point for this.
- Don't measure Google Safe Browsing as the SLA. Measure time-to-blocklist-warning across all browser engines your customers use, including Chinese browsers (QQ, 360, UC, Baidu). For cross-border brands, GSB-only metrics underrepresent half your real customer protection surface.
If you're already running OpenBait, the SAN-fan-out detection improvement landed in your scout pipeline this week — no action needed on your end. The Chinese-channel templates and 12321 / Tencent integration are the next P1.
If you're evaluating, you can register for the free tier (1 brand, 5 Canary tokens, 3 takedowns/month) to test against a domain you control. The Memcyco-comparison and broader brand-protection SaaS comparison are public and explicitly call out where we don't compete.
Related reading
- Phishing takedown services compared — in-house, agency, or SaaS
- Building an anti-phishing defense in 2026
- The 48-hour phishing incident response playbook
- Browser blocklist submission, line by line
Sources / external references
Protect your brand from phishing
Start monitoring domain impersonation and social media brand abuse — free.
Get Started FreeRelated articles
Building an Anti-Phishing Defense That Actually Works in 2026
How mid-market security teams should layer detection, takedown, and customer-side protection into one operational flow. Field notes from a year of running this stack against AI-generated phishing campaigns — what saves time, what wastes budget, and where vendors over-promise.
The First 48 Hours of a Phishing Incident — A 7-Step Response Playbook
What to do in the first 48 hours after a phishing site impersonating your brand goes live. Scoped to mid-market security teams without a 24/7 SOC. Each step has an owner, an output, and a hard deadline — based on the response runs we operate at OpenBait.
Phishing Takedown Services Compared — In-House, Agency, or SaaS?
An honest 2026 comparison across the takedown landscape: enterprise platforms (Memcyco, Bolster, ZeroFox, Axur, PhishLabs), agency-style retainers, and self-serve SaaS. Where each model wins, how prices actually shake out, and what mid-market security teams should buy when budgets land under $50K/year.