サブドメイン乗っ取り：DNSセキュリティガイド 2025 | 防止策

はじめに

サイバーセキュリティの急速な進化の中で、組織を悩ませ続ける脆弱性の一つがサブドメイン乗っ取りです。セキュリティチームがソフトウェアの脆弱性修正や高度な攻撃から防御に集中する一方で、放置されたクラウドリソースや忘れられたDNSレコードは、攻撃者が数時間で悪用できる見えないバックドアを作り出しています。サイバー犯罪者は未使用のサブドメインを悪用し、フィッシングサイトのホスティング、マルウェアの拡散、敏感なユーザーデータの取得を行い、信頼されたドメインを武器に変えてしまいます。

この包括的ガイドでは、サブドメイン乗っ取りの仕組みを解説し、攻撃者がこれらの脆弱性をどのように発見・悪用するかを明らかにし、あなたのデジタルインフラを守るための実践的な戦略を提供します。セキュリティの専門家、開発者、ビジネスオーナーの皆さんにとって、この脅威を理解することは、ブランドの信頼性を維持し、ユーザーを保護するために不可欠です。

サブドメイン乗っ取りとは？

サブドメイン乗っ取りの脆弱性は、企業のサブドメインの一つが存在しなくなったサードパーティサービスにポイントしている場合に発生します。これにより攻撃者はそのサービスを乗っ取り、サブドメインに表示される内容を制御できます。この単純に見える設定ミスが、攻撃者にとって信頼されたドメインから悪意のあるコンテンツを配信できる危険な状況を生み出します。

脆弱なサブドメインの構造

この脆弱性は、次のような予測可能な一連の流れから生じます：

サービスの提供：開発チームがサブドメイン（例：marketing.yourdomain.com）を作成し、AWS S3、Azure、GitHub Pages、Herokuなどのサードパーティサービスにポイントします。
DNS設定：DNSレコード（通常はCNAME）が作成され、トラフィックが外部サービスにルーティングされます。
サービスの廃止：プロジェクトが終了し、クラウドリソースが削除されても、DNSレコードは残ったままです。
脆弱性の窓：このようなDNSレコードは「ダングリングDNS」とも呼ばれ、攻撃者が同じリソース名を主張し、サブドメインの内容を制御する機会を生み出します。

これがビジネスにとって重要な理由

サブドメイン乗っ取りは重大なセキュリティリスクを伴います：フィッシング攻撃 — 攻撃者はサブドメインに悪意のあるコンテンツをホストし、メインドメインに対する信頼を利用します。データ窃盗 — ユーザが騙されて操作されたサブドメインとやり取りすることで、機密情報が盗まれる可能性があります。これらの影響は、技術的なセキュリティの問題を超え、ブランドの評判、顧客の信頼、規制遵守にも及びます。

実例：最近の事例

サブドメイン乗っ取りの脅威は理論だけではありません。世界中の組織がこれらの攻撃の犠牲となり、壊滅的な結果を招いています。

SubdoMailingキャンペーン

最近、「SubdoMailing」という大規模な広告詐欺キャンペーンでは、8,000以上の正規ドメインを利用して大量の詐欺メールを送信しました。ダングリングDNSレコードを悪用し、信頼されたドメインの評判を利用してメールセキュリティフィルターを回避し、サブドメイン乗っ取りの高度な大規模攻撃を示しました。

サプライチェーンへの影響

2024年10月から2025年1月にかけての調査では、削除されたAWS S3バケットに既存の参照が残っているものを探し、パイプライン管理やアプリケーション開発・展開に使用された可能性のあるバケットを特定しました。この調査は、サブドメイン乗っ取りがサプライチェーン攻撃に変貌し、開発パイプラインやソフトウェア配布メカニズムを危険にさらす可能性を浮き彫りにしました。

高度なインシデント例

政府のウェブサイト、フォーチュン500企業、人気プラットフォームなど、多くの組織がサブドメイン乗っ取りの被害に遭っています。例えば、トランプ政権のウェブサイトの改ざん事件もその一例です。これらの事例は、規模やセキュリティ成熟度に関係なく、どの組織もこの脆弱性から免れられないことを示しています。

よく狙われるサービスとプラットフォーム

どのサービスがよく悪用されるかを理解することで、セキュリティ対策の優先順位をつけやすくなります。以下は最も頻繁にターゲットとなるプラットフォームです：

クラウドストレージサービス

Amazon S3：バケットを削除しても、対応するDNSレコードを残しておくと、新たなサブドメイン乗っ取りの脆弱性を生むことになります。攻撃者はAWSコンソールから同じ名前の新しいS3バケットを作成し、すべてのコンテンツを制御できます。

Azure Blob Storage：S3と同様に、ストレージアカウントが削除されてもDNSレコードが残ると、攻撃者は一致する名前のアカウントを再作成できます。

Platform-as-a-Service (PaaS)

Heroku：削除されたアプリは、herokuapp.comドメインへのCNAMEレコードを残し、それを奪い取ることが可能です。
GitHub Pages：リポジトリを削除しても、対応するDNSエントリを削除しないと乗っ取りの機会が生まれます。
Shopify：移行や放棄されたECサイトは、脆弱なDNS設定を残すことがあります。
FastlyとCloudFront：CDN設定が削除されても、DNSレコードはアクティブなままです。

コンテンツ管理・マーケティングプラットフォーム

WordPress.com：非アクティブ化されたホスト済みブログのサブドメイン
HubSpot：放置されたランディングページを持つマーケティング自動化プラットフォーム
Zendesk：非アクティブなヘルプセンターにポイントするカスタマーサポートサブドメイン

サブドメイン乗っ取りの脆弱性発見ステップ

セキュリティ専門家やエシカルハッカーは、体系的なアプローチでこれらの脆弱性を特定します。理解しておくと、防御側と認定テスターの両方に役立ちます。

ステップ1：サブドメイン列挙

ターゲットドメインに関連するすべてのサブドメインを発見するフェーズです：

受動的手法： - 証明書透明性ログ：crt.shで対象ドメインに発行された証明書を検索 - DNSアグリゲーター：SecurityTrails、DNSDumpster、VirusTotalなどのサービスを利用 - 検索エンジンリコン：Googleダーク（例：site:*.example.com）を活用

能動的手法： - DNSブルートフォース：Sublist3r、Amass、Subfinderなどのツールを使い一般的なサブドメイン名をテスト - ゾーン転送試行：DNSサーバがゾーン転送を許可しているか確認（設定ミス）

ステップ2：DNSレコード分析

サブドメインを特定したら、そのDNSレコードを分析します：

# CNAMEレコードの確認
dig marketing.example.com CNAME

# NSレコードの確認
dig dev.example.com NS

# Aレコードの確認
dig blog.example.com A

外部サービスを示す応答や、「NXDOMAIN」やサードパーティプラットフォームを指すレコードを探します。

ステップ3：脆弱性の特定

プロビジョニングや解除（削除）の処理が適切に行われていない場合、攻撃者がサブドメインを乗っ取るチャンスが生まれます。脆弱性の主な兆候は：

存在しないリソースを指すCNAME：DNSレコードは存在するが、ターゲットリソースがない
エラーメッセージ：「404 Not Found」「NoSuchBucket」「ここにGitHub Pagesサイトはありません」
未請求のユーザ名：サービスがDNSレコードの名前と一致する名前を請求可能

ステップ4：検証テスト

脆弱性を報告する前に、実際に悪用できるか確認します：

リソースを請求：ターゲットプラットフォームで、DNSレコードのターゲットと一致するアカウントやリソースを作成
テストコンテンツを展開：ユニークで無害な識別子（例：「Proof of Concept by [Your Name]」）を配置
サブドメイン経由でアクセス：脆弱なサブドメインにアクセスし、コンテンツが表示されるか確認
詳細に記録：スクリーンショット、DNSレコード、乗っ取り成功例を保存

自動検出ツール

サブドメイン乗っ取り検出を効率化するツール：

SubOver：複数サービスの乗っ取り脆弱性をチェックするPythonツール
subjack：拡張されたサービス署名を持つGoベースのフィンガープリンティングツール
Nuclei：拡張性のある脆弱性スキャナーで、サブドメイン乗っ取りテンプレートを搭載
Can I Take Over XYZ：乗っ取り脆弱性のあるサービスの包括的データベース

攻撃の流れ（エシカル視点）

攻撃者がサブドメイン乗っ取りをどのように悪用するかを理解することで、防御側は対策を強化できます。

リコンナissanceフェーズ

攻撃者は、広範なリコンナissanceを行い、大規模なデジタルフットプリントと多数のサブドメインを持つ組織をターゲットにします。対象は： - 合併や買収中の企業（放置されたリソースの可能性が高まる） - マーケティングキャンペーンを頻繁に行う組織（仮設のランディングページ） - 多数の開発プロジェクトを持つテック企業

リソースの請求

脆弱なサブドメインを特定したら、攻撃は比較的簡単です：

特定されたサービス（AWS、Azure、GitHubなど）にアカウントを作成
DNSレコードに記載された名前と一致するリソースをプロビジョニング
ユーザートラストを悪用した悪意のあるコンテンツを展開

悪意のある活動

制御を確立したら、攻撃者は次のような行為を行えます：

フィッシング操作：組織の見落とし資産を利用して侵入せずに済む。信頼されたサブドメインに偽のログインページを作成し、資格情報を収集。

マルウェア配布：エクスプロイトキットや悪意のあるダウンロードを信頼されたドメインから提供。

データ収集：クッキー、セッショントークン、ユーザ提出情報を収集し、正規サービスに見せかける。

評判の毀損：サブドメインに不適切なコンテンツを掲載し、ブランドイメージを傷つける。

SEO操作：高権威のサブドメインにスパムコンテンツを作成し、検索順位を操作。

総合的な防御戦略

サブドメイン乗っ取りを防ぐには、多層的なアプローチが必要です。技術的コントロール、プロセス改善、組織の意識向上を組み合わせて対策します。

すぐにできる対策

サブドメイン監査：すべてのサブドメインとその目的、所有者を洗い出す。

DNSレコードの棚卸し：DNSレコードの完全なリストを作成し、特に外部サービスへのCNAMEを確認。

孤立したレコードの特定：廃止されたサービスや期限切れリソースにポイントしているDNSエントリは脆弱です。例：S3のプロジェクトを終了した後もDNSレコードが残っている場合、攻撃者はバケット名を奪取できます。

ダングリング参照の削除：不要なDNSレコードを削除します。

プロセスとポリシーの改善

廃止手順の確立：クラウドリソース削除前にDNSレコードを確実に削除する正式な手順を作成。プロジェクト終了時のチェックリストにDNSクリーンアップを必須化。

チェンジマネジメントの実装：DNS変更には承認と記録を義務付け、定期的な見直しを行う。

所有権の割当：すべてのサブドメインとDNSレコードに明確な所有者を設定し、管理責任を持たせる。

四半期ごとのレビュー：定期的にDNSレコードとクラウドリソースの監査を行い、誤設定を早期に発見・修正。

技術的コントロール

DNS監視：DNS変更を常時監視し、ダングリングレコードを検知するアラートを設定。

自動スキャン：SubOverやNucleiなどのツールを定期的に実行し、脆弱性を事前に検出。

クラウドリソースのタグ付け：すべてのクラウドリソースにプロジェクト情報とDNS関連付けを行い、追跡を容易に。

リソースの再利用防止：一部のクラウドプロバイダーはリソースの完全削除オプションを提供し、名前の再利用を防止します。

ワイルドカードレコードの注意：ワイルドカードDNSレコード（*）は一部の乗っ取りリスクを軽減しますが、他のセキュリティリスクも伴うため慎重に評価してください。

クラウドプロバイダーの保護策

主要クラウドプロバイダーは対策を講じていますが、その制限を理解することも重要です：

Azure：CNAMEレコードは特に脆弱ですが、Azureは特定のサービスに対してドメイン検証を要求し、所有権証明を行った後にカスタムドメインを追加可能にしています。

AWS：Route 53はエイリアスレコードを提供し、ターゲットリソースが削除されると自動的に消えますが、CNAMEレコードは依然脆弱です。

Google Cloud：多くのサービスでドメイン検証プロセスがあり、リスクは軽減されますが、完全には排除できません。

セキュリティツールと監視

サブドメイン乗っ取り検出をセキュリティワークフローに組み込みます：

継続的監視プラットフォーム：SecurityTrails、DNSdumpster、DetectifyなどはDNS変更や脆弱性を継続的に監視します。

バグバウンティプログラム：HackerOneやBugcrowdを通じて外部セキュリティ研究者にサブドメイン乗っ取りの発見と報告を促進。HackerOneのHacktivityフィードには、多くのサブドメイン乗っ取りの報告があります。

SIEM連携：セキュリティ情報とイベント管理システムに設定し、DNS変更や異常なサブドメイン活動をアラート化します。

サブドメイン乗っ取りへの対応

発見した場合は迅速に対応しましょう：

すぐにできる対応

乗っ取りの確認：サブドメインが実際に侵害されているか確認し、悪意のあるコンテンツを記録
DNSレコードの削除：攻撃者のコンテンツへのトラフィックを止めるために、該当のDNSレコードを直ちに削除
関係者への通知：セキュリティチーム、法務、関係部署に連絡
影響範囲の評価：提供されたコンテンツ、乗っ取りの期間、被害者数を調査

調査フェーズ

アクセスログの確認：利用可能ならDNSクエリログを分析し、被害範囲を把握
データ漏洩の有無：ユーザーデータや資格情報が収集されたか調査
フォレンジック分析：攻撃手法を記録し、今後の防止策に役立てる

事後対応

予防策の実施：根本原因に対処し、インフラ全体に教訓を適用
ユーザ通知：ユーザーデータが漏洩した場合は、法令に従い通知
規制当局への報告：必要に応じて関係当局に報告

長期的な防御のためのベストプラクティス

持続可能なセキュリティには、サブドメイン乗っ取り防止を組織文化に組み込むことが重要です：

開発チームの教育

開発者に対し、サブドメイン乗っ取りのリスクと対策を教育します： - DNSの衛生管理の重要性 - 適切な廃止手順 - セキュアなクラウドリソース管理

Infrastructure as Code (IaC)

DNSレコードをバージョン管理されたIaCで管理： - すべてのDNS変更をGitリポジトリで追跡 - ダングリングレコードを検出する自動検証を実装 - TerraformやCloudFormationなどのツールを利用

セキュリティ意識向上

セキュリティ意識向上プログラムにサブドメイン乗っ取りを含める： - 非技術者にもビジネスへの影響を説明 - 小さなミスが大きな脆弱性を生むことを示す - セキュリティは全員の責任である文化を育む

ベンダーマネジメント

サードパーティサービスを利用する場合： - DNSレコードがポイントしているサービスを記録 - ベンダー契約にリソース廃止に関する条項を盛り込む - セキュリティ懸念を通知するための連絡手段を確立

まとめ

サブドメイン乗っ取りは、忘れられたインフラ、クラウドの急速な普及、適切でない廃止プロセスの完璧な組み合わせです。攻撃者は、組織の見落とされた資産を巧みに利用し、重大な影響をもたらします。幸いにも、DNS管理の徹底、適切な廃止手順、継続的な監視によって、サブドメイン乗っ取りは完全に防止可能です。

このガイドで紹介した戦略—即時の監査から長期的なプロセス改善まで—を実施することで、組織はこの脆弱性を攻撃面から排除できます。セキュリティはゴールではなく旅路です。定期的な監査、自動化された監視、組織の意識向上によって、サブドメイン乗っ取りを見えない脅威から管理されたリスクへと変えることができます。今すぐ行動を起こし、サブドメインを棚卸し、ダングリングDNSレコードを整理し、将来の脆弱性を防ぐプロセスを導入しましょう。

あなたのブランドの評判とユーザーの信頼は、DNSレコードの見えないインフラにかかっています。忘れられた設定がバックドアとなり、セキュリティ投資を台無しにしないようにしてください。今日からサブドメイン監査を始め、攻撃者が既にあなたのダングリングDNSエントリを狙っていることを忘れずに。

著者について：この文章は、2025年10月時点の最新サイバーセキュリティのベストプラクティスに基づき、Microsoft Azure Security、CrowdStrike、OWASP、HackerOne、最近のサブドメイン乗っ取りキャンペーンに関する脅威インテリジェンスレポートなどの業界リーディングソースから調査・執筆されました。