サブドメインテイクオーバーとは？仕組み・被害事例・対策をわかりやすく解説

社内で使っていた開発環境やステージングサイトを外部クラウドから移行したとき、古いサブドメインのDNSレコードをそのまま残してしまっていませんか？その「消し忘れ」が、攻撃者に自社の正規ドメイン配下のページを乗っ取られる原因になります。

この記事では、サブドメインテイクオーバーの仕組みと実際の攻撃手口を解説し、情シス担当者が今日から実施できるDNS棚卸し手順と具体的な対策を詳しく紹介します。

サブドメインテイクオーバーとは？

サブドメインテイクオーバー（Subdomain Takeover）とは、企業が使わなくなったサブドメインのDNSレコードを残したまま外部サービスを解約・削除してしまった際に、攻撃者がそのサブドメインを「乗っ取って」自由にコンテンツを配信できるようになる脆弱性です。

脆弱性と聞くとソフトウェアのバグを思い浮かべる方が多いかもしれませんが、サブドメインテイクオーバーは純粋なソフトウェアの欠陥ではなく、DNSの「設定の消し忘れ」から生じる運用上の問題です。これが見落とされやすい理由の一つです。

では、なぜこれが深刻な問題になるのでしょうか。企業のドメイン（example.co.jp）のサブドメイン（staging.example.co.jp など）は、外部から見れば「example.co.jp と同じ組織が運営しているページ」に見えます。そのサブドメインを攻撃者が乗っ取ると、その企業になりすましたフィッシングページや悪意あるコンテンツを配信できるようになるわけです。

なぜ今、注目されているのか

サブドメインテイクオーバーの問題自体は以前から存在していましたが、ここ数年で急増した背景があります。

・クラウドサービスの普及: AWS・Azure・GCP・GitHub Pages・Herokuなど、サブドメインを使って外部サービスを公開する機会が増えた
・SaaSツールの急増: マーケティングツール・チャットツール・ドキュメントツールなど、カスタムドメイン設定ができるSaaSが急増し、使用後に解約してもDNSレコードを残しがち
・エンジニアの入れ替わり: 設定した本人が退職・異動すると「このサブドメインは何に使っていたか」が分からなくなり、削除できないまま放置される

特にスタートアップや成長期の中堅企業では、開発のスピードを優先するあまり、廃止した環境のDNSレコードが整理されないまま残るケースが多く見られます。

攻撃の仕組み（敵を知る）

攻撃者がサブドメインテイクオーバーを実行する流れを順を追って理解しましょう。手口を知ることが、最も効果的な防御につながります。

1. サブドメインの列挙（偵察フェーズ）

まず攻撃者はターゲット企業のサブドメインを大量に列挙します。これは合法的に行える方法が複数あります。

・証明書透明性ログ（Certificate Transparency Logs）の活用: SSL/TLS証明書の発行履歴が公開データベースに記録されており、「crt.sh」などのサービスで企業の全サブドメインを検索できます
・ブルートフォース: dev、staging、test、api、mail、status、app など、よく使われるサブドメイン名を総当たりで調べます
・Webアーカイブの利用: 過去のWebページのソースコードに記載されたサブドメインを収集します
・検索エンジンの活用: 検索エンジンで「site:example.co.jp」と検索すると、クロールされたサブドメインの一覧を取得できます

2. 「宙ぶらりん」なサブドメインの発見

列挙したサブドメインに対して、CNAMEレコードの先（向き先）が実際に稼働しているかを確認します。

# CNAMEレコードを確認
$ dig CNAME staging.example.co.jp +short
example-staging.s3-website-ap-northeast-1.amazonaws.com.

# 向き先のURLにHTTPリクエストを送って応答を確認
$ curl -s "http://example-staging.s3-website-ap-northeast-1.amazonaws.com/" | head -1
# "NoSuchBucket" や "NoSuchWebsite" が含まれていれば
# バケットは削除済みで乗っ取り可能な状態

外部サービスごとに「乗っ取り可能」を示すエラーパターンが異なります。代表的なものは以下のとおりです。

3. サブドメインの乗っ取り実行

宙ぶらりんなサブドメインを見つけたら、攻撃者は該当する外部サービスに「同じ名前」でリソースを作成するだけです。

・S3の場合: 削除されたバケットと同じ名前のS3バケットを攻撃者自身のAWSアカウントで作成し、静的ウェブサイトホスティングを有効化する。S3バケット名はグローバルで一意のため、先に作成できた者が勝ちです
・GitHub Pagesの場合: 攻撃者がGitHubリポジトリを作成し、Pagesのカスタムドメインにターゲットのサブドメインを設定する
・Heroku・Netlify・Fastlyなどの場合: 攻撃者のアカウントにアプリ・サイトを作成し、カスタムドメインとしてターゲットのサブドメインを追加する

この操作は特別な技術的難易度を要しません。攻撃者はターゲット企業のサーバーに一切アクセスすることなく、外部サービスの通常の利用手順だけで乗っ取りを完了できます。

【被害の深刻さ】乗っ取り後に何ができるのか

乗っ取ったサブドメインで攻撃者ができることは、想像以上に広範囲です。

・フィッシング詐欺ページの設置: 正規ドメイン（example.co.jp）のサブドメインから偽のログインページを表示できるため、利用者が本物と信じ込みやすい。フィッシングフィルターにも検知されにくい点が厄介です
・SSLサーバー証明書の取得: Let’s Encryptなどの認証局から正規のSSL証明書を取得でき、アドレスバーに鍵マークが表示されるHTTPSページを作れます
・Cookieの窃取: Cookieがドメイン全体（.example.co.jp）に有効な設定になっている場合、乗っ取ったサブドメインからCookieを読み取れるケースがあります
・SPAMメール送信基盤への悪用: 企業の正規ドメインを送信元に見せかけたフィッシングメールを大量送信する基盤として悪用できます

具体的な防御手順

1. 自社サブドメインの全件棚卸し

防御の第一歩は、自社のサブドメインを全て把握することです。DNS管理画面の一覧だけでなく、以下の方法も組み合わせて漏れなく洗い出しましょう。

# crt.shで証明書透明性ログからサブドメインを列挙（自社ドメインのみ）
curl -s "https://crt.sh/?q=%25.example.co.jp&output=json" | \
  python3 -c "import sys,json; data=json.load(sys.stdin); [print(d['name_value']) for d in data]" | \
  sort -u > subdomains.txt

# 得られたサブドメイン一覧のCNAMEレコードを一括確認
while read domain; do
  result=$(dig CNAME "$domain" +short 2>/dev/null)
  if [ -n "$result" ]; then
    echo "CNAME: $domain -> $result"
  fi
done < subdomains.txt

ツール操作が難しければ、DNS管理画面からレコード一覧をCSV形式でエクスポートし、スプレッドシートに整理するだけでも構いません。大切なのは「全件を一度可視化する」ことです。

2. CNAMEの向き先が有効かを確認する

CNAMEレコードが設定されているサブドメインについて、その向き先（外部サービスのホスト名）が現在も有効かどうかを確認します。

# 例: staging.example.co.jp のCNAMEと向き先を確認
$ dig CNAME staging.example.co.jp +short
example-staging.s3-website-ap-northeast-1.amazonaws.com.

# 向き先にHTTPリクエストを送って確認
$ curl -s "http://example-staging.s3-website-ap-northeast-1.amazonaws.com/" | grep -i "nosuch"
NoSuchBucket  # ← バケット削除済み。対処が必要

# NXDOMAINが返る場合も宙ぶらりんの可能性あり
$ dig staging.example.co.jp +short
# 空行が返ったりNXDOMAINステータスなら外部サービス自体がもう存在しない

自動化したい場合は、OSSのサブドメインテイクオーバー検出ツールが活用できます。

・subjack（Go製）: サブドメインのリストを渡すと、テイクオーバー可能なものをまとめて報告してくれます
・Nuclei + nuclei-templates: 多目的の脆弱性スキャナーで、サブドメインテイクオーバー向けのテンプレートが豊富に用意されており、自社ドメインの定期スキャンに活用できます

なお、これらのツールは自社が管理するドメインに対してのみ使用してください。

3. 不要なDNSレコードの即時削除

調査の結果、使われていないCNAMEレコードが見つかったら、迷わず削除します。「もしかしたらまだ使っているかもしれない」という思考が放置につながります。削除後に問題が発覚すれば、その時点で設定を復旧すれば良いのです。

削除の優先順位は以下を参考にしてください。

・向き先が「NoSuchBucket / NoSuchApp / NXDOMAIN」になっているもの: 今すぐ削除（最優先）
・向き先のサービスは有効だが、もう使っていないもの: まずサービス側でカスタムドメイン設定を解除してから、DNS側のレコードを削除する
・担当者が不明で確認が必要なもの: 担当者を探す間も、使われていないと分かった時点で削除する

4. 「サービス廃止の手順」を標準化する

個別のDNSレコード削除は対症療法です。根本的な解決のためには、クラウドサービスや外部SaaSを廃止する際の手順を標準化しましょう。

重要なのは「DNS削除を先に行う」という順序です。サービスを先に消してDNSを後で消そうとすると、多くの場合「後で」が永遠に来ません。これがサブドメインテイクオーバーが生まれる最大の要因です。

中小企業でも今日からできること

「情シスが1人しかいない」「専用ツールを導入する余裕がない」という環境でも、すぐに始められることがあります。

まず今日中にDNS管理画面を開き、CNAMEレコードの一覧を眺めてみてください。「このサービス、もう使っていないけどDNSレコードが残っているな」と気づいたものがあれば、担当者に確認するだけで大きなリスクを未然に防げます。

Linuxのdigコマンドを使ったDNS調査の詳しい手順については、姉妹サイトLinuxMaster.JPのネットワーク設定関連記事も参考にしてみてください。

よくある誤解と注意点

【誤解1】「HTTPSで鍵マークがついていれば安全」

サブドメインを乗っ取った攻撃者は、Let’s Encryptなどの認証局から正規のSSLサーバー証明書を取得できます。ブラウザの鍵マークや「https://」は「そのドメインに紐づく証明書を持つ者がサイトを運営している」ことを示すだけで、「あなたの会社が運営している」ことの証明ではありません。鍵マークがついた偽サイトが作られているケースがある点を覚えておいてください。

【誤解2】「うちの会社は規模が小さいから狙われない」

サブドメインテイクオーバーの検出は自動化ツールで大量のドメインを一括スキャンできるため、企業規模に関係なく発見されます。むしろクラウドサービスを積極的に使いながら管理が追いつきにくい中規模・中小企業のほうが、DNSレコードの消し忘れが起きやすい環境にあります。

【誤解3】「CNAMEレコードだけに注意すればいい」

CNAMEレコードの消し忘れが最も典型的なケースですが、ElasticIPやAzureのパブリックIPなど、Aレコード（IPアドレス直指定）でも同様の問題が起きることがあります。クラウドのIPアドレスは解放後に別の組織に再割り当てされる場合があるため、Aレコードについても使われていないものは削除するよう心掛けてください。

【注意】検証・調査は必ず自社ドメインの範囲内で

サブドメインテイクオーバーの検証ツールや手法は、必ず自社が管理するドメインに対してのみ使用してください。他社のサブドメインに対して許可なく調査操作を行うことは、不正アクセス禁止法に抵触する可能性があります。詳細は法律の専門家にご確認ください。

本記事のまとめ

サブドメインテイクオーバーは、攻撃者がターゲット企業のサーバーに一切触れることなく、正規のドメイン配下のページを乗っ取れる見落とされがちな脆弱性です。派手な攻撃手法ではありませんが、フィッシング詐欺に悪用された場合のブランド毀損や利用者の被害は深刻です。

まずは今日、自社のDNS管理画面を開いてCNAMEレコードを一覧化することから始めてみてください。「使っているかどうか分からない」レコードを一つ発見して削除するだけでも、確実にリスクを下げられます。