類似ドメイン検知の実務ガイド — 認証基盤エンジニアが現場で使う 5 つの手法

認証基盤を運用していると、ある時期から類似ドメインの通報がサポート窓口にぽつぽつ届くようになります。最初は月に 1 〜 2 件。それが半年後には週 1 件、1 年後には週に複数件になる。そして気付くと、SOC のチケット処理能力を超えて、誰も見ていないキューに積み上がっていく——これが日本の中堅〜上場企業で起きている、類似ドメイン問題の典型的な進行パターンです。

「類似ドメインをどう見つけるか」は、現場で何度も議論されるテーマです。結論から言うと、「唯一の正解」はなく、複数のデータソースを組み合わせるしかない——これが実運用を通じた率直な答えです。この記事では、代表的な 5 つの検知手法を、それぞれの得意分野と落とし穴も含めて整理します。末尾には、OpenBait で使っている手法の組み合わせ方も書きました。

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

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

検知手法を選ぶ前に、何を検知したいのかを明確にする必要があります。実務で遭遇する類似ドメインは大きく 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 レスポンスと正規サイトを fuzzy hash で比較し、コンテンツが実際にコピーされているかを検知できる

落とし穴

• ブランド接続型は苦手：login-openbait.com のようなパターンは標準アルゴリズムでは生成されない。別途 keyword list を渡す必要がある
• 新規登録の監視はできない：一度列挙して終わり。翌週に新しい偽装ドメインが登録されても検知されない
• スケール問題：ブランドが 10 個あれば 10 回実行する必要があり、レポートを見る運用フローが必要

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

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

概要

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

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

CT ログは crt.sh、Facebook CT Monitoring、Censys などで検索可能で、RSS / API 購読もできます。

得意分野

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

落とし穴

• ノイズ量が膨大：openbait を含む証明書を監視すると、正規の *.openbait.com も全部ヒットする。フィルタリングロジックが必須
• 証明書取得後の検知：攻撃者が稼働を始めてから気付く。予防ではなく検知
• API レート制限：crt.sh は無料だが突き放した検索をかけると頻繁にタイムアウトする。監視するなら自前のキャッシュ＋差分抽出が現実的

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

検知手法 3 — Newly Registered Domains（NRD）feed

概要

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

得意分野

• 抜け漏れが少ない：CT ログと違い「証明書を取った瞬間」ではなく「ドメインを登録した瞬間」に拾えるので、典型的に 1 〜 7 日早い
• TLD 別フィルタリング：.top、.shop、.xyz などの悪用率が高い TLD だけに絞ると、ノイズを大幅に減らせる

落とし穴

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

検知手法 4 — Registrar bulk / zone file data

概要

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

得意分野

• 差分で新規登録を検知：前日のファイルと diff を取れば、当日登録されたドメインが全量わかる
• 無料（ただし申請と使用目的の記述が必要）
• 最も権威性が高いソース：registrar 経由ではなくレジストリ（Verisign 等）が直接配布

落とし穴

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

中堅企業が単独で運用するには荷が重いソースで、プラットフォーム事業者が抽象化して提供するのが実際的です。

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

概要

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

得意分野

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

落とし穴

• API 制限とコスト：Google Custom Search、Bing Search の API は無料枠が小さく、本格運用は有料契約
• 類似ドメインが未検出でも起こる：たとえば Google 広告だけで誘導するフィッシングでは、攻撃者はドメイン名を SEO で上げる必要がない

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

5 つの手法を単独で使うと、いずれも抜け漏れが発生します。現場での現実的な組み合わせは以下です。

OpenBait ではこれらを 1 つのプラットフォームに統合し、候補生成（dnstwist 系 + ブランド接続 + IDN ホモグリフ）、CT ログ日次購読、NRD feed 取り込み、検索エンジン監視までを自動化しました。無料の候補ジェネレータで自社ドメインの初期スナップショットを取り、継続監視が必要だと判断されたら無料枠で試していただけます。

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

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

実際に対応すべきは、

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

このいずれかを満たす候補のみで、残りは監視リスト扱いで十分です。OpenBait ではこの分類を自動化しています。

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