サブドメインテイクオーバーという言葉は、セキュリティに関わる仕事をしていれば、一度は聞いたことがあると思います。
ただ、これを「実際に何が起きているのか」という視点で説明しようとすると、意外と難しいと感じることがあります。
というのも、この事象は、いわゆる“攻撃らしい攻撃”から始まるわけではありません。
脆弱性スキャンで赤く表示されるわけでもなく、アラートが大量に飛んでくるわけでもない。
多くの場合、きっかけはとても地味です。
たとえば、以前使っていたクラウドサービス。
もう使っていないけれど、DNS の設定だけは昔のまま残っている。
担当者が変わったり、構成が少しずつ変わったりする中で、「特に問題が起きていないから」と、そのままになっているケースです。
サブドメインテイクオーバーは、そうした使われなくなった設定が、誰にも気づかれないまま残っている状態から始まります。
攻撃というより、運用の隙がそのまま入口になってしまう。
現場で見ていると、そんな印象を持つことが多い事象です。
だからこそ、この問題は気づきにくい。
何かが壊れたわけでもなく、サービスが止まるわけでもない。
それでも条件がそろうと、第三者が正規ドメイン配下の一部を自由に使えてしまう状態が、静かに成立してしまいます。
TABLE OF CONTENTS
サブドメインテイクオーバーとは何が起きているのか
サブドメインテイクオーバーは、使われなくなった、あるいは設定が中途半端なまま残っているサブドメインのレコード（ダングリングレコード）を、第三者が事実上引き継ぐ形で成立します。
添付の画像にあるように、そのプロセスは「店舗の閉店」に例えると非常にイメージしやすくなります。
- まずは支店を開店し、看板を設置する状態（画像左）： 正規の管理者が「campaign.example.com」といったサブドメインを作成し、キャンペーンサイトなどの運用を始めます。この時点では、看板（DNS設定）と店舗（実際のコンテンツ）が正しく紐付いています。
- 支店を閉店した後も、看板を放置してしまう状態（画像中央）： キャンペーンが終了して店舗（サーバーやクラウドのリソース）は撤去したものの、「また使うかもしれないから」と看板（DNS設定）だけをその場に残してしまいます。これが「ダングリングレコード」と呼ばれる隙を生みます。
- 支店があった土地に、別の人が違法店舗を開店する状態（画像右）： 空き地になった場所に、第三者が勝手に新しい店を建ててしまいます。DNSの向き先が空いているため、攻撃者はそのドメイン名をそのまま利用して、自身のWebサイトを表示させることができてしまいます。画像にある「看板だけ使わせてもらおう！」というハッカーの言葉通り、正規の看板が立っている場所で、外部の人間が勝手に「違法店舗」が営業を開始するのです。
といっても、サーバーに侵入したり、アプリケーションを突破したりするわけではありません。ポイントになるのは、あくまで「DNSの向き先」です。DNSが参照している先に、すでに正規の管理者が存在しない、あるいはクラウド側のリソースが削除されている。そうした状態にもかかわらず、DNSだけが残り続けていると、正規ドメイン配下でありながら、外部の人間が自由に使えてしまう場所が生まれてしまいます。
現場でこの手の問題を見ていると、画像の中の管理者が「勝手に場所を使われてる！？」と驚いているように、「攻撃された」という実感を持たれにくいのが特徴だと感じます。サービスが落ちるわけでもなく、社内システムに不具合が出るわけでもない。ログを見ても、不審な侵入の形跡がはっきり残ることは多くありません。
ただ、その状態がフィッシングや偽サイトの踏み台として使われ始めると、話は変わってきます。URLは正規ドメイン配下、見た目も本物に近い。その結果、被害は社内ではなく、取引先やユーザーといった社外に向かって広がっていくことが多いのです。
そして気づいたときには、「技術的な問題」というよりも、ブランドや信頼といった、取り戻しにくいところで大きなダメージを負ってしまう。サブドメインテイクオーバーは、まさに「自社の看板が犯罪に利用される」という形で表に出てくるケースを、私は何度も見てきました。
今回の事例の前提条件
今回の事例は、プライベートなバグバウンティプログラムの中で確認されたものです。
公開環境ではなく、限られた範囲で実施されているプログラムでした。
- 対象範囲：サブドメインテイクオーバー
- 重要度：High
- プログラム種別：Private
- 申告日・修正日：同日対応
技術的に派手な手法は使われていません。
脆弱なコードを突くような話ではなく、DNS とクラウドサービスの間にある運用上の隙が、そのまま入口になっていました。
実務の感覚としては、こうしたケースは決して珍しくありません。
「高度な攻撃」よりも、「もう使っていないはずの設定」が原因になる。
今回の事例も、まさにその延長線上にありました。
偵察フェーズで最初に見るポイント
実際の調査に入る前に、いくつか必ず確認しているポイントがあります。
どれも地味ですが、ここを押さえておくかどうかで、その後の進め方が大きく変わります。
ワイルドカード指定の有無
サブドメインテイクオーバーを調べるとき、最初に必ず確認するのがスコープの定義です。
特に、ワイルドカード指定が含まれているかどうかは重要なポイントになります。
たとえば、スコープに *.example.com のような記載があるかどうか。
この指定が明示されていれば、サブドメイン全体が調査対象として認められている、という判断になります。
逆に、ここが許可されていない場合、技術的には成立しているように見えても、
「報告としては対象外」という扱いになるケースがあります。
現場では、このあたりの確認を飛ばしてしまい、あとから認識のズレが生じることも少なくありません。
だからこそ、実際の調査に入る前に、
「どこまでが見てよい範囲なのか」「どこから先は対象外なのか」を、
一度落ち着いて確認しておくことが大切だと感じています。
サブドメイン列挙と DNS の確認
実務では、まず最初に対象ドメイン配下のサブドメインを一通り洗い出します。
ここを飛ばしてしまうと、そもそも入口になり得る場所を見落としてしまうからです。
今回の事例では、サブドメインの列挙に Subfinder を使いました。
派手なツールではありませんが、結果が安定していて、余計なノイズが少ない。
現場では、こうした「淡々と仕事をしてくれるツール」の方が結果的に信頼できると感じています。
サブドメインを一通り確認したあとは、それぞれの DNS の向き先を見ていきます。
ここで注目するのは、IP アドレスそのものよりも、「どのサービスを指しているか」です。
今回は、次のように dig コマンドで確認しました。
dig *.example.comその結果、返ってきたのが以下の CNAME レコードです。
*.example.com 600 IN CNAME *.trafficmanager.net.Azure Traffic Manager を指している状態ですが、実際にブラウザからアクセスしてみると、サイトは表示されませんでした。
一見すると、単に使われなくなった設定のようにも見えます。
ただ、この「参照はされているが、実体が存在しない」状態こそが、今回のポイントでした。
DNS は確かに Traffic Manager を向いている。
しかし、その先に正規のリソースが存在しない。
このズレがあると、条件次第では第三者がその名前を取得できてしまう余地が生まれます。
現場で調査をしていると、この段階で「これは少し嫌な状態だな」と感じることがあります。
今回も、まさにその感触がありました。
Azure Traffic Manager 側の状態
ブラウザで該当ドメインにアクセスすると、サイトは表示されません。
一見すると、単なる設定ミスや未使用のリソースにも見えます。
しかし、Azure 側で適切な関連付けがされていない場合、
第三者が新たに Traffic Manager を作成し、その名前を取得できる余地が残ります。
DNS は Traffic Manager を指しているものの、実体となるリソースは存在しない状態でした。
実際に起こり得ること
この状態をそのまま放置してしまうと、第三者が取り得る行動の幅は一気に広がります。
システムに侵入しなくても、正規ドメイン配下の一部を自由に使える状態になるためです。
具体的には、次のようなことが可能になります。
- 正規ドメイン配下に見える偽サイトの設置
- 企業やサービスを装ったなりすましページの公開
- マルウェア配布ページの設置
- フィッシングサイトへの誘導
ここで厄介なのは、URL そのものに不審な点がほとんどないことです。
ドメイン名だけを見れば、社内の人間でも「正規のページだ」と思ってしまう。
取引先や一般の利用者であれば、なおさら疑いにくい状態になります。
その結果、被害は社内で完結せず、ユーザーや取引先といった社外に向かって静かに広がっていくことがあります。
気づいたときには、技術的な問題というよりも、ブランドや信頼の話として表に出てきてしまう。
このタイプの事案で、よく目にする流れです。
正規ドメイン配下で、第三者が用意したコンテンツが表示される状態です。
技術的に特別な攻撃ではない
この事例で特に印象に残ったのは、
ゼロデイや高度な侵入技術が一切使われていない点でした。
目立つ攻撃手法は何もありません。
代わりに積み重なっていたのは、次のような要素です。
- すでに使われなくなったクラウドリソース
- 削除されないまま残り続けている DNS レコード
- 誰も定期的に見返していない設定
それぞれを一つだけ見れば、よくある運用の一場面です。
「今すぐ問題になるわけではない」と判断され、後回しにされがちなものでもあります。
ただ、こうした要素がいくつか重なったとき、
気づかないうちに入口ができてしまう。
現場で見ていると、サブドメインテイクオーバーは
まさに運用の延長線上で成立する問題だと感じることが多いです。
派手さはありませんが、だからこそ見落とされやすい。
今回の事例も、その典型だったように思います。
推奨される対応策
サブドメインテイクオーバーへの対策というと、何か特別なセキュリティ製品や高度な仕組みを想像されることがあります。
ただ、今回のようなケースでは、やるべきことは意外とシンプルです。
不要な DNS レコードの削除
まず意識したいのは、使われていない DNS レコードを残さないことです。
CNAME や A レコードが、過去の構成の名残としてそのままになっていないか。
クラウドリソースを削除したときに、DNS 側の設定まで一緒に見直されているか。
現場では、「リソースは消したつもりだったが、DNS までは見ていなかった」という状態をよく見かけます。
まずはここを一度、棚卸しするだけでも、リスクは大きく下げられます。
継続的な DNS 監視
DNS は、一度設定するとそのまま触られなくなることが多い領域です。
だからこそ、定期的に差分を見る運用が効いてきます。
- 以前と比べて向き先が変わっていないか
- 参照先のサービスが本当に存在しているか
こうした点を、定期的に確認するだけでも、「いつの間にかおかしな状態になっていた」という事態を防ぎやすくなります。
クラウドと DNS の対応関係を整理する
Traffic Manager や CDN のように、外部サービスに名前解決を委ねている構成は特に注意が必要です。
- このサブドメインは、どのサービスにひもづいているのか
- 誰が管理しているのか
- 削除するとき、どこまで確認すべきなのか
こうした対応関係をあらかじめ整理しておくだけで、「消したつもり」「誰かが見ているはず」という曖昧さを減らすことができます。
サブドメインテイクオーバーは、技術的な知識よりも、運用の整理がそのまま対策になるタイプの問題だと感じています。
使っていない設定ほど、静かに効いてくる
サブドメインテイクオーバーは、何かが壊れて初めて気づくタイプの問題ではありません。
サービスが止まるわけでもなく、エラーが表に出るわけでもない。
むしろ、何も起きていない状態が長く続くからこそ、その存在に気づかれないままになりがちです。
だからこそ、平常時に一度だけ、次のような点を静かに見直してみる価値があります。
- 使われていないサブドメインが残っていないか
- クラウドサービスと DNS の関係が整理できているか
どちらも、特別なツールや知識がなければできない確認ではありません。
ただ、日常の運用の中では、後回しにされやすいポイントでもあります。
現場で診断や調査をしていると、こうした一手間が結果的に、大きなトラブルを未然に防いでいるケースを何度も見てきました。
派手さはありませんが、確実に効く確認です。
この記事が、その見直しのきっかけになればと思います。
自社のセキュリティに不安を感じたら
