`.cn` フィッシングサイトを Tencent 経由で数時間で停止 — Google には 3 日反応されなかった件
ある顧客から、日本の消費者向けブランドを名乗るフィッシングサイトの報告が入った。サイトは .cn 直下にランダム文字列のサブドメインを置く構造で、典型的な使い捨て型 phishing kit のデプロイパターン。同じ URL を 2 つのテイクダウン経路に並行で投げて、何が起きるかを観察した。
| 通報先 | 提出日 | 最初の反応 | 停止確認 |
|---|---|---|---|
| phish.report 経由 → Tencent abuse | 2026-04-25 | 1 営業日以内に受付確認 | 約 24 時間後に停止 |
| Google Safe Browsing | 2026-04-25 | （観測されず） | 3 日経過後も停止せず |
これは 1 回限りの事例ではなく、中国系ホスティング・DNS インフラに乗ったフィッシングを扱うと繰り返し見るパターンで、顧客・社員・ブランド言及のいずれかが中国を跨ぐ可能性がある場合、テイクダウンスタックの優先順位を見直す根拠になる。
何が起きているのか
Google Safe Browsing は本質的にブラウザ警告システムであって、テイクダウンサービスではない。URL を提出すると Google が Chrome / Safari / Firefox の phishing ブロックリストに入れるかを評価する。サイトはオリジンホスト上で稼働し続け、配布されるのは「訪問時の警告」だけ。警告反映までの中央値は 24–72 時間と言われるが、.cn ホスト + 西側 CDN を経由しないインフラに対しては、Google 側のインセンティブはさらに下がる。オリジンに対してレバレッジがなく、彼らの主要市場のユーザー被害も限定的だからだ。
Tencent の abuse 経路は構造が違う。Tencent は DNSPod（レジストラ）/ Tencent Cloud（ホスティング）/ QQ Browser のブロックリスト / WeChat セキュリティ / 腾讯电脑管家 の phishing 分類器 を全て自前で運営している。Tencent abuse デスクが動くと、DNS 解決から消える、ホスティングがページを落とす、中国系ブラウザとチャットクライアントが警告を出す——これらが 1 つのチェーンで連動して起きる。彼らがレジストラとして近い phishing インフラについて、これは現存する経路の中で最速のテイクダウンパスである。
この 2 経路の差は、誰も明文化していない運用上の現実だ。世のほとんどの「anti-phishing ベストプラクティス」記事は Google Safe Browsing への提出を最前線、レジストラ abuse を補助に置く。西側ホストの phishing についてはおおむね正しい。.cn / Tencent ホストについては逆である。
この事例後に運用しているスタック
中国系インフラに乗った phishing を見つけたときに走らせる順序：
- phish.report 提出 — phish.report の contacts DB が知っている経路（Tencent abuse + 数経路）に自動ルーティング。観測した 24 時間 SLA を考えると単発アクションとしては最速。基本フロー無料、アカウント不要。
- Tencent DNS Abuse Complaint Platform 直接 — tencentcloud.com/report-platform/dnsabuse。ドメインが明らかに DNSPod / Aceville Pte Ltd 経由で登録されているときに使う。公式 SLA は受付確認が 1 営業日、証拠パッケージが綺麗なら停止はその後 24 時間以内に続くことが多い。
- 12321（中国インターネット協会反詐騙センター） — 12321.cn。工信部が委託する不良情報受付センター。WeChat 公式アカウント
12321 举报中心への提出が最速で、URL とスクリーンショットを貼れば下流の事業者にエスカレーションされる。Tencent 自身のデスクほどのインフラ権限はないが、ホスティング事業者が長期的に無視できない規制的圧力を加える。 - 360 网址举报（fuwu.360.cn/jubao/wangzhi） — 360 ブラウザ / 360 Total Security のブロックリストを更新する。反映まで概ね 12〜24 時間。
- Cloudflare phishing report（並行） — abuse.cloudflare.com/phishing。CF プロキシが前段にあるときのみ意味がある。純粋な
.cnインフラには通常関係ない。 - Google Safe Browsing + Microsoft SmartScreen — 投げっぱなし。西側ブラウザをカバーするが、kit の被害者層がそれを使っているかは別問題。待たない。
要点は、Google Safe Browsing は不要になったわけではなく、中国系インフラに対しては主役の道具ではないということ。並列で投げる安価な保険として残し、進捗をそこに依存させない。
phish.report の公開 API について驚いた発見
このスタックを社内自動化に組み込む過程で、phish.report の公開エンドポイント GET /api/v0/hosting?url=<URL> を、その週に CT ログから観測した本番候補 50 件に対してベンチマークした。エンドポイントは URL のホスティングとレジストラに対する {name, role, report_uri} の配列を、phish.report が手動キュレーションした abuse 連絡先 DB から返す。
ヒット率：0%。安価な TLD の候補（.top .xyz .buzz .cn .link）は全件 null を返した。一方、同じエンドポイントは google.com github.com vercel.app amazon.com には完全な構造化データを返した——既存の商業ドメインだ。
我々の解釈はこうだ。phish.report の公開ホスティングエンドポイントは、ルックアップ対象として正当な側にいる可能性が高いレジストラ・ホスティング事業者に対してキュレーションされている。kit オペレーターのロングテール（中国その他の安価レジストラ、回転価格 TLD、駐車後フリップされるインフラ）こそが活発な phishing の集積地で、ちょうどそこが公開マッピングの空白地帯になっている。顧客のケースで成功したのは phish.report のフルテイクダウンフローを通したからであって、シンプルな API マッピングを引いたからではない。ヒトインザループの提出と下流チャネルとの関係——これらが本当のプロダクトであり、公開ルックアップではない。
統合する人への実務的な含意：active な phishing URL について GET /hosting が有用なルーティングデータを返すと仮定してはいけない。phish.report の認証つき case API（実際に提出フローを駆動する）を使うか、安価 TLD のロングテール用に自前の abuse 連絡先マッピングを維持するかのいずれか。
OpenBait の方針に対して何が変わったか
このケースを受けて 3 つの具体的なシフトを行った：
1. 検知の精度を、テイクダウン統合より先に投資する。当初は「phish.report のホスティングエンドポイントを wrapper する」のがテイクダウン改善で最もレバレッジが高いと見ていた。しかしヒット率 0% の結果でその判断が反転した。検知側のシグナル——具体的には、Let's Encrypt 証明書 1 枚に複数のブランド関連 SAN を載せる kit オペレーター指紋（既存の CertStream パイプラインが見落としていた fan-out パターン）の識別——を先に投資している。この変更は今週本番に投入済み。
2. 中国系チャネルを first-class 機能として扱う。多くの国際 brand-protection ベンダー（Memcyco / Bolster / Axur / Fortra/PhishLabs）は西側チャネルに強く中国系チャネルに弱い——自動化に英語前提の abuse-channel 直感が組み込まれていない、12321 や DNSPod との固定 reporter 関係がない、中国語の ops デスクがない。顧客層やブランド言及が中国を跨ぐ日本の中堅企業にとって、これが効く。Tencent / 12321 / 360 のテンプレートを既存の GoDaddy / Namecheap / Cloudflare と同等の status で優先する。
3. Google Safe Browsing を主力指標としない正直さ。西側ブラウザの並列カバレッジとしてはスタックに残るが、「Google Safe Browsing 応答時間」を SLA に置いた人は、.cn .ru .kp インフラで実際に攻撃を受けた日に Google にレバレッジが効かないことを思い知ることになる。誠実な再フレーム：Safe Browsing は被害者保護レイヤーであり、テイクダウンレイヤーではない。
持ち帰れる要点
ブランド保護を内製で回している場合、次の攻撃が来る前に自分のインフラで確認しておくべきこと 3 点：
- 過去に
.cnサイトを停止できたことはあるか。ない場合、中国系ホスト型攻撃が来た日にスタックが機能しない可能性が高い。今すぐテストできる：継続稼働中の phishing kit に対して Tencent / 12321 へ提出し、自分の応答時間を観測すれば客観データになる。 - レジストラからチャネルへのルーティングロジックは何か。WHOIS の単純ルックアップだけでは登録元レジストラは分かるが、実際に応答する abuse チャネルは分からない。case ボリュームの上位 10 レジストラについて、実際に最速で応答するチャネル（フォールバック経路含む）にマップしておくこと。phish.report のレジストラ別 contact ページは出発点として無料。
- Google Safe Browsing を SLA としない。顧客が使うすべてのブラウザエンジン（QQ / 360 / UC / Baidu などの中国系ブラウザを含む）にわたって、ブロックリスト警告までの時間を計測すること。クロスボーダーブランドの場合、GSB のみの指標は実顧客保護面の半分を過小評価する。
OpenBait を既に運用している場合、SAN fan-out 検知の改善は scout パイプラインに今週投入済み——お客様側でアクション不要。中国系チャネルテンプレートと 12321 / Tencent 統合は次の P1。
評価中の方は無料枠（1 ブランド・5 Canary トークン・月 3 件のテイクダウン）で、自社管理のドメインを対象にお試しできる。Memcyco との比較や、より広い brand-protection SaaS 比較 は公開しており、勝てない領域も明示してある。
関連記事
参考資料
関連記事
フィッシング対策の実装ガイド — 検知・テイクダウン・顧客防御を一つの運用に束ねる
フィッシング攻撃を受け続けている企業向けに、CT ログ監視・タイポスクワッティング検知・registrar abuse 通報・ブラウザブロックリスト・JavaScript SDK による顧客側保護を一連の運用フローとして組む方法。中堅企業 300〜2,000 人規模を念頭に、それぞれの工程で何を自動化するかを整理する。
フィッシング被害に遭ったら — 48 時間以内にやるべき 7 ステップ
自社ブランドがフィッシングに悪用されたと判明した直後の 48 時間で何をすべきか。被害範囲の特定、証拠保全、ユーザー警告、レジストラ通報、ブラウザブロックリスト並行提出、再発防止まで、順序化された playbook。
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.