脅威の手口を解説: サブドメイン乗っ取りの仕組みと対策

本ブログは 2026 年 6 月 16 日に公開された AWS Blog “Threat tactic spotlight: Subdomain takeover” を翻訳したものです。

このブログ記事では、サブドメイン乗っ取り (subdomain takeover) を検出して防止する方法を説明します。サブドメイン乗っ取りとは、脅威アクターがダングリング DNS レコード (dangling DNS record) を悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトする手口です。この記事では、この問題の概要と発生する仕組みを説明し、さまざまな AWS の機能やサービスを使用してこの手口の影響を緩和する方法を紹介します。

責任共有モデルでは、クラウド内の設定のセキュリティを確保することはお客様の責任です。AWS は、強固なデフォルト設定、Well-Architected フレームワークのセキュリティの柱のガイダンス、およびセキュリティサービスを通じて、お客様がその責任を果たせるよう支援しています。また、AWS Customer Incident Response Team (AWS CIRT) は、お客様の特定の設定を悪用するために脅威アクターが使用する新たな手口や流行している手口を監視しています。これにより、お客様は十分な情報に基づいて設計上の判断を下し、対応計画を改善できます。

AWS CIRT は、サブドメイン乗っ取りの機会を狙う脅威アクターが、既に存在しないリソースを指すパブリック DNS の CNAME レコードを積極的にスキャンしていることを確認しています。

注: サブドメイン乗っ取りの手口は、AWS サービスの脆弱性を利用するものではありません。ダングリング DNS レコードを悪用して、トラフィックを攻撃者が管理するリソースにリダイレクトするものです。

DNS の基礎知識

CNAME レコード: CNAME (Canonical Name) レコードは、あるドメイン名を別のドメイン名に向ける DNS エントリです。例えば、api.example.com が api.example.s3-website-us-east-1.amazonaws.com を指すように設定できます。DNS のこの機能により、実際のリソースには機械的に生成された長い AWS ホスト名が割り当てられていても、お客様は覚えやすくわかりやすいドメイン名を設定できます。ただし、ターゲットのリソースを削除した後もそれを指す CNAME レコードが残っていると、「ダングリング」レコードとなり、セキュリティ上の問題が生じます。

ダングリングレコード: リソース (S3 バケットなど) を削除した後もそれを指す DNS レコードが残っている場合、その DNS レコードは存在しないリソースを指す「ダングリング」状態になります。グローバルに共有される名前空間内のリソースの場合、脅威アクターが削除済みのリソース名を取得し、お客様の DNS レコードを通じて悪意のあるコンテンツを配信できる可能性があります。

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

サブドメインとは、ドメインの前に付加するプレフィックスで、リソースへのアクセスを整理するために使用します。サブドメイン乗っ取りは、お客様が基盤となるリソースを削除した後、脅威アクターが同じ名前で新しいリソースを作成し、そのリソースを指したまま残っている DNS レコードを悪用することで発生します。

サブドメイン乗っ取りが起こり得るのは、グローバルに共有される DNS 名前空間を使用する AWS リソースを CNAME レコードが指している場合です。このような名前空間では、AWS のお客様であれば誰でもリソース名を選択できます。次の AWS リソースがこの条件に該当します。

Amazon S3 (グローバル名前空間): mybucket.s3.amazonaws.com のようなバケット名はグローバルに一意であり、バケットが削除されると、どのアカウントでもその名前を取得できます。注: アカウントリージョナル名前空間 (2026 年 3 月にリリース) を使用して作成された S3 バケットは、スコープがお客様のアカウントに限定されるため、この問題の対象にはなりません。

Amazon CloudFront: d111111abcdef8.cloudfront.net のようなディストリビューションのドメイン名は AWS によって割り当てられるため、攻撃者が選択することはできません。ただし、お客様がディストリビューションを削除した後、別のお客様が新たに作成したディストリビューションにたまたま同じドメイン名が割り当てられると、ダングリング CNAME を通じて、そのお客様のコンテンツが配信される可能性があります。

AWS Elastic Beanstalk: myapp.elasticbeanstalk.com のような環境名はグローバルに一意であり、環境を終了すると、どのアカウントでもその名前を取得できます。

Amazon VPC、Amazon EC2 インスタンス、プライベートホストゾーンなどのリソースは、グローバルに取得可能な DNS 名前空間を公開していないため、この手口の対象にはなりません。

MITRE ATT&CK では、この手法を T1584.001: Compromise Infrastructure – Domains に分類しています。

シナリオ例の分析

次のシナリオを考えてみましょう。

S3 ウェブサイトエンドポイントを指す DNS CNAME レコードを作成したとします。これにより、サブドメイン subdomain.example.com は subdomain.example.s3-website-us-east-1.amazonaws.com に解決され、subdomain.example という名前の S3 バケットからコンテンツが配信されます。チームがバケットを削除した際に DNS レコードの削除を忘れると、サイトにアクセスしたユーザーには、バケットが存在しないことを示すエラーが表示されます。しかし、この時点で脅威アクターがこのエラーに気付いてそのバケット名を取得すると、独自のサイトを構築できてしまいます。ユーザーが subdomain.example.com サイトにアクセスすると、そのサイトが表示されることになります。

図 1 は、静的ウェブサイトをホストするように設定された subdomain.example という名前の S3 バケット (グローバルに一意なバケット名) と、その S3 ウェブサイトエンドポイント subdomain.example.s3-website-us-east-1.amazonaws.com を示しています。

Figure 1: S3 bucket configured as a static website

図 1: 静的ウェブサイトとして設定された S3 バケット

図 2 に示すように、Amazon Route 53 を使用して、Amazon のドメイン名に解決される CNAME レコードを作成します。これにより、ユーザーはわかりやすい名前でアクセスでき、URL に含まれる長い S3 ウェブサイト名を覚える必要がなくなります。

Figure 2: DNS Resolver configured with CNAME record pointing to origin bucket

図 2: オリジンバケットを指す CNAME レコードが設定された DNS リゾルバー

その後、お客様の AWS 管理者は S3 バケットからのコンテンツ配信を停止することにし、図 3 に示すようにバケットを削除します。

Figure 3: Resource deleted without removing the CNAME record

図 3: CNAME レコードを削除せずにリソースを削除

S3 バケットは削除されたものの CNAME レコードが残っているため、DNS レコードはダングリング状態になります。脅威アクターはこの状況を突き止め、図 4 に示すように、自身が管理する AWS アカウントで同じグローバル名 subdomain.example を持つ新しい S3 バケットを作成します。これにより脅威アクターは、この新しいバケットからコンテンツを配信できるようになり、その中には悪意のあるコンテンツが含まれる可能性もあります。ユーザーはこの切り替えに気付かず、見覚えのある URL から配信されているように見えるため、コンテンツを信頼して subdomain.example.com へのアクセスを続けます。

図 4: サブドメイン乗っ取りの発生

サブドメイン乗っ取りによって想定される影響

次のような影響が考えられます。

評判へのリスク: DNS レコードが指している脅威アクターのサイトから配信されるコンテンツはお客様が管理できないため、組織の評判が損なわれるリスクがあります。

フィッシングキャンペーンにさらされる可能性: 組織内のユーザーがサブドメインをブラウザにブックマークしている場合、リソースが既に利用できないことを知らないまま、マルウェアをホストしているサイトや、ユーザーの認証情報を詐取するフィッシングに使用されているサイトに、何の疑いもなくアクセスしてしまう可能性があります。

ブロック: サブドメインが悪意のあるアクティビティを理由にセキュリティベンダーからフラグ付けされると、業務に影響が及ぶ可能性があります。

経済的損失: サブドメイン乗っ取りのインシデントに対応する間、サービス提供が中断される可能性があり、経済的な影響が生じる場合があります。

プロアクティブな検出

AWS Config によるプロアクティブな検出

プロアクティブに検出するには、AWS Config を使用して Route 53 の CNAME レコードを継続的に監視し、ターゲットのリソースがアカウント内に存在することを確認します。

前提条件: この方法では、監視対象のリソースタイプ (S3 バケット、CloudFront ディストリビューション、Elastic Beanstalk 環境) に対して AWS Config レコーダーを有効にしておく必要があります。AWS Config で記録されていないリソースタイプは、インベントリチェックに表示されません。詳細については、「コンソールを使用した AWS Config のセットアップ」を参照してください。

DNS 解決チェックではなく AWS Config インベントリを使用する理由

一般的な方法は、CNAME が有効なエンドポイントに解決されるかどうかを確認することです。しかし、この方法には重大な欠陥があります。攻撃者が既にリソースを取得している場合、DNS 解決は成功します。ただし、その解決先はお客様のリソースではなく攻撃者のリソースです。応答しているリソースがお客様の所有物ではないことに気付く手がかりはありません。

AWS Config に記録された設定項目をクエリすれば、その DNS 名で単に何かが応答するかどうかではなく、リソースがお客様のアカウントのインベントリに存在するかどうかを確認できます。この方法なら、乗っ取りが既に発生した後でも、ダングリング CNAME を正しく特定できます。

実装方法:

アカウントレベルと組織レベルのスコープ

リファレンス実装では、単一のアカウント内の AWS Config インベントリをクエリします。そのため、アカウント A の CNAME レコードが、同じ AWS 組織内のアカウント B に正当に存在するリソースを指している場合でも、ルールはそのレコードを NON_COMPLIANT としてフラグ付けします。

アカウント間でリソースを共有している組織では、AWS Config アグリゲータを使用するようにソリューションを変更できます。AWS Config アグリゲータは、組織内のすべてのアカウントを対象にリソースインベントリをクエリします。これは、IAM Access Analyzer がアカウントレベルと組織レベルの両方のスコープをサポートしているのと同様の考え方です。この方法を使用するには、組織レベルの AWS Config アグリゲータを事前に設定しておく必要があります。また、Lambda 関数の IAM ロールには config:SelectAggregateResourceConfig 権限が必要です。

AWS は、まずはシンプルなアカウントレベルのスコープから始め、環境にクロスアカウントのリソース共有が含まれる場合は組織レベルに拡張することをお勧めします。

基本的な考え方は、Route 53 ホストゾーンの CNAME レコードをクエリするカスタム AWS Config ルールを作成することです。このルールは、各 CNAME のターゲットを解析し、S3、CloudFront、Elastic Beanstalk などの既知の AWS リソースパターンを指しているかどうかを判断します。パターンに一致した CNAME ごとに、ルールはターゲットを AWS Config インベントリと照合し、リソースが実際にアカウント内に存在するかどうかを確認します。リソースが見つからない場合、ルールは CNAME レコードを NON_COMPLIANT としてマークし、レビューが必要なものとして提示します。

AWS Config ルールでは、次の既知の AWS リソースパターンを対象とします。

S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com
訳注: S3 ウェブサイトエンドポイントは、リージョンによって s3-website.<region>.amazonaws.com (ドット形式) になる場合もあるため、検出パターンではこの形式も考慮してください。参照: Amazon S3 ユーザーガイドの「ウェブサイトエンドポイント」
CloudFront: *.cloudfront.net
Elastic Beanstalk: *.elasticbeanstalk.com

注: 外部のサードパーティサービスを指す CNAME レコードは、参照先のリソースが AWS Config インベントリに含まれないため、この検出メカニズムの対象外です。

AWS Config ルールによる NON_COMPLIANT の検出結果は、AWS Security Hub に送信して一元的に可視化したり、SNS 通知をトリガーしてセキュリティチームにアラートを送ったりできます。

Figure 5: Dangling DNS Detection Solution

図 5: ダングリング DNS 検出ソリューション

リファレンス実装:

AWS は、この検出方法の完全な実装を、オープンソースのソリューションとして公開しています。このソリューションでデプロイされる Lambda 関数は、すべての Route 53 ホストゾーンから CNAME レコードを検出し、パターンマッチングを使用して S3、CloudFront、Elastic Beanstalk を指すターゲットを特定します。続いて、AWS Config インベントリをクエリし、各ターゲットリソースがアカウント内に引き続き存在するかどうかを確認します。ダングリングレコードを検出すると、Security Hub で重要度 HIGH の検出結果を生成します。オプションで SNS 通知を送信し、セキュリティチームにアラートを送ることもできます。また、継続的なコンプライアンス追跡のための CloudWatch メトリクスダッシュボードも含まれています。

デプロイ:

# Clone the repository
git clone https://github.com/aws-samples/sample-dangling-dns-detection
cd sample-dangling-dns-detection

# Build the Lambda deployment package
./scripts/package.sh

# Upload to S3
aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/

# Deploy the CloudFormation stack
aws cloudformation deploy \
  --template-file infrastructure/template.yaml \
  --stack-name dangling-dns-detection \
  --parameter-overrides \
      LambdaCodeS3Bucket=YOUR_BUCKET \
      EvaluationFrequency=TwentyFour_Hours \
  --capabilities CAPABILITY_NAMED_IAM

このスタックは、指定したスケジュール (デフォルト: 24 時間ごと) で実行される AWS Config カスタムルールを作成します。このルールは、すべての CNAME レコードを評価し、コンプライアンスステータスを報告します。

影響の緩和

サブドメイン乗っ取りを緩和するには、予防のための手順と、発生時の対応能力の両方が必要です。

予防: 標準作業手順

最も効果的な緩和策は、リソースのプロビジョニング解除に関する標準作業手順を定め、基盤となるリソースより先に DNS レコードを確実に削除することです。

DNS ゾーン内で、プロビジョニング解除を予定しているリソースの完全修飾ドメイン名 (FQDN) を指す CNAME レコードを削除します。
DNS の TTL が期限切れになるまで待ってから、リソースを削除します。DNS リゾルバーは TTL の期間中レコードをキャッシュします (例えば、TTL が 3,600 の場合、リゾルバーは最大 1 時間、古いレコードを返す可能性があります)。TTL が期限切れになる前にリソースを削除すると、キャッシュされた CNAME エントリによってトラフィックがまだそのリソースに向けられている間に、脅威アクターがリソース名を取得できてしまう可能性があります。
不要になったリソースをプロビジョニング解除します。
削除した CNAME レコードについて DNS チェックを実行し、その名前がリソースに解決されなくなったことを確認します。

重要な原則: 必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してください。この順序を守ることで、ダングリングレコードが悪用される隙をなくすことができます。

予防: S3 のアカウントリージョナル名前空間

前述のとおり、AWS は 2026 年 3 月に Amazon S3 汎用バケットのアカウントリージョナル名前空間を導入しました。これは S3 固有の乗っ取り経路の緩和に向けた意義のある一歩ですが、運用上の重要な制限事項に注意する必要があります。

既存のバケットには適用されません。グローバル名前空間で既に作成されたバケットは、アカウントリージョナル名前空間に移行できません。これらのバケット名はグローバルに一意のままであり、バケットを削除すると誰でもその名前を取得できます。

グローバル名前空間が引き続きデフォルトです。コンソール、CLI、SDK のいずれで新しいバケットを作成する場合も、グローバル名前空間がデフォルトで選択されたままです。新しいオプションを知らないお客様は、今後もグローバルスコープのバケットを作成し続けることになります。

既存の IaC テンプレートは更新が必要です。アカウントリージョナル名前空間の使用を明示的に選択していない既存の Infrastructure as Code (IaC) テンプレート (CloudFormation、CDK、Terraform) では、引き続きグローバル名前空間でバケットがプロビジョニングされます。CloudFormation の場合は、BucketNamespace プロパティを account-regional に設定します。その他の IaC ツールについては、それぞれのドキュメントで同等の設定を確認してください。組織は、テンプレートを監査し、オプトインするよう更新する必要があります。

こうした理由から、この記事で説明したダングリング DNS の検出方法は引き続き不可欠です。既存の S3 インフラストラクチャを持つ組織や、同等の名前空間のスコープ設定が用意されていない CloudFront および Elastic Beanstalk のリソースについては、特に重要です。

対応: 通知と修復

ダングリング DNS レコードが検出されると、「プロアクティブな検出」セクションで説明したリファレンスソリューションは、AWS Security Hub で重要度 HIGH の検出結果を自動的に作成し、AWS Config で CNAME レコードを NON_COMPLIANT として報告します。デプロイ時に SNS トピック ARN を指定すると、E メール、Slack、その他のチャネルを通じて通知を送信し、セキュリティチームや運用チームにアラートを送ることもできます。本番環境では、ヒューマンインザループのワークフローを検討してください。チームメンバーが通知を確認し、DNS レコードの削除を実行前に承認する仕組みです。これにより、一時的な問題の発生時に正当なレコードを誤って削除することを防げます。

リファレンスソリューションには、コンプライアンスステータスと評価メトリクスを経時的に追跡するための CloudWatch ダッシュボードも含まれています。これにより、チームはホストゾーン全体の DNS の健全性を継続的に可視化できます。

注: 完全に自動化された修復 (DNS レコードの自動削除) にはリスクが伴い、誤検知によって正当なサービスが中断される可能性があります。AWS は、まずは検出と通知から始め、検出精度と運用の成熟度に応じて自動化を検討することをお勧めします。

まとめ

サブドメイン乗っ取りは、防止可能な設定ミスでありながら、組織に重大な影響を及ぼす可能性があります。多層防御のアプローチを取ることで、最も効果的に保護できます。

予防: 基盤となるリソースのプロビジョニングを解除する前に DNS レコードを削除する標準作業手順を導入します。

検出: AWS Config カスタムルールを使用して、アカウント内に存在しなくなったリソースを指す CNAME レコードをプロアクティブに特定します。

対応: SNS または Security Hub を通じて通知を設定し、ダングリングレコードが検出されたときにチームが迅速に対応できるようにします。

監視: CloudWatch ダッシュボードを使用して継続的な可視性を確保し、DNS の健全性とコンプライアンスステータスを追跡します。

重要なのは、DNS を適切に管理すること、つまり CNAME レコードが存在しないリソースを指している状況を把握することが、第一の防御策になるという点です。AWS Config による自動検出は、運用手順が機能しなかった場合のセーフティネットになります。さらに、問題を検出したときにすぐ実行できる対応用のプレイブックを用意しておけば、影響を抑え、平均復旧時間を短縮できます。

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ