類似ドメイン検知の実務ガイド — 5 つの手法と使い分け

類似ドメインの検知に**「唯一の正解」はなく、不完全な信号を組み合わせるしかありません**。しかも、それぞれに信じる前に知っておくべき落とし穴があります。この記事で扱うのは、dnstwist 型の候補生成、証明書透明性ログ（CT）、新規登録ドメイン（NRD）フィード、ゾーンファイル、検索・SNS 監視の 5 つです。

そして、OpenBait が予想していなかった結果も載せています。2026 年 7 月 25 日、自社のパイプラインを点検しました。「高」または「重大」と判定していた 347 件の候補から 100 件を無作為に抽出し、1 件ずつ確認したところ、稼働中のなりすましは 0 件、87 件はすでに存在していませんでした。数字は後半の「高スコアの候補 100 件は、実際には何だったか」にあります。候補を見つけるのは簡単です。難しいのは、どの候補に人の時間を使うかを決めることで、確認待ちの一覧を見る価値があるかどうかはそこで決まります。

類似ドメインを一度だけ試したい方は、無料のタイポスクワット候補ジェネレータでブランドドメインを入力すれば、候補一覧をその場で確認できます。

そもそも類似ドメインには何種類あるか

検知手法を選ぶ前に、何を検知したいのかを明確にする必要があります。実務で遭遇する類似ドメインは大きく 4 タイプに分かれます。

1. 文字変形型（dnstwist 系）

openbait.com に対する opnbait.com（文字削除）、oepnbait.com（文字転置）、opeen-bait.com（文字挿入）のような文字単位の変形です。攻撃者が手作業で登録するパターンと、自動生成で大量に登録するパターンがあります。

2. 同形字（ホモグリフ）型

ラテン文字 a をキリル文字 а、英小文字 l を数字 1 に置き換えるなど、見た目では区別が困難なドメインです。最近の主要ブラウザは Punycode で警告表示しますが、メール本文やメッセンジャーのリンクでは判定がユーザーに委ねられるため依然として有効な攻撃手段です。

3. TLD 置換型

openbait.com → openbait.co / openbait.shop / openbait.top など、主ドメイン名はそのままで拡張子だけ変えるタイプです。攻撃者がもっとも頻繁に使う手口です。理由は単純で、.com を押さえられたあとでも、新規 gTLD（.top、.xyz、.online など）は 1 ドル前後で登録できるためです。

4. ブランド名付加型

login-openbait.com、openbait-support.com、myopenbait.net のような、ブランド名の前後にキーワードをつなげたドメインです。dnstwist 系のアルゴリズムだけでは拾いきれません。

検知手法 1 — dnstwist によるオフライン列挙

概要

dnstwist（elceef）は、与えられたドメインから機械的に変形候補を列挙する OSS ツールです。Python 製、コマンドライン一発で動きます。

dnstwist openbait.com

得意分野

• 候補の網羅性：同形字、文字の挿入・削除・転置、キーボード配列による打ち間違いなど、想定される変形パターンを体系的に展開してくれます
• 無料で試せる：オフラインで実行するため、入力したドメインが外部に漏れません
• SSDEEP ハッシュの比較：オプションの --ssdeep を付けると、候補ドメインの HTTP レスポンスと正規サイトをファジーハッシュで比較し、コンテンツが実際にコピーされているかを検知できます

落とし穴

• ブランド名付加型は苦手：login-openbait.com のようなパターンは標準のアルゴリズムでは生成されません。別途キーワード一覧を渡す必要があります
• 新規登録の監視はできない：一度列挙して終わりです。翌週に新しい偽装ドメインが登録されても検知されません
• 規模が大きくなると手が回らない：ブランドが 10 個あれば 10 回実行する必要があり、結果を確認する運用フローが要ります

dnstwist は候補生成器としては優秀ですが、継続監視の仕組みではない。これが現場での立ち位置です。

検知手法 2 — Certificate Transparency ログの監視

概要

Certificate Transparency（以下 CT）は、Google が主導する TLS 証明書の公開ログシステムです。すべての信頼された CA が、発行した証明書を CT ログに記録することを義務付けられています。

これが類似ドメイン検知にとって意味するのは、攻撃者が Let's Encrypt などで証明書を取得した瞬間に、CT ログにドメイン名が公開されるということです。

CT ログは crt.sh、Facebook の CT 監視ツール、Censys などで検索でき、RSS / API での購読もできます。

得意分野

• ほぼリアルタイム：証明書の発行後、数秒〜数分でログに反映されます
• TLS の有効化は実害の直前：証明書が取得されたということは、攻撃者が本番運用に入る直前だということです。「まだ登録されただけ」の段階より確度が高くなります
• 公開情報なので無料：crt.sh は誰でもアクセスできます

落とし穴

• ノイズが膨大：openbait を含む証明書を監視すると、正規の *.openbait.com もすべてヒットします。絞り込みの処理が必須です
• 証明書の取得後に検知する：攻撃者が稼働を始めてから気付くことになります。予防ではなく検知です
• API の制限：crt.sh は無料ですが、広い範囲を検索すると頻繁にタイムアウトします。監視するなら、自前のキャッシュと差分抽出が現実的です

実務的には、CT ログ監視は週次〜日次で実行するバッチ処理として運用し、ヒットしたドメインを二次検証に回すフローが定番です。

検知手法 3 — 新規登録ドメイン（NRD）フィード

概要

ドメイン登録業界では、全 gTLD の新規登録ドメインを日次で束ねたフィードが流通しています。代表的なのは WhoisXML API や DomainTools のような商用サービスです。無料で使えるものでも、OpenPhish や urlscan.io が類似の情報を公開しています。

得意分野

• 抜け漏れが少ない：CT ログと違い、「証明書を取った瞬間」ではなく「ドメインを登録した瞬間」に拾えるため、たいてい 1 〜 7 日は早くなります
• TLD ごとの絞り込み：.top、.shop、.xyz など悪用率の高い TLD だけに絞ると、ノイズを大幅に減らせます

落とし穴

• 商用データは有料：日次で全 TLD を購読すると、年間数千ドル〜数万ドルかかります
• ブランドとの照合は自前：全ドメインから自社ブランドに似たものを抽出する照合処理が必須です。dnstwist の候補リストと突き合わせるのが現実的です
• 正当な登録との区別が難しい：たとえば openbait-jp.com が登録されたとき、それが代理店なのか偽装なのかは、登録直後には判断できません

検知手法 4 — ドメイン登録事業者・ゾーンファイルのデータ

概要

.com / .net のゾーンファイルは、ICANN の CZDS（Centralized Zone Data Service）を通じて、学術・研究・セキュリティ目的で利用を申請できます。承認されると、**1 日 1 回、その TLD の全ドメイン一覧（数億件）**をダウンロードできます。

得意分野

• 差分で新規登録を検知：前日のファイルとの差分を取れば、当日登録されたドメインが全量分かります
• 無料（ただし申請と使用目的の記述が必要です）
• 最も信頼できる情報源：ドメイン登録事業者経由ではなく、レジストリ（Verisign など）が直接配布しています

落とし穴

• データ量が大きい：.com のゾーンファイルは圧縮で数 GB、展開すると数十 GB になります。ストレージとメモリの設計が前提です
• TLD ごとに申請が必要：.com、.net、.jp（JPRS）、.tokyo などは個別の申請で、JP の ccTLD は条件が厳しくなります
• 運用保守のコスト：日次の差分処理パイプラインを構築し、運用する必要があります

中堅企業が単独で運用するには荷が重い情報源で、プラットフォーム事業者が扱いやすい形にして提供するのが実際的です。

検知手法 5 — 検索エンジン・SNS 監視

概要

Google / Bing / 百度で「自社ブランド名 + login」「自社ブランド名 + サポート」のような検索を定期的に実行し、検索結果に自社ドメイン以外が現れたら通報する、というシンプルな手法です。

得意分野

• ユーザー起点の発見：検索エンジンが評価して上位に出しているということは、ユーザーがそのドメインにたどり着く可能性が高いということです
• SNS と組み合わせると効果が大きい：X（旧 Twitter）、Instagram、TikTok の広告配信やアカウント名の監視と組み合わせると、ドメイン単体では拾えないソーシャル経由の誘導を捕捉できます

落とし穴

• API の制限とコスト：Google Custom Search、Bing Search の API は無料枠が小さく、本格運用は有料契約になります
• 類似ドメインが見つからなくても被害は起こる：たとえば Google 広告だけで誘導するフィッシングでは、攻撃者はドメイン名を検索上位に押し上げる必要がありません

高スコアの候補 100 件は、実際には何だったか

稼働中のなりすましサイトは 1 件もありませんでした。2026 年 7 月 25 日、OpenBait は自社の検知パイプラインを初めて実測で点検しました。「高」または「重大」と判定されていた 347 件から 100 件を無作為に抽出し、1 件ずつ DNS、HTTP、RDAP（登録状態）を確認した結果です。

消えていたドメインのうち少なくとも 5 件は、Cloudflare の「Suspected Phishing」警告画面か HTTP 451 を返しました。つまり実際にフィッシングサイトであり、すでに誰かが対処していたということです。上で紹介した手法は、フィッシング用のドメインを確かに見つけます。ただし見つけているのは「登録」であって、登録は攻撃ではありません。こうしたドメインの寿命は数日で、4 日前の検知結果は 94% がすでに消えていました。

ここから得た教訓は 2 つで、同じ仕組みを組むどの現場にも当てはまります。1 つ目は、実際に取得して応答があるまで、候補は「発見」ではないということ。名前の見た目ではなく、ページが何をしているかで判定してください（OpenBait のパイプラインは、347 件すべてで取得エラーを記録しながら「高」と判定していました）。2 つ目は、ブランド名の単純な部分一致がノイズの大半を生むということ。「jcb」を含む名前の多くは JCB と無関係です。OpenBait がいま入口を逆側、つまり実際にフィッシングサイトを踏んだ顧客からの通報に置き、類似ドメインの走査を補助的な位置づけにしている理由の多くは、ここにあります。

まとめ — 実務での組み合わせ方

5 つの手法を単独で使うと、いずれも抜け漏れが出ます。現場での現実的な組み合わせは次のとおりです。

OpenBait が実際に使っているのは、この 5 つのうち 4 つ相当です。dnstwist 系の類似名生成（文字変形・ブランド名付加・IDN ホモグリフ）、CT ログのリアルタイム取得、新規登録ドメインのリスト（WhoisDS NRD）、Google 検索で、ゾーンファイルの照合は行っていません。類似ドメインの確認は Free プランで 3 日ごと、Pro 以上で毎日、Google 検索はプランのキーワード数の範囲で行います。無料の候補ジェネレータで自社ドメインの初期スナップショットを取り、継続監視が必要だと判断した場合は、Free プランでお試しください。

最後に — 現場からの率直なアドバイス

類似ドメイン対策は、「見つけたら全部登録する」ではなく「見つけて評価し、対応を決める」が正解です。防御的登録は 1 ドメインあたり年間 10 〜 100 ドルかかるので、全候補を抑えようとすると年間数千ドル〜数万ドルになります。

実際に対応すべきなのは、次のいずれかを満たす候補だけです。

1. DNS が稼働している — 攻撃がすでに始まっているか、準備中
2. TLS 証明書が発行されている — 本番運用の直前
3. MX レコードが設定されている — メール送信にも使われる可能性

残りは監視リスト扱いで十分です。OpenBait のリスクスコアは出発点にすぎず、この分類を自動では完了できません。上の点検でも 347 件すべてを「高」と判定していたため、対応する候補は人が選びます。

日本の中堅〜上場企業のセキュリティチームにとって、類似ドメイン監視は「やらないわけにはいかないが、手が足りない」仕事の典型です。興味のある方は、OpenBait の Free プランで実際のデータをご覧ください。現場の判断材料になるはずです。