Infoblox Threat Intelは、廃止済みのクラウドリソースを指したまま残されたDNS CNAMEレコードを悪用し、政府機関や企業などの正規サブドメインを乗っ取る脅威アクター「Hazy Hawk」の活動を分析しています。
Hazy Hawkは少なくとも2023年12月から活動しており、Infobloxは2025年2月、米疾病予防管理センター(CDC)のサブドメインが乗っ取られた事象を調査する過程で同アクターを特定しました。乗っ取った正規サブドメインには大量のURLが作成され、Traffic Distribution System(TDS)を経由して、テクニカルサポート詐欺、偽ウイルス対策ソフト、マルウェア配布、フィッシング、偽ストリーミングサイトなどへ利用者を誘導していました。
CyberPressはこれを「DNS vulnerabilities」の悪用と表現していますが、Infobloxの一次調査が示しているのはDNSプロトコルやAWS、Azureなどのクラウドサービス自体の脆弱性ではありません。クラウドリソースを廃止した後もCNAMEレコードを削除せず残した「ダングリングDNS」と、クラウド資産のライフサイクル管理不備を突いたサブドメイン乗っ取りです。
AWSも2026年6月、同種のサブドメイン乗っ取りについて、AWSサービスの脆弱性を悪用するものではなく、存在しなくなったリソースを指すDNSレコードを攻撃者が探索していると注意喚起しています。
Hazy Hawkのサマリー
- 【確認済み】Hazy HawkはInfoblox Threat Intelが追跡するDNSに精通した脅威アクターです。
- 【確認済み】活動は少なくとも2023年12月から確認されています。
- 【確認済み】Infobloxは2025年2月、CDCのサブドメイン乗っ取りを調査する中でHazy Hawkを特定しました。
- 【確認済み】主な手法は、廃止済みクラウドリソースを指したまま残った「ダングリングCNAME」の悪用です。
- 【重要】DNSプロトコルやAWS、Azureなどのクラウドサービス自体の脆弱性を悪用する攻撃ではありません。
- 【確認済み】Infobloxは、AWSのS3/Elastic Beanstalk、Azureの複数サービス、Akamai、Cloudflare CDN、GitHub、Netlifyなど、複数のクラウド/CDNサービスに関連する放棄済み資産の悪用を確認しています。
- 【確認済み】InfobloxはCDC、Deloitte、PwC、EY、UC Berkeleyなど多数の政府機関、大学、企業の正規ドメインに関連する乗っ取りを確認しています。
- 【確認済み】乗っ取ったサブドメインは、TDSを介した詐欺、偽アプリ、マルウェア配布、フィッシングなどへの誘導に使われました。
- 【確認済み】正規の親ドメインやクラウドアカウントそのものが侵害されたことを意味する事案ではありません。
- 【確認済み】Infobloxは、クラウドリソース廃止時に対応するCNAMEを削除する運用と、DNS・クラウド資産の継続的な棚卸しを推奨しています。
- 【確認済み】AWS CIRTは2026年6月、攻撃者が公開CNAMEからサブドメイン乗っ取り可能な設定を能動的に探索していると公表しました。
- 【確認済み】Cloudflareは2026年、自社の検査対象で1週間に100万件超のダングリングDNSを検出したと公表しており、DNS資産の放置は現在も広く残る課題です。
- 【未確認】Hazy Hawkの実在人物、所在地、国家との関係は特定されていません。
- 【Infobloxの評価】ドメイン乗っ取り部分がサービスとして別の攻撃者へ提供されている可能性もあるとしていますが、確定した事実ではありません。
| 項目 | 内容 |
|---|---|
| 脅威アクター | Hazy Hawk |
| 調査主体 | Infoblox Threat Intel |
| Infobloxによる発見 | 2025年2月 |
| 一次調査公表 | 2025年5月20日 |
| 活動開始 | 少なくとも2023年12月 |
| 主な手法 | ダングリングCNAMEを悪用したサブドメイン乗っ取り |
| 根本要因 | DNSレコードと廃止済みクラウド資産のライフサイクル管理不備 |
| DNSプロトコルの脆弱性 | 確認されていません |
| クラウドサービスの脆弱性 | 確認されていません |
| Infobloxが関連を確認したサービス | Akamai、Amazon S3/Elastic Beanstalk、Azure、Bunny CDN、Cloudflare CDN、GitHub、Netlifyなど |
| 主な悪用目的 | 詐欺、偽アプリ、マルウェア配布、フィッシング、悪性広告 |
| 中継 | Traffic Distribution System(TDS)、URL短縮サービスなど |
| 主な対策 | クラウド資産廃止時のDNS削除、資産台帳、継続監視、Protective DNS |
発端はCDCのサブドメインに突然現れた大量の不審URL
InfobloxがHazy Hawkを把握したきっかけは、2025年2月に確認されたCDCのサブドメインでした。
CDC配下の不自然なサブドメインに、ポルノ動画やスポーツ配信などをうたう多数のURLが検索結果へ表示されていました。
InfobloxがDNSを調査したところ、このサブドメインは以前利用されていたAzureのクラウドリソースをCNAMEで参照していましたが、参照先のリソースはすでに廃止されていました。
DNS側のCNAMEだけが残ったことで「正規組織のサブドメイン」と「存在しないクラウド資産」の対応関係が残り、第三者が参照先を再取得できる状態になっていたとInfobloxは分析しています。
Hazy Hawkはこの状態を利用してサブドメインのコンテンツを制御し、正規のcdc.gov配下に見えるURLを悪用しました。
ここで侵害されたのはCDCの親ドメイン全体やWebサーバーではありません。放置されたDNS設定を通じて、特定のサブドメインに対応するクラウド資産を第三者が制御できるようになった事案です。
「ダングリングCNAME」がサブドメイン乗っ取りを生む
CNAMEは、あるドメイン名を別のドメイン名へ対応付けるDNSレコードです。
クラウド上のWebアプリケーション、ストレージ、CDNなどへ独自サブドメインを割り当てる際に広く使われています。
問題になるのは、クラウド側のリソースを先に削除し、DNSのCNAMEを残した場合です。
DNS上には参照先が設定されたままですが、その実体はすでに存在しません。この状態が「ダングリングCNAME」「ダングリングDNS」と呼ばれます。
クラウドサービスによっては、削除されたリソース名を別の利用者が取得できる場合があります。その場合、DNSを変更していないにもかかわらず、企業の正規サブドメインへのアクセスが第三者のクラウドリソースへ到達する状態になり得ます。
MicrosoftもAzureの公式セキュリティ文書で、廃止済みAzureリソースを指すDNSレコードが残っていると、サブドメイン乗っ取りにつながる可能性があると注意喚起しています。
「DNSの脆弱性」や「AWSの脆弱性」とは異なる
CyberPressの記事タイトルでは「DNS Vulnerabilities」と表現されていますが、今回のHazy Hawkをソフトウェア脆弱性やDNSプロトコルの欠陥として扱うのは正確ではありません。
Infobloxは「DNS misconfigurations」として説明しており、原因は利用されなくなったクラウド資産とDNSレコードの管理が分離したまま放置されることです。
AWSも2026年6月に公開したサブドメイン乗っ取りの解説で、この攻撃はAWSサービスの脆弱性を悪用するものではないと明記しています。
AWS Customer Incident Response Team(CIRT)は、攻撃者がインターネット上の公開CNAMEを探索し、すでに存在しなくなったクラウドリソースを参照するレコードを探しているとしています。
クラウドの共有責任モデルでは、クラウド事業者側のセキュリティだけでなく、利用企業側が作成したDNSとクラウド資産の整合性も管理する必要があります。
AWS、Azure、GitHub、Cloudflareなど複数サービスに関連する資産を悪用
Infobloxの調査では、Hazy Hawkが悪用した放棄済み資産に関連するサービスとして、Akamai、Amazon S3、Amazon Elastic Beanstalk、Microsoft Azureの複数サービス、Bunny CDN、Cloudflare CDN、GitHub、Netlifyなどが挙げられています。
ただし、これらのクラウド/CDNサービスそのものが侵害されたという意味ではありません。
Hazy Hawkが狙うのは、組織が過去に外部サービス上で作成し、その後廃止した資産と、削除されず残ったDNSレコードの組み合わせです。クラウドサービスごとに名前空間や再取得防止策は異なり、すべてのダングリングCNAMEがそのまま乗っ取れるわけでもありません。
Infobloxは、一部クラウド事業者がダングリングDNSからの乗っ取りを防ぐ仕組みを実装していることも説明しています。Microsoft Azureでも、カスタムドメイン検証などサブドメイン乗っ取りを防ぐための保護策が提供されています。
CDCだけでなく政府・大学・大企業のサブドメインを悪用
Infobloxは、Hazy Hawkが少なくとも数十の著名組織に関連するサブドメインを乗っ取っていたとしています。
一次調査で例示された組織には、米アラバマ州政府、オーストラリア保健当局、UC Berkeley、University College London、CDC、Deloitte、EY、PwC、TEDなどがあります。
ただし、これは各組織の親ドメイン全体や社内システム、クラウドアカウントが侵害されたことを意味しません。
Infobloxが追跡しているのは、組織の正規ドメイン配下に存在した特定サブドメインと、放棄済みクラウド資産の関連を悪用した事象です。
また、各組織について、利用者被害やマルウェア感染件数などが個別に確認されているわけでもありません。
正規ドメインの信頼性とSEOを詐欺へ転用
Hazy Hawkが乗っ取ったサブドメインには、多数のURLが作成されていました。
正規組織のドメイン配下であるため、利用者から見れば信頼できるURLに見えやすく、検索エンジン上でも親ドメインの評価を利用できる可能性があります。
Infobloxによると、これらのURLは最終的な詐欺サイトへ直接接続するとは限らず、複数のリダイレクトやTraffic Distribution Systemを経由します。
到達先はアクセス元の地域や端末などによって変化し、テクニカルサポート詐欺、偽ウイルス対策ソフト、マルウェア配布、フィッシング、偽動画・ストリーミングサイトなどへ振り分けられていました。
ブラウザのプッシュ通知を許可させ、サイトを離れた後も詐欺広告や偽警告を表示するケースも確認されています。
Infobloxは、こうした広告・アフィリエイト型のサイバー犯罪エコシステムでHazy Hawkが乗っ取った正規サブドメインが利用されていると分析しています。
乗っ取り対象の探索には高度なDNSデータが必要
ダングリングCNAMEの考え方自体は新しいものではありません。
一方、InfobloxはHazy Hawkについて、放棄されたクラウド資産を大量に発見する能力が特徴的だとしています。
通常の未登録ドメインを指すCNAMEであれば、参照先が存在しないことを比較的確認しやすい場合があります。
しかし、クラウドサービスでは廃止された資産への応答方法がプロバイダーごとに異なり、DNS問い合わせだけでは利用可能な資産かどうか判断できない場合があります。
Infobloxは、Hazy Hawkがこうした対象を発見するには広範なパッシブDNSデータへのアクセスと相応の技術力が必要だと分析しています。
なお、Infobloxは悪用可能なCNAMEを特定する具体的な探索方法については公開していません。
2026年もダングリングDNSは多数存在
Hazy Hawkの主要な一次調査は2025年に公表されたものですが、ダングリングDNSによるサブドメイン乗っ取りは2026年時点でも現実的なリスクです。
AWS CIRTは2026年6月、攻撃者が公開CNAMEを能動的に探索してサブドメイン乗っ取りの機会を探していると公表しました。
Cloudflareも2026年、自社のSecurity Overview向け検査エンジンが1週間に1億件超のDNSレコードを検査し、そのうち100万件超をダングリングDNSとして検出したと公表しています。
このうち約3%、約3万1,000件がダングリングCNAMEで、Cloudflareの調査対象では95%がMicrosoft Azureサービス、3%がAWS Elastic Beanstalkを参照していました。
これはインターネット全体の統計ではなく、Cloudflareの検査対象に基づくデータです。
それでも、クラウド資産を廃止した後にDNSだけが残る問題が大規模環境で現在も発生していることを示しています。
クラウド資産を削除する前にDNSを処理する
InfobloxはHazy Hawkへの基本対策として、クラウドリソースを停止・廃止した際に、対応するCNAMEを削除する運用を確立するよう推奨しています。
AWSも同様に、リソース廃止時の標準手順を設けることを最も有効な予防策として挙げています。
特に重要なのは、DNSとクラウド資産を別々に削除するのではなく、ライフサイクルを一つの変更管理プロセスとして扱うことです。
クラウドリソースだけを削除し、DNS変更を別チームへ依頼したまま忘れると、ダングリングDNSが発生します。
大企業では、DNS管理、クラウド管理、Web開発、事業部門、外部委託先が別組織になっていることが多く、M&Aやサービス終了、プロジェクト廃止時に特に残存しやすいとInfobloxは指摘しています。
DNSの棚卸しは「応答しているか」だけでは不十分
サブドメイン乗っ取り対策では、DNSレコードが名前解決できるかだけを確認しても十分ではありません。
AWSは2026年の解説で、すでに攻撃者が放棄済み資産を取得していた場合、DNSは正常に応答してしまうため、「名前解決できる=自社資産である」と判断できないとしています。
必要なのは、DNSレコードと実際のクラウド資産台帳を照合し、参照先が自社アカウント・自社契約下に存在するか確認することです。
クラウドアカウントを複数利用している企業では、アカウント横断で資産を確認する必要があります。
DNS、CMDB、クラウド資産管理、Infrastructure as Codeなどを連携させ、CNAMEの参照先と実資産の所有関係を継続的に検証する仕組みが求められます。
情報システム・クラウド管理者への示唆
Hazy Hawkの事例で確認すべきなのは、DNS設定そのものより「サービスを廃止するときの手順」です。
まず、公開DNSに登録されているCNAME、A、AAAAなどを棚卸しし、それぞれが現在利用しているクラウド、CDN、SaaS、ホスティング環境のどの資産を指しているか確認する必要があります。
特に、過去のPoC環境、キャンペーンサイト、採用サイト、イベントサイト、M&Aで引き継いだドメイン、終了済みプロジェクト、開発・検証環境は確認優先度が高い領域です。
クラウド資産を廃止する場合は、DNS担当とクラウド担当のどちらか一方の作業だけで完了扱いにせず、DNS削除までを廃止手順へ組み込むことが重要です。
また、DNSレコードの作成時に「所有者」「利用システム」「クラウドアカウント」「有効期限」「廃止予定日」を記録し、所有者不明のレコードを定期的に抽出できるようにすると管理しやすくなります。
インターネット利用者側への対策としては、Protective DNS、Webフィルタリング、ブラウザ通知の制御も有効です。
正規組織のドメイン配下だから安全と判断せず、リダイレクト後のURLやブラウザ通知要求を確認する必要があります。
セキュリティ対策Labでは、DNS設定不備を利用する別のドメイン乗っ取り手法「Sitting Ducks」や、Vacant Viper、Hasty Hawkなどの活動も整理しています。
関連記事:DNSへのサイバー攻撃:ドメインハイジャックの新たな脅威
Hazy HawkとSitting Ducksでは技術的な成立条件が異なりますが、共通するのは「現在使われていないDNS資産が、組織の信頼されたドメインを攻撃者へ提供してしまう」という点です。
クラウド資産の作成を自動化する企業では、廃止時のDNS削除と所有権確認も同じレベルで自動化・監視することが重要です。
出典
- Cloudy with a Chance of Hijacking: Forgotten DNS Records Enable Scam Actor – Infoblox Threat Intel
- Hazy Hawk: Domain Hijacking Threat Actor – Infoblox Threat Intel
- Threat tactic spotlight: Subdomain takeover – AWS Security Blog
- Prevent dangling DNS entries and avoid subdomain takeover – Microsoft Learn
- Building a security overview dashboard for actionable insights – Cloudflare
- Hazy Hawk Exploits DNS Vulnerabilities to Hijack Cloud Resources and Spread Malware – CyberPress
- DNSへのサイバー攻撃:ドメインハイジャックの新たな脅威 – セキュリティ対策Lab






