サブドメイン監視とは？増減・放置・再公開を継続検知する方法

サブドメイン監視とは何か

棚卸し と 継続監視 の違い

サブドメイン棚卸しは、ある時点で「何が存在しているか」を一覧にする作業です。とても重要ですが、あくまでスナップショットです。棚卸しだけでは、来週追加されたサブドメイン、昨日までは死んでいたのに今日また応答するようになったホスト、委託先が DNS だけ残してサービス本体を消した状態までは追えません。

一方のサブドメイン監視は、「前回と比べて何が変わったか」を見続ける運用です。運用の視点で言い換えると、棚卸しは基準線を作る作業、監視は基準線から外れた変化を捉える作業です。ここを混同すると、一覧はあるのに危険な再公開やdangling CNAMEを見逃しやすくなります。

OWASP Attack Surface Analysis Cheat Sheet↗でも、アタックサーフェスは一度図にして終わるものではなく、変化に合わせて見直し続ける対象として扱われています。外部公開面は「あるか、ないか」だけではなく、「どう変わったか」が重要です。

監視対象を 新規 / 消失 / 再公開 / 危険変更 / 所有者不明 に分ける

監視対象をただ「全部見る」と考えると、通知が増えた瞬間に運用が破綻します。現場で回しやすいのは、差分を 5 つに分ける方法です。新規は新しく見つかったサブドメイン、消失は以前は応答していたのに現在は変わったもの、再公開は不要になったはずのホストが再び応答し始めたもの、危険変更は CNAME や NS、TTL、証明書、ログイン面などの重要な変化、所有者不明は存在していても誰が責任を持つのか分からない状態です。

この 5 分類で見ると、監視は「数を増やすこと」ではなく、「危険な差分だけを拾って責任者へ戻すこと」に変わります。ここまで整理できると、通知の多さに埋もれず、対応優先度も付けやすくなります。

なぜ今サブドメイン監視が重要なのか

変更は 攻撃 ではなく 運用のゆるみ から始まる

サブドメインの事故は、ゼロデイや巧妙な侵入だけで始まるわけではありません。多いのは、プロジェクト終了後の削除漏れ、制作会社に任せたCNAMEの残置、担当者しか知らない管理画面、サービス停止前後の順序ミスです。つまり、最初の原因は「攻撃者の強さ」ではなく「組織側のゆるみ」であることが多いのです。

Microsoft Learn の subdomain takeover 解説↗でも、頻繁に作成・削除されるリソースを持つ組織ほど、DNS が残り、向き先のリソースだけが消えることで高重大度リスクが生まれると説明されています。これは高度な脆弱性というより、ライフサイクル管理の不整合です。

Hazy Hawk や subdomain takeover 事例を解説

2025 年 5 月 20 日に公開されたInfoblox の Hazy Hawk 解説↗は、この問題が理論ではなく現実の攻撃であることをよく示しています。Infoblox は Hazy Hawk を少なくとも 2023 年から活動していた DNS に詳しい脅威アクターと説明し、2025 年 2 月に検知したとしています。特に重要なのは、彼らが高信頼ドメイン配下のサブドメインを、削除済みクラウド資源に向いたdangling CNAMEで乗っ取った点です。

しかも目的は単なる改ざんではありません。Infoblox によれば、放置された向き先のリソース名を先に取り直し、正規ドメインの信頼と SEO 可視性を悪用しながら、大量の悪性 URL を配信していました。さらに訪問者の地域や端末に応じて送り先を変えるTDS（Traffic Distribution System: 訪問者属性に応じて遷移先を出し分ける仕組み）も使い、詐欺ページ、偽アンチウイルス、マルウェア配布、フィッシングへ誘導していました。ここから分かるのは、攻撃者に必要なのが必ずしも脆弱性の悪用そのものではないことです。

さらにMDN の Subdomain takeover 解説↗でも、危険なのはCNAME はあるがホストがない状態だと整理されています。設定の削除順と所有確認の弱さだけで、信頼されたサブドメインが攻撃者の足場になってしまう点が、読者にとって最も重要な発見です。

監視すべき項目はどこまで含めるべきか

サブドメイン監視は名前の有無だけでは足りません。実務で本当に使える監視にするには、DNS、証明書、実際の公開状態を一緒に見て、「危険な差分かどうか」を判断できる必要があります。

DNS レコード、CNAME、NS、TTL の変化

まず基礎になるのは DNS です。A、AAAA、CNAME、TXT、NS、MX を全部同じ重みで見る必要はありませんが、少なくとも外部公開面に直結する A / AAAA / CNAME と、委任や運用の意図が見える NS / TXT は差分監視の中心に置くべきです。

特にTTLは見落とされがちです。TTL は DNS 情報をどれくらいの時間キャッシュしてよいかを表す値で、極端に短くなっている場合は切替作業や不安定な運用の兆候になり得ます。CNAME の向き先変更、NS の変更、急な TTL 変更は「危険変更」の候補として別枠で扱う方が安全です。

SSL/TLS 証明書、失効、期限、SAN の変化

DNS だけでは見つからない変化を拾うのが証明書です。公開証明書のSANは、その証明書がどのホスト名をカバーしているかを示す一覧で、台帳にないサブドメインや、想定外に残っている古い名前を見つける手掛かりになります。

MDN の Certificate Transparency 解説↗の通り、CT ログは公開証明書の発行記録を外から観測できる仕組みです。新しい証明書が出たのに台帳へ反映されていない、失効や期限が怪しい、SAN に用途不明の名前が混ざっている、といった差分は、DNS 変化がなくても監視対象に入ります。

公開状態、疎通、WAF、主要ポート、ログイン面の露出

最後に見るべきなのは「本当に外へ出ているか」です。HTTP 応答、タイトル、TLS 設定、主要ポートの応答、ログイン画面や管理画面の有無は、単なる名前一覧よりも実害判断に直結します。WAF（Web Application Firewall）の有無や応答の変化も、再公開や設定変更の兆候になります。

サブドメインを継続的に見つける方法

passive discovery と Certificate Transparency logs

最初の入口はpassive discoveryです。これは自社ドメインへ積極的に大量通信を打ち込むのではなく、外部に公開されている情報や観測可能な証跡からサブドメイン候補を集める方法を指します。ProjectDiscovery の Subfinder Overview↗でも、passive subdomain enumeration は外部ソースを組み合わせて候補を集める考え方として説明されています。

CT ログも同じ文脈で有効です。新しい証明書が出たのに台帳へない名前は、新規サブドメインや再公開のヒントになりやすく、しかも DNS だけでは拾えないケースがあります。passive discovery と CT を組み合わせると、「今見えている公開面」と「最近外部へ出た可能性がある面」の両方を押さえやすくなります。

DNS provider 連携と authoritative source の確保

ただし、外から見える情報だけで運用を閉じるのは危険です。最終的な正本は、自社が管理している DNS provider や authoritative DNS に戻す必要があります。authoritative source とは「そのドメインの正式な設定を持つ正本」のことで、ここに戻れないと差分の真偽判定ができません。

実務では、外から見える情報を起点に候補を拾う outside-in で発見し、DNS provider や台帳で確認し、owner に戻す流れが最も安定します。外から見える痕跡だけで削除判断まで進めるのではなく、必ず「正本の設定」と照合してください。

手作業のリスト管理が危険な理由

Excel やスプレッドシートだけでリスト管理すると、更新タイミングのばらつき、担当者依存、委託先からの戻し漏れ、M&A 後の台帳統合遅れが重なって、すぐに現実とずれます。最初は整理できていても、差分が 10 件、20 件と増えた時点で「どこから危険か」が見えなくなります。

危険なのは、一覧が古いこと自体より、古い一覧を根拠に安心してしまうことです。手作業のリスト管理は初期整備には向きますが、継続監視では outside-in の観測、authoritative source、owner 情報を往復させる設計が必要です。

実務で回るサブドメイン監視の運用フロー

サブドメイン監視は、毎日・毎週・毎月で見るべきものが違います。daily では危険な差分を止め、weekly では owner と用途を確認し、monthly では未整理の残骸を潰す、という三層に分けると運用が止まりにくくなります。

毎日の差分検知で止めるべきもの

毎日見るべきなのは、すべての差分ではなく「今日止めないと危ない差分」です。たとえば、新規に公開されたログイン面、CNAME の向き先変更、急に証明書が差し替わったホスト、以前は死んでいたのに再び応答し始めたサブドメインは優先度を高く置きます。

週次レビューで所有者と用途を確認する

週次では、daily で拾った差分を「誰の資産か」「何に使っているのか」へ戻します。ここを飛ばすと、毎日差分を見つけても、次の週にはまた owner 不明のまま残り続けます。用途確認はセキュリティ担当だけでは閉じないため、部門、制作会社、子会社、インフラ担当の合意点を作る場が必要です。

月次レビューで 不要停止 と 監視漏れ を潰す

月次レビューでは、差分の件数よりも「残り続けている未整理資産」を見ます。owner が空欄のサブドメイン、直近 30 日で CT ログに出たのに台帳へないホスト、古い証明書だけが残っている名前、停止済みのはずなのに DNS が消えていない資産は、ここでまとめて潰すのが現実的です。

複数ドメイン・子会社・委託先を含む場合の設計

ドメイン単位ではなく責任単位で見る

複数ドメインを持つ企業では、ドメイン単位だけで管理すると「見えているけれど誰も引き取らない」差分が増えます。実務では、ドメイン名より先に、責任部署、ブランド、委託先、子会社といった責任単位で見る方が回りやすいです。

全社側は outside-in の差分検知と優先度付け、各責任単位は用途確認と修正を持つ形にすると、全体最適と現場対応の両方を両立しやすくなります。

制作会社、代理店、旧キャンペーンサイトの扱い

制作会社や代理店が作った microsite は、最も「正規っぽいのに owner が曖昧」になりやすい資産です。キャンペーン終了後も DNS だけ残り、証明書だけ更新され、広告 URL や過去の配布資料だけが残るケースは珍しくありません。

少なくとも、委託先が公開面を作る場合は、命名規則、停止前チェック、DNS 削除責任、TXT / 管理者情報更新、証明書管理、契約終了後の確認期限までを明文化しないと、監視は後追いの事故対応になりやすいです。

M&A 後やブランド別で監視が漏れやすい場所

M&A 後のドメインは監視漏れの代表例です。買収前から存在したブランドサイト、旧採用サイト、製品サポートドメイン、国別ドメイン、パートナー向けサブドメインなどが残りやすく、しかも親会社の台帳へ取り込まれるまで時間差が生まれます。

ブランド別運用も同様で、コーポレート、EC、メディア、採用、IR などが別チームで管理されていると、誰も全体差分を見ていない状態が起きます。したがって、複数ドメイン環境では全社共通の監視面と各チームの責任面を分けて設計するのが現実的です。

見落としやすい危険シナリオ

dangling CNAME とサービス廃止順の逆転

最も典型的なのが、サービス本体を削除してから DNS を消すパターンです。GitHub Docs↗もAzure App Service の防止策↗も、削除順の重要性と所有確認の必要性を繰り返し説明しています。停止チケットは閉じているのに DNS だけ残る、というのが一番危険です。詳しくはdangling DNS / subdomain takeover の整理記事でも、再取得の流れを別途まとめています。

ステージングの再公開と証明書だけ残るケース

staging 環境は「誰も使っていないはず」と思われがちですが、再公開事故の温床です。CDN や認証設定が消え、ホストだけ再び応答する、あるいは証明書だけ更新されて「死んだはずのホスト」が静かに復活するケースがあります。

ここで効くのが、HTTP 応答と証明書を一緒に見る監視です。DNS 変化がなくても、証明書の再発行や応答コードの変化は再公開の兆候になります。逆に、証明書だけ更新されているのに管理責任者が不明なら、かなり危険です。

wildcard DNS や深い階層サブドメインの放置

GitHub Pages のカスタムドメイン運用では、GitHub Docs↗が*.example.comのような wildcard DNS を強く非推奨として扱っています。理由は、一つの設定で多数のサブドメインへまとめて応答させるため、深い階層や想定外の名前まで危険領域にしてしまうからです。

wildcard DNS は便利ですが、監視難易度を大きく上げます。新しい名前が勝手に有効になる、深い階層が見逃される、担当者が想定していない名前でも応答し得る、といった問題が起きます。使うなら、通常より強い差分監視と所有確認が必要です。

サブドメイン監視なら ASM診断 PRO

発見から継続監視までを 1 本でつなげる

ここまで見てきた通り、サブドメイン監視は見つける、変化を追う、危険なものを優先する、責任者へ戻すまで一気通貫で回さないと機能しません。手作業でも不可能ではありませんが、ドメイン数や関係者が増えると、一覧の維持だけで時間が消えます。

ASM診断 PRO は、この「棚卸し後の運用」を前提にした導線を取りやすいのが強みです。まず Public 診断で外から見える公開資産の全体像をつかみ、その後、会員登録とTXT 認証を通じて Verified 側の継続監視、つまり所有確認済みドメインを継続的に見る運用へつなげることで、単発調査で終わらせずに運用へ移せます。

特に、どのサブドメインが危険か、どのドメイン群で差分が出ているか、どこから管理責任者確認や修正に入るべきかを整理したいチームに向いています。毎日の差分、週次の owner 確認、月次の不要停止を、人手だけで安定して回すには限界があります。ASM診断 PRO の価値は、検知そのものより結果を次の行動へ戻しやすいことにあります。

手作業 / 単発棚卸し / ASM診断 PRO の比較表で訴求する

運用チームが比較表から判断すべきこと

サブドメイン監視で本当に難しいのは、検知そのものより検知結果を放置しないことです。棚卸しだけでは「今見つかったもの」が中心になりますが、監視では「前回から変わったもの」が重要です。運用チームが必要とするのは、巨大な一覧より、差分と優先度です。

ASM診断 PRO はその点で、継続監視へ自然に接続しやすい設計を取りやすく、特に複数ドメインや委託先の残骸が混ざりやすい組織で価値が出やすいです。もちろん、ASM だけで全ての問題が解決するわけではありません。脆弱性診断やペンテストの代わりにもなりません。ただし、外部公開資産の変化を追い、何が増えたか、何が危ないか、誰に戻すかを継続的に見える化するという意味では、サブドメイン監視の土台になります。

よくある質問（FAQ）

サブドメイン棚卸しと監視は別々にやるべきですか

はい。棚卸しは基準線を作る作業、監視はその基準線からの差分を見る作業です。棚卸しだけでは今あるものは分かりますが、後から増えたものや再公開されたものは追えません。実務では、棚卸しを初期整備、監視を定常運用として分けて考える方が回しやすいです。

wildcard や動的に増えるサブドメインも監視できますか

できますが、通常より難易度は上がります。wildcard DNS は深い階層まで危険領域を広げやすく、GitHub Docs でも強い注意喚起があります。DNS 差分、HTTP 応答、証明書、所有情報を組み合わせて監視し、想定外の有効化を見つける必要があります。

複数ブランドや子会社のドメインをまとめて見てもよいですか

見るべきです。ただし、単に一つの一覧へ混ぜるのではなく、責任部署、ブランド、子会社、委託先の軸を持つべきです。全社横断で差分を検知しつつ、修正責任は各管理責任者に戻す形が現実的です。

脆弱性スキャナだけでは不十分ですか

不十分です。脆弱性スキャナは「存在している対象に対して何が弱いか」を見るのが得意ですが、「新しいサブドメインが増えた」「古いホストが再公開された」「dangling DNS が残った」といったライフサイクルの変化は別軸です。サブドメイン監視は、スキャナの前段にある母集団管理に近い役割です。

委託先が作ったサブドメインは誰が責任を持つべきですか

最終責任はドメインを保有する側が持つべきです。委託先が作成・運用する場合でも、停止時の DNS 削除、TXT / 管理者情報更新、証明書管理、サービス廃止順の確認は自社の統制に入れる必要があります。委託先任せにすると、契約終了後に最も危険な残骸が残りやすくなります。

まとめ

サブドメイン監視は、サブドメインを「見つける」ことより、「変化を追い続ける」ことに価値があります。特に重要なのは、新規、消失、再公開、危険変更、所有者不明の 5 分類で差分を捉え、daily / weekly / monthly で見る観点を分けることです。

実務では、棚卸しだけで終わらせず、所有確認、削除順の統制、委託先を含む責任分界、証明書や CT ログの監視までつなげる必要があります。まずは、自社のサブドメイン台帳に最終確認日、管理責任者、用途、停止手順が入っているかを確認し、そこから継続監視へ進めるのが現実的です。