クラウド環境では、使わなくなったサービスを削除して終わり、という運用になりがちです。
しかし、DNSレコードだけが残ったままになると、外部から見ると「企業の正規ドメインに見えるのに、実体のクラウドリソースは存在しない」という状態が生まれます。この隙を悪用されると、攻撃者がそのサブドメイン上に任意のコンテンツを表示できる可能性があります。
今回取り上げるのは、Microsoft Azure Traffic Managerを利用していた本番環境で確認された、サブドメインテイクオーバーの事例です。派手な脆弱性というより、クラウドとDNSの運用上のズレから生まれる問題です。ただ、実際の影響は決して軽くありません。
TABLE OF CONTENTS
使っていないはずのサブドメインが、攻撃に使われる
サブドメインテイクオーバーとは、企業が管理しているサブドメインを、第三者が実質的に支配できてしまう状態を指します。
典型的なのは、DNSのCNAMEレコードが外部サービスやクラウドサービスを指したまま、その参照先のリソースだけが削除されているケースです。この状態は「ダングリングDNS」と呼ばれます。
たとえば、次のような流れです。
- 企業のサブドメインがAzure Traffic Managerを参照している
- しかし、参照先のTraffic Managerプロファイルはすでに削除されている
- DNSレコードだけが残り、インターネット上から引き続き参照できる
- 第三者が同じ名前のクラウドリソースを取得できる状態になる
- 結果として、企業の正規サブドメイン上に第三者のコンテンツが表示される可能性がある
見た目は企業の正規ドメインです。利用者や取引先が疑わずアクセスしてしまう点が、この問題の怖いところです。
今回確認された構成
今回のケースでは、公開されている本番用サブドメインが、Azure Traffic Managerの管理ドメインをCNAMEで参照していました。
以下は、対象サブドメインのDNS参照先を確認した際の画面です。CNAMEレコードがクラウドサービス側の管理ドメインを指していることが分かります。
| 項目 | 内容 |
|---|---|
| 対象サービス | Microsoft Azure Traffic Manager |
| 攻撃のきっかけ | 不要になったクラウドリソースを指し続けるCNAMEレコード |
| 脆弱性の分類 | サブドメインテイクオーバー |
| 露出していた対象 | 外部公開されている本番系サブドメイン |
| 想定されるリスク | 高 |
調査時点では、DNS上ではサブドメインが引き続き解決される一方で、参照先のAzure Traffic Managerプロファイルは有効な状態ではありませんでした。つまり、DNSとクラウドリソースの管理状態がずれていたことになります。
このような状態は、障害や移行作業の後に残ることがあります。特に、クラウドリソースを削除する担当者とDNSを管理する担当者が異なる場合、見落としが起こりやすくなります。
何が問題だったのか
DNSレコードだけが残っていた
本来、クラウドリソースを削除した場合、そのリソースを指していたDNSレコードも同時に削除または更新する必要があります。
しかし、今回のようにDNSレコードだけが残ると、外部からは「そのサブドメインはまだ何かを参照している」ように見えます。一方で、実際のクラウド側の受け皿は存在しません。
この状態が続くと、第三者が同名または対応するクラウドリソースを作成し、残されたDNSレコードを利用できてしまう可能性があります。
企業ドメインの信頼がそのまま悪用される
サブドメインテイクオーバーが厄介なのは、攻撃者がまったく知らないドメインを使うわけではない点です。
利用されるのは、企業が所有する正規のドメイン配下のサブドメインです。ブラウザのアドレスバーにも、見慣れた企業ドメインが表示されます。
そのため、利用者は不審なURLだと気づきにくくなります。社内ポータル、検証環境、キャンペーンページ、ログイン画面などに見せかけたページが置かれた場合、フィッシングや認証情報の窃取につながる可能性があります。
検証で確認されたこと
今回の調査では、許可された範囲で安全に検証が行われました。
まず、DNSの状態を確認し、対象サブドメインがAzure Traffic Managerの管理ドメインを参照していることを確認します。そのうえで、参照先のクラウドリソースが有効に存在していない状態であることを確認しました。
次に、管理された検証環境において、対象サブドメインが外部のコンテンツを返せる状態になるかを確認しました。
検証環境の設定後、DNSの解決状況を改めて確認しました。対象サブドメインが意図した参照先に解決されることを確認し、次にHTTP応答の確認へ進みます。
その後、HTTPリクエストを送り、対象サブドメインから外部のコンテンツが返されるかを確認しました。
結果として、当該サブドメイン上で第三者が用意したコンテンツを表示できる可能性があることが確認されています。
ここで重要なのは、攻撃に高度なマルウェアやゼロデイ脆弱性が必要だったわけではないという点です。DNSとクラウドリソースの管理不整合が、そのまま攻撃面になっていました。
なぜ気づきにくいのか
サブドメインテイクオーバーは、通常の脆弱性診断だけでは見落とされることがあります。
理由のひとつは、問題の所在がアプリケーションコードではなく、DNS、クラウド設定、資産管理の境界にあるためです。
- アプリケーション側には脆弱性が見つからない
- クラウドリソースはすでに削除済みで、管理画面上では問題に見えない
- DNSレコードは残っているが、誰も日常的に棚卸ししていない
- 一時的な検証環境や古いサブドメインが放置されやすい
- 担当部署が分かれており、削除作業とDNS整理が連動していない
現場で見る限り、この種の問題は「誰かが大きなミスをした」というより、運用の隙間に残りやすい問題です。だからこそ、個人の注意力だけに頼るのは危険です。
悪用された場合に起こり得る影響
サブドメインテイクオーバーが悪用された場合、影響は単なる表示改ざんにとどまりません。
- 企業の正規サブドメインを使ったフィッシングページの設置
- マルウェアや不正ファイルの配布
- 顧客や取引先のアクセス先の誘導
- ブランドなりすまし
- フォーム入力情報や認証情報の窃取
- Cookieやトークンの設定状況によっては、追加の攻撃につながる可能性
- 問い合わせ対応、広報対応、信用低下などの二次的な負荷
特に企業ドメイン配下で不正ページが表示されると、利用者側から見た信頼性が非常に高く見えてしまいます。メールやSNSで誘導された場合でも、URLだけを見て「正規のサイトだ」と判断される可能性があります。
攻撃者にとっては、信頼されたドメインを使えること自体が大きな武器になります。
原因はクラウドとDNSのライフサイクル管理のずれ
今回の根本原因は、Azure Traffic Managerのリソース削除とDNSレコードの整理が連動していなかったことです。
より具体的には、次のような管理上の課題がありました。
- 削除済みのTraffic Managerプロファイルを参照するDNSレコードが残っていた
- 使われていないCNAMEレコードを定期的に確認する仕組みがなかった
- クラウドリソースとDNSレコードの対応関係が台帳化されていなかった
- リソース削除時にDNS確認を行う変更管理プロセスが弱かった
- 外部公開資産の棚卸しが十分ではなかった
クラウド環境では、リソースの作成と削除が簡単です。その一方で、DNSは別の管理画面、別の担当者、別の運用ルールで管理されていることが珍しくありません。
この「簡単に作れるクラウド」と「残り続けるDNS」の組み合わせが、サブドメインテイクオーバーの温床になります。
企業が確認すべきポイント
同じような問題を防ぐには、まず外部に公開されているDNSレコードを棚卸しすることが重要です。
1. 使われていないCNAMEレコードを確認する
外部サービスやクラウドサービスを参照しているCNAMEレコードを洗い出します。
特に、次のようなサービスを指しているレコードは注意が必要です。
- Azure Traffic Manager
- Azure App Service
- Azure Front Door
- CDNサービス
- SaaS型のWebホスティングサービス
- 検証環境や一時公開用のクラウドサービス
参照先のクラウドリソースが存在しているか、現在も利用されているかを確認してください。
2. クラウドリソース削除時の手順にDNS確認を入れる
クラウドリソースを削除する際は、関連するDNSレコードも必ず確認する運用にします。
削除申請書や変更管理フローがある場合は、次の確認項目を追加すると実務に乗せやすくなります。
- このリソースに紐づく独自ドメインはあるか
- 該当するCNAME、A、AAAA、TXTレコードはあるか
- 削除後に残す必要があるDNSレコードか
- 移行先がある場合、DNSの向き先は更新済みか
- 削除後に外部からアクセスした際、不審な応答になっていないか
3. 外部公開資産の台帳を作る
サブドメイン、参照先サービス、管理部署、利用目的、最終確認日を一覧化しておくと、放置された資産を見つけやすくなります。
| 管理項目 | 確認内容 |
|---|---|
| サブドメイン | 例：service.example.co.jp |
| DNSレコード種別 | CNAME、A、AAAAなど |
| 参照先 | Azure、AWS、SaaS、CDNなど |
| 利用目的 | 本番、検証、キャンペーン、一時公開など |
| 管理担当 | 部署名または担当チーム |
| 最終確認日 | 棚卸しを行った日付 |
台帳は作って終わりではなく、定期的に更新されることが大切です。特に、キャンペーンサイト、検証環境、PoC環境は放置されやすいため、期限付きで管理するのが現実的です。
4. 継続的なDNS監視を行う
人の目だけで全てのDNSレコードを追い続けるのは、規模が大きくなるほど難しくなります。
そのため、外部公開資産の監視、DNSの差分検知、到達不能な参照先の検出などを継続的に行う仕組みがあると安心です。
特に、次のような変化は早めに検知したいポイントです。
- 新しいサブドメインが追加された
- 既存のCNAMEの向き先が変わった
- 参照先のクラウドサービスが存在しなくなった
- 以前は応答していたサブドメインが別の内容を返すようになった
- 所有者不明の公開資産が見つかった
確認時に気をつけたいこと
サブドメインテイクオーバーの調査は、影響の大きい検証になり得ます。
自社環境であっても、第三者サービス上にリソースを作成して検証する場合は、権限、影響範囲、ログ取得、関係者への共有を明確にしたうえで行う必要があります。
また、他社ドメインに対して同様の検証を行うことは、不正アクセスや迷惑行為とみなされる可能性があります。調査は必ず許可された範囲で実施してください。
予防側のホワイトハッカーとしては、「取れるかどうか」を試す前に、「取られ得る状態を見つけて安全に塞ぐ」ことを重視します。
クラウド時代のDNSは、単なる設定項目ではない
サブドメインテイクオーバーは、アプリケーションの脆弱性というより、資産管理と変更管理の問題として現れることが多いです。
クラウドサービスを削除した。検証環境を閉じた。キャンペーンサイトを終了した。そうした日常的な作業の後に、DNSだけが残っていないか。
この確認が抜けるだけで、企業の正規ドメインが攻撃者にとって使いやすい入口になることがあります。
派手な攻撃手法ではありませんが、実務上はかなり現実的なリスクです。特にクラウド利用が増え、短期間だけ公開される環境が増えている企業ほど、見直す価値があります。
セキュリティ対策というと、新しいツールや高度な検知に目が向きがちです。ただ、こうしたDNSの棚卸しやクラウドリソースの整理も、攻撃の入口を減らすうえでは非常に大切です。
使っていないサブドメインが本当に使われていない状態になっているか。まずはそこから確認してみるだけでも、見えてくるものがあります。
投稿者プロフィール
-
Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）
