AWSは2026年10月20日、サブドメイン乗っ取り（subdomain takeover）の仕組みと対策を解説する日本語ブログを公開した。6月16日に公開された英語版の記事を翻訳したものだ。AWS Customer Incident Response Team（AWS CIRT）は、攻撃者がこの手口を狙ってDNSレコードを積極的にスキャンしていることを確認しているという。
サブドメイン乗っ取りは、既に存在しないリソースを指したまま残ったDNSレコードが悪用される手口である。AWSは、AWSサービスの脆弱性を突くものではないと明記している。記事では、AWS Configによる検出方法とオープンソースの実装、DNSレコードを先に削除する運用手順を紹介している。
削除したリソースを指す「ダングリングDNS」が入口に
CNAMEレコードは、あるドメイン名を別のドメイン名に向けるDNSの設定である。たとえば、自社のサブドメインをS3のウェブサイトエンドポイントに向ければ、長いAWSのホスト名を覚えずに済む。ただし、リソースを削除した後もレコードが残ると、存在しない先を指す「ダングリング」状態になる。
問題になるのは、名前を誰でも取得できる共有の名前空間を使うリソースだ。対象は、Amazon S3（グローバル名前空間）、Amazon CloudFront、AWS Elastic Beanstalkの3つだ。一方、Amazon VPCやAmazon EC2インスタンス、プライベートホストゾーンは対象外とされた。MITRE ATT&CKでは、この手法をT1584.001に分類している。
記事のシナリオでは、S3バケットを削除した際にDNSレコードの削除を忘れたケースを取り上げている。攻撃者は同じ名前のバケットを自分のアカウントで作り、そこから任意のコンテンツを配信できる。利用者は見慣れたURLのままなので、切り替わったことに気付かない。
想定される影響はフィッシングから業務停止まで
AWSは、想定される影響を4つ挙げている。1つ目は、管理できないコンテンツが自社ドメインから配信されることによる評判への打撃だ。2つ目はフィッシングで、ブックマークしていたサブドメインから、マルウェアや認証情報を盗むサイトに誘導されるおそれがある。
3つ目は、悪意のある活動を理由にセキュリティベンダーからサブドメインにフラグを付けられ、業務に支障が出ることだ。4つ目は経済的な損失で、インシデント対応の間にサービスが中断する可能性がある。いずれも、技術的な侵害がなくても起こり得る点に注意が必要だ。
DNSの解決確認ではなくAWS Configの在庫と照合
検出の方法として、AWSはAWS ConfigでRoute 53のCNAMEレコードを継続的に監視する方法を示している。CNAMEが指すリソースが、自社アカウントのインベントリに実在するかを照合する仕組みだ。前提として、監視対象のリソースタイプでAWS Configのレコーダーを有効にしておく必要がある。
よく使われる「CNAMEが名前解決できるか」の確認には、重大な欠陥があるという。攻撃者が既に名前を取得していれば、名前解決は成功してしまうからだ。インベントリと照合すれば、乗っ取りが起きた後でもダングリングレコードを見つけられる。外部のサードパーティサービスを指すCNAMEは、この方法の対象外とされている。
AWSは、この検出方法の実装をオープンソースとしてGitHubで公開した。Lambda関数がすべてのRoute 53ホストゾーンからCNAMEを集め、S3、CloudFront、Elastic Beanstalkを指すものを照合する。問題があれば、AWS Security Hubで重要度HIGHの検出結果を作り、SNSでも通知できる。既定では24時間ごとに評価を実行する。
最大の対策は「DNSを先に消す」削除手順
AWSが最も効果的な緩和策として挙げるのは、リソースを廃止するときの標準手順を定めることだ。まずCNAMEレコードを削除し、DNSのTTLが切れるのを待ってから、リソースを削除する。TTLの間はリゾルバーが古いレコードを返すため、先にリソースを消すと、攻撃者に名前を取られる隙が生まれる。
S3については、2026年3月に「アカウントリージョナル名前空間」が導入された。この方式で作ったバケットは自社アカウントに限定されるため、乗っ取りの対象にならない。ただし、既存のバケットは移行できず、新規作成時もグローバル名前空間が既定のままだ。CloudFormationなどのIaCテンプレートも、明示的に設定を変えなければ従来どおりの方式でバケットを作る。
検出後の対応では、人が確認してから削除する手順を検討するよう勧めている。DNSレコードの自動削除は、誤検知で正当なサービスを止めるリスクがあるためだ。AWSは、まず検出と通知から始め、精度と運用の成熟度に応じて自動化を進めることを推奨している。
企業への示唆
サブドメイン乗っ取りは、システム廃止の手順の抜けから起きる。まずは、キャンペーンサイトや検証環境など、過去に作って廃止したサブドメインのDNSレコードを棚卸ししたい。あわせて、リソース削除の手順書に「DNSレコードの削除とTTL経過の確認」が含まれているかを確かめるとよい。
DNSの管理部門とクラウドの運用部門が分かれている企業では、片方だけが削除して終わる状況が起きやすい。S3のバケットを作るIaCテンプレートで、アカウントリージョナル名前空間を使う設定にしているかも見直したい。外部のSaaSを指すCNAMEはAWS Configでは確認できないため、別の方法で点検する必要がある。
ITトレンドでクラウドセキュリティについてチェック！[クラウドセキュリティのおすすめ製品を徹底比較！リスクや種類も解説]
AWSのセキュリティ関連ニュースはこちらもチェック！[AWSが「Well-Architected Agent」をパブリックプレビュー——65以上のサービスを横断して環境を分析、コスト・セキュリティ・性能・レジリエンスの改善策をIaCコードまで提示]
まとめ
AWSは、削除済みのリソースを指したまま残ったDNSレコードを悪用する、サブドメイン乗っ取りの対策を解説した。AWS Configのインベントリと照合する検出方法と、そのオープンソース実装をあわせて公開している。
最も効果的な対策は、DNSレコードを先に削除し、TTLが切れてからリソースを消す運用である。AWSの利用企業は、廃止済みのサブドメインと削除手順を一度点検しておきたい。
