なぜフィッシングは特定のレジストラに集中するのか — 2026 年のドメイン経済地理
ブランド保護の現場で発見した偽サイトを 100 件まとめて WHOIS で引くと、登録元レジストラは上位 5 社で 70 % 以上を占める。ICANN 認定のレジストラは世界に 2,500 社以上あるのに、なぜここまで偏るのか——というのが本稿の問い。集中の構造を理解しておくと、takedown を「見つけた順に 1 件ずつ送る」運用から「レジストラ別の応答率に合わせて経路を切り替える」運用に変えられる。
業界データが示す集中の事実
Interisle Consulting Group が毎年公開している Phishing Landscape Report は、この問題を定量化した数少ない公開リソースだ。2024 年版の主要結論は 3 つに集約される。第 1 に、検出されたフィッシング URL のうちドメイン単位では特定の十数社に集中している。第 2 に、市場シェアに不釣り合いな量を捌いているレジストラが存在する——つまり「人気だから多い」ではなく、何か別の要因がある。第 3 に、Top 20 のリストは年を跨いでもほぼ同じ顔ぶれが残り、GoDaddy・Namecheap・NameSilo・Tucows・PublicDomainRegistry が常連として並ぶ。
レポートが断っているとおり、絶対数の多寡だけでは「悪用しやすさ」は測れない。GoDaddy のように世界最大手のシェアなら絶対数は単に大きい。一方で NameSilo のように市場シェアは中堅でも常に上位入りするレジストラは別の要因——後述する 3 つの構造——を備えている。
別の指標として Spamhaus Most Abused TLDs and Registrars があり、こちらはレピュテーション低下率で並べる。Interisle が「絶対数」を見るのに対し Spamhaus は「比率」を見るので、両方を突き合わせると「単に大きいから多い」と「シェア比で異常に多い」が分離できる。
集中する 3 つの構造的理由
価格と決済の組み合わせ
フィッシング犯にとってドメインは消耗品だ。被害者がクリックする前に発見されればドメインは寿命終了で、次のドメインに切り替える。1 ドメインあたりの単価が低いほど、攻撃の単位経済が成立しやすい。
.com の卸値（ICANN + Verisign）は約 10 ドル/年だが、一部のレジストラは 8.88 ドル / 9.99 ドルといった原価割れ寸前の小売価格を提示している。年間 100 ドル分の予算で 10 ドメインしか買えない vs 12〜15 ドメイン買えるの差は、検出される前に何ドメイン回せるかに直結する。
決済手段も効く。暗号通貨を受け付けるレジストラではクレジットカードのチャージバックリスクが消える。検出後に被害企業が決済を遡って取り消そうとしても、犯罪組織側のコストは発生しない。「価格の安さ × 暗号通貨決済」を両方備えているレジストラが、フィッシング経済の中で最もコスト効率がいい仕入先になる。
WHOIS プライバシーのデフォルト有効化
GDPR 以降、WHOIS の登録者情報を redact または proxy 化するレジストラが増えた。これは消費者にとっては妥当なプライバシー保護だが、副作用として攻撃者にも適用される。Interisle のレポートはこう書いている——「登録時点で登録者情報を自動的に隠蔽またはプロキシ化するレジストラは、悪意のある行為者に運用上の優位性を与える」。
注目すべきは「GDPR 適用外地域でもデフォルト有効化している」レジストラの存在で、これは技術的判断というよりビジネス判断（プライバシー重視の差別化マーケティング）として行われている。攻撃者からみれば、登録時に個人情報を渡さずに済む経路が選択肢として常時用意されているということになる。
Abuse 応答の温度差
最も見落とされがちで、最も実務に効くのがこの軸だ。同じ通報フォーマットを送っても、レジストラによって応答速度と真剣度が桁違いに違う。
| 対応水準 | 特徴 | 結果として起こること |
|---|---|---|
| プロアクティブ型 | 24 時間以内の応答、証拠確認、必要なら停止 | フィッシング犯は「ここはハイリスク」と判断して他に移動 |
| リアクティブ型 | 48〜72 時間で何らかの action | 「対応はしてくれる」評価で、犯罪者の中での優先度は下がる |
| サイレント型 | 自動応答メールのみ、数週間 action なし | 犯罪者の選好レジストラとして集中の入口になる |
サイレント型のレジストラに登録されたドメインは寿命が長い → より多くの被害者に届く → 犯罪者の ROI が高い → 次の登録もここを選ぶ、という正のフィードバックループが回る。Interisle の Top 20 リストに常連として残るレジストラの多くは、この「応答の遅さ」が市場での集中を生んでいる。
逆に Cloudflare Registrar や Porkbun のような新興プレイヤーが集中度の上位に入っていないのは、abuse 応答の早さで早期に「歓迎されないレジストラ」と認識されているからだ。これは技術的な対策というより、社内の abuse チームの予算と運用設計の差分として現れる。
Takedown 戦略への反映
集中構造を知ったうえで、ブランド保有者は takedown 経路を 3 つに分類して運用すべきだ。
応答型レジストラ——Namecheap、Tucows、Porkbun、Cloudflare Registrar など——に対しては abuse API か trusted reporter 制度を使う。証拠パッケージを標準化して自動送信し、平均応答時間を社内 SLA として計測する。固定 reporter アドレスから継続送信して信頼を積み上げると、3〜6 か月で優先処理に乗ることが多い。詳細は 通る registrar abuse 通報の書き方 で扱った。
沈黙型レジストラ——NameSilo・PublicDomainRegistry・一部の小規模 registrar——に対しては、レジストラ直送は補助的な経路として扱う。代わりに ブラウザブロックリスト 3 系統（Google Safe Browsing・Microsoft SmartScreen・Cloudflare 1.1.1.1）への並行提出と、ホスティング事業者（Cloudflare・AWS・OVH など）への abuse 通報をメインに据える。最後の手段として ICANN Compliance Portal への registrar 苦情申請があり、これは沈黙型レジストラが嫌がる数少ないエスカレーションになる。
API 受付停止中のレジストラ——GoDaddy が 2026 年第 2 四半期時点で trusted reporter API の新規受付を停止しているのが代表例——に対しては手動フォーム提出に切り替える。受付停止中でも reporter アドレスを継続的に使い続け、通報履歴は社内で残しておく。将来 API が再開された時点で「過去の通報品質」が trusted reporter 認定の評価対象になる可能性がある。
レジストラ別の応答率を社内データで持つ
集中の構造はレポートで読めるが、自社の業界・ブランド・通報頻度に固有の応答率は社内で計測しないと見えない。次の指標を半年分蓄積するだけで、takedown 戦略の精度が一段上がる。
レジストラ別の 24 時間以内応答率、平均 takedown 完了時間、ブラウザブロックリスト 3 系統への並行提出による補完率、そして「応答なしから ICANN Compliance に上げた件数とその後の解決率」——この 4 つを四半期ごとに見ると、自社にとってどのレジストラが「相手にしても応答が薄いから他経路に振るべき」かが定量的に判別できる。
OpenBait のプラットフォームでは、検出した偽ドメインの登録元レジストラ別に takedown ステータスを自動集計しており、上記 4 指標をダッシュボード上で日次更新で見られる構成になっている。中堅企業で社内集計を組む工数を取れない場合、この種の SaaS 経由で集計データを持つほうが TCO 的に妥当なレンジに収まる。
関連記事
参考資料
関連記事
フィッシング対策の実装ガイド — 検知・テイクダウン・顧客防御を一つの運用に束ねる
フィッシング攻撃を受け続けている企業向けに、CT ログ監視・タイポスクワッティング検知・registrar abuse 通報・ブラウザブロックリスト・JavaScript SDK による顧客側保護を一連の運用フローとして組む方法。中堅企業 300〜2,000 人規模を念頭に、それぞれの工程で何を自動化するかを整理する。
`.cn` フィッシングサイトを Tencent 経由で数時間で停止 — Google には 3 日反応されなかった件
顧客対応で実際に起きた事例。同じフィッシング URL を同じタイミングで Google Safe Browsing と Tencent abuse 通報の両方に出した結果。Tencent 側は 24 時間以内に停止、Google 側は 3 日経っても無反応。中国系インフラを跨ぐ可能性のあるブランドを守っている人が、テイクダウンスタックを設計し直すべき理由を整理する。
フィッシング被害に遭ったら — 48 時間以内にやるべき 7 ステップ
自社ブランドがフィッシングに悪用されたと判明した直後の 48 時間で何をすべきか。被害範囲の特定、証拠保全、ユーザー警告、レジストラ通報、ブラウザブロックリスト並行提出、再発防止まで、順序化された playbook。