サブドメイン乗っ取りとは？AWSで起きる原因と対策【2026年版】

「昔 S3 で作ったキャンペーンサイト、バケットは消したけれど DNS の設定はそのまま」——そんな状態が、サブドメイン乗っ取りの入り口になります。

結論から言うと、対策の基本は「DNS レコードを先に消し、TTL が切れるのを待ってからリソースを消す」という順番を守ることです。すでに消してしまったリソースがあるなら、DNS に残った CNAME レコードを今すぐ点検するのが先決です。

今このテーマを取り上げるのには理由があります。AWS は2026年10月20日、公式ブログ（日本語）で「脅威の手口を解説：サブドメイン乗っ取りの仕組みと対策」を公開しました。AWS のインシデント対応チーム（AWS CIRT）は、存在しないリソースを指す CNAME レコードを、脅威アクターが積極的にスキャンしていることを確認していると説明しています。

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

この記事では、AWS の公式ブログと Microsoft・GitHub の公式ドキュメントをもとに、仕組み・対象になるリソース・防ぎ方・点検の方法を整理します。個人や小規模なサイトでも、DNS の片付け方を見直すだけで防げるリスクという位置づけです。

サブドメイン乗っ取りとは？一言でまとめると

サブドメイン乗っ取りとは、削除済みのリソースを指したまま残っている DNS レコードを悪用され、自分のサブドメインで他人のコンテンツが表示されてしまうことです。英語では subdomain takeover と呼ばれます。

AWS のブログは、この手口はAWS サービスの脆弱性を利用するものではないと明記しています。原因は利用者側の設定の片付け漏れです。そのため、AWS の責任共有モデルでは、利用者が自分で防ぐ範囲にあたります。

なお、セキュリティの攻撃手法をまとめた MITRE ATT&CK では、T1584.001（Compromise Infrastructure: Domains）に分類されていると AWS のブログは紹介しています。

なぜ起きる？S3の例で見る仕組み

AWS のブログでは、S3 の静的ウェブサイトを例に、乗っ取りまでの流れを説明しています。

① サブドメインを S3 に向ける

subdomain.example.com を、S3 のウェブサイトエンドポイント（subdomain.example.s3-website-us-east-1.amazonaws.com）に向ける CNAME レコードを作ります。S3 で独自ドメインのサイトを公開する場合、バケット名はドメイン名と厳密に一致させる必要があります（S3 の公式ドキュメント）。

② バケットだけを削除する

サイトが不要になり、S3 バケットを削除します。このときCNAME レコードを消し忘れると、アクセスした人には「バケットが存在しない」というエラーが表示されます。

③ 第三者が同じ名前のバケットを作る

S3 のバケット名は（従来のグローバル名前空間では）全世界で一意で、削除すると誰でも同じ名前を取得できます。脅威アクターが自分の AWS アカウントで subdomain.example というバケットを作ると、subdomain.example.com に来た人に、攻撃者のコンテンツが表示されるようになります。

利用者から見ると、URL は見覚えのある正規のドメインのままです。だからこそ、気づかれにくく、信用されやすいのがこの手口の厄介な点です。

AWSで対象になるリソース：S3・CloudFront・Elastic Beanstalk

AWS のブログによると、乗っ取りが起こり得るのは、誰でも名前を取得できる「グローバルに共有される名前空間」のリソースを CNAME で指している場合です。

一方で、Amazon VPC・Amazon EC2 インスタンス・プライベートホストゾーンなどは、グローバルに取得できる DNS の名前空間を公開していないため、この手口の対象にはならないとされています。

また、S3 でも2026年3月から使えるアカウントリージョナル名前空間で作ったバケットは、名前の範囲が自分のアカウントに限られるため対象外です（詳しくは後述）。

乗っ取られると何が起きる？

AWS のブログは、想定される影響として次の4つを挙げています。

• 信用の低下：自分のドメインで、自分が管理できないコンテンツが配信される
• フィッシング：ブックマークから訪れた利用者が、マルウェアの配布や認証情報を盗むサイトに誘導される
• ブロック：サブドメインがセキュリティベンダーに「悪意のあるサイト」と判定され、業務に影響が出る
• 経済的な損失：インシデント対応の間、サービスが止まることがある

Microsoft Learn の解説は、さらに具体的なリスクに触れています。たとえば、攻撃者は乗っ取ったサブドメインで有効な SSL 証明書を取得できるため、「HTTPS だから安全」とは言えません。親ドメイン全体（*.example.com）に Cookie を発行しているサイトでは、乗っ取られたサブドメインから Cookie を集められるおそれもあります。

MX レコード（メールの受け取り先）が残っている場合は、正規のサブドメイン宛てのメールを受け取られるリスクもあると Microsoft は説明しています。Web サイトだけでなく、メール関連のレコードも点検の対象です。

予防の基本：DNSを先に消し、TTLを待ってから削除

AWS のブログが「最も効果的な緩和策」として挙げているのが、リソースを削除するときの標準の手順を決めておくことです。順番は次のとおりです。

① CNAME レコードを削除する

DNS ゾーンから、削除する予定のリソースを指している CNAME レコードを消します。Route 53 なら、該当するホストゾーンのレコード一覧から削除します。

② TTL が切れるまで待つ

DNS のリゾルバー（問い合わせを中継するサーバー）は、TTL の間はレコードをキャッシュしています。AWS のブログの例では、TTL が 3,600（秒）なら最大1時間、古いレコードが返される可能性があります。TTL が切れる前にリソースを消すと、その隙に名前を取られるおそれがあります。

③ リソースを削除する

TTL が切れたことを確認してから、S3 バケットや CloudFront ディストリビューションなどを削除します。

④ 名前が解決されないことを確認する

削除した CNAME について DNS の問い合わせを行い、もうどのリソースにも解決されないことを確かめます。

AWS はこれを「重要な原則」として、必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してくださいとまとめています。

Route 53 でドメインやホストゾーンを管理している方は、レコードの扱い方とあわせて料金や注意点もこちらで確認できます。

あわせて読みたい

Route 53でドメインを取得するには？料金・手順と注意点【2026年版】

S3はアカウントリージョナル名前空間で守れる

S3 については、AWS が2026年3月12日に「汎用バケットのアカウントリージョナル名前空間」を提供開始しています。

※ 2026年10月20日時点の AWS の公式発表による

ただし、AWS のブログは運用上の制限が3つあると注意しています。

• 既存のバケットは移行できない：グローバル名前空間で作ったバケットは、削除すれば今までどおり誰でも名前を取得できる
• デフォルトはグローバル名前空間のまま：コンソール・CLI・SDK で新しく作るときも、何も指定しなければ従来の方式になる
• IaC のテンプレートは更新が必要：CloudFormation なら BucketNamespace プロパティを account-regional にする

チームで AWS を使っているなら、SCP や IAM ポリシーで、アカウントリージョナル名前空間でしかバケットを作れないように強制することもできます。

なお、CloudFront と Elastic Beanstalk には同等の仕組みが用意されていないため、削除の順番と、次に紹介する検出が引き続き欠かせないとされています。

残ったCNAMEを見つけるには：AWS Configで自動検出

すでに消したリソースを指す CNAME が残っていないかは、AWS Config（リソースの構成を記録するサービス）で自動的に確認できます。

DNS が「つながる」だけでは安全と言えない

よくある確認方法は、CNAME が名前解決できるかを見ることです。しかし AWS のブログは、攻撃者がすでにリソースを取得している場合も名前解決は成功するため、この方法には重大な欠陥があると指摘しています。

そこで AWS が勧めているのが、指し先のリソースが「自分のアカウントに存在するか」を AWS Config の記録で確かめる方法です。これなら、乗っ取りがすでに起きていても見つけられます。

AWS が公開している検出ツール

AWS は、この方法を実装したサンプル「sample-dangling-dns-detection」を GitHub で公開しています。

• 何をする：Route 53 のすべてのホストゾーンの CNAME を調べ、S3・CloudFront・Elastic Beanstalk を指すものが自分のアカウントに存在するか確認する
• 検出したら：Security Hub に重要度 HIGH の検出結果を作り、SNS でメールや Slack に通知できる
• 頻度：デフォルトは24時間ごと
• 前提：対象のリソースタイプについて AWS Config の記録を有効にしておく

サンプルの README は、本番用のソフトウェアではなく参考実装であり、まず検証用のアカウントで試すよう勧めています。Lambda や AWS Config の評価などの料金がかかる点にも注意してください。また、外部のサービスを指す CNAME は確認の対象外です。

自動削除はしない

AWS のブログは、DNS レコードを自動で削除する仕組みは誤検知で正当なサービスを止めるリスクがあるとして、まずは検出と通知から始め、本番環境では人が確認して承認してから削除する流れを勧めています。

無料枠やクレジットで試したリソースを消したあとこそ、CNAME の消し忘れが起きやすいタイミングです。クラウドの無料枠の使い方はクラウド無料枠の比較記事で整理しています。

AWS以外でも起きる：AzureとGitHub Pagesの対策

サブドメイン乗っ取りは AWS に限った話ではありません。Microsoft と GitHub も、公式ドキュメントで対策を案内しています。

① Azure の場合

Microsoft Learn によると、App Service（*.azurewebsites.net）、Blob Storage、Front Door、Traffic Manager、パブリック IP の DNS 名などを CNAME で指している場合が対象です。主な対策は次のとおりです。

• Microsoft Defender for App Service：App Service を削除したのにカスタムドメインの DNS が残っていると、アラートで知らせる
• Azure DNS のエイリアスレコード：Front Door・Traffic Manager・CDN・パブリック IP を指す場合、リソースを消すとレコードも空になる
• カスタムドメインの検証（asuid の TXT レコード）：TXT レコードがあれば、他のサブスクリプションがそのドメインを検証できない
• Get-DanglingDnsRecords：未解決の DNS を洗い出す PowerShell ツール

② GitHub Pages の場合

GitHub Pages で独自ドメインを使っているなら、カスタムドメインの検証を行うのが基本です。GitHub Docs は、検証で乗っ取り攻撃を回避できると説明しています。

• 方法：_github-pages-challenge-ユーザー名 という名前の TXT レコードを DNS に追加し、設定画面で検証する。検証後も TXT レコードは残しておく
• 起こりうる場面：リポジトリの削除、課金プランのダウングレード、カスタムドメインのリンク解除、Pages の無効化
• ワイルドカード DNS（*.example.com）は使わないことを強く勧めている

小規模サイトでもできる点検チェックリスト

大規模な組織向けのツールを入れなくても、個人や小規模なサイトでできることはあります。AWS・Microsoft・GitHub の公式の推奨を、手元で確認しやすい形にまとめます。

特に、DNS を Route 53 以外（ドメインを取ったサービスの DNS など）で管理している場合は、AWS Config の検出ツールの対象外になります。DNS の管理画面を直接見て確認するのが確実です。

CloudFront の先にアプリを置く例は、次の記事で紹介しています。独自ドメインで公開するときは、閉じるときの手順もあわせて決めておくと安心です。

あわせて読みたい

Lambda Web Functionsとは？東京でも提供開始【2026年10月】

VPS でサイトを運営している場合は、サーバー側の基本的なセキュリティ設定もあわせて見直しておきましょう。

あわせて読みたい

さくらのVPSのセキュリティ初期設定：最初にやる5つの対策【2026年版】

よくある質問

Q. HTTPS（SSL証明書）を使っていれば防げる？

A. 防げません。Microsoft Learn は、攻撃者は乗っ取ったサブドメインで有効な SSL 証明書を取得できると説明しています。証明書があることは、そのサイトが本来の持ち主のものである保証にはなりません。

Q. EC2 や VPS の IP アドレスを A レコードで指している場合は？

A. AWS のブログは、Amazon EC2 インスタンスや Amazon VPC はグローバルに取得できる DNS の名前空間を公開していないため、この手口の対象にはならないとしています。ただし、使わなくなったサーバーを指すレコードを残しておく理由はないため、サーバーを解約するときは DNS も一緒に片付けておきましょう。

Q. 乗っ取られているのを見つけたらどうする？

A. まず該当する DNS レコードを削除します。Microsoft Learn は、そのうえでアプリのコードに古いサブドメインへの参照が残っていないか見直し、被害がなかったか調査し、なぜ DNS が消されなかったのかを確認するよう勧めています。

Q. 新しく作る S3 バケットは何をすればいい？

A. 2026年3月から使えるアカウントリージョナル名前空間でバケットを作るのが有効です。ただし、何も指定しなければ従来のグローバル名前空間になるため、作成時に明示的に選ぶ必要があります。

まとめ

サブドメイン乗っ取りのポイントをまとめます。

• 原因：削除済みのリソースを指したまま残った DNS レコード（ダングリング DNS）
• AWS で対象になるもの：S3（グローバル名前空間）・CloudFront・Elastic Beanstalk。EC2・VPC は対象外
• 予防の順番：CNAME 削除 → TTL 待ち → リソース削除 → 解決されないことを確認
• S3 の新機能：2026年3月12日からアカウントリージョナル名前空間（追加料金なし。既存バケットは移行不可）
• 検出：AWS Config で「指し先が自分のアカウントにあるか」を確認。名前解決できるかだけでは不十分
• AWS 以外：Azure はカスタムドメインの検証・Defender、GitHub Pages はドメインの検証が基本

まずは、自分のドメインの DNS 管理画面を開き、もう使っていないリソースを指す CNAME が残っていないかを確認するところから始めてみてください。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。