「Danglegeddon」へようこそ

Silent Pushのシミュレーションにより、ダングリングDNSドメインが世界に脅威を与え続ける理由を解明

要点

• Silent Pushの調査チームは「ダングリングDNSインフラ」を調査するため、政府・銀行・自動車製造・製薬の4業界を対象にしたシミュレーションを実施しました。
• シンプルなエージェントベースの計測手法とAIワークフローを適用し、悪用される恐れがあるサブドメインを特定・列挙・発見しました。
• 同じ手法を繰り返し使っても成果が得られることから、大規模なDNSテイクオーバーが発生し得ることに気付きました。
• 本プロジェクトを「Danglegeddon」と名付けました。

本記事は、マキナレコードが提携するSilent Push社のブログ記事『Welcome to Danglegeddon』（2026年7月30日付）を翻訳したものです。

こちらのページから、Silent Pushで公開中のその他のブログ記事もご覧いただけます。

概要

インターネット上には、その存在を忘れられたり、放置されたり、あるいは設定ミスで「宙ぶらりん」になったサブドメインが無数にあります。これらは一見すると無害なため、アナリストやエージェント、そして防御する側にとっても、早急に対策すべきサイバー脅威として認識されるとは限りません。

この「宙ぶらりんのDNS」に紐付くインフラ、すなわち「ダングリングDNSインフラ」に着目したSilent Pushの調査チームは、ある素朴な疑問を抱きました。「熟練した国家支援型アクターの視点からこれを見てみると、どうなるのだろうか？」と。

また、この「極めて悪用されやすい」インフラに対し、これまでにない規模で模擬攻撃を行うとどうなるのでしょうか？その影響はどのようなもので、被害がどこまで広がり、どれほどの速さで大規模なテイクオーバーが可能になるのでしょうか？

Silent Pushのアナリストチームは、政府機関やフォーチュン500企業を含む一連の組織に対し、まずマイクロソフトのインフラに焦点を当てた脅威調査イニシアチブを立ち上げ、このプロジェクトを「Danglegeddon」と名付けました。

Silent Pushのアプローチ

ダングリングDNSインフラのサンプル

インフラの初期サンプルとして、計1万2,500件のドメインをターゲットに設定しました。これはSilent Pushのデータセットで日々確認される企業やインフラに関する変更記録の総数のうち、ごくわずかな数にすぎません。Silent Pushは各対象組織のVDP（脆弱性開示プログラム）やBBP（バグバウンティプログラム）、セーフハーバーを確認してから、脆弱性のパッシブスキャンを行いました。

観測したレコードはすべて「ダングリングな」状態であり、各企業にとってリスク要因となっていました。1万2,500件のApexドメインを調査したところ、1万6,000件のダングリングサブドメインを特定し、そのうち4,000件を自動でテイクオーバーできました。残りのうち7,000件は、テイクオーバーの条件を満たしているかどうかを判断するために、追加の確認作業が必要でした。さらなる精査の結果、残った5,000件はプロバイダーによる保護策が講じられており、安全であることが確認できました。

唯一無二の手法：DNSテイクオーバー

このシミュレーションでは、以前から広く知られる手法の1つである「ダングリングDNSテイクオーバー」という特別な手法を用いました。これにより、DNSのさまざまな設定ミスやCookieの広すぎるスコープ設定を悪用したフィッシングキャンペーンを展開し、クレデンシャルハーベスティングやOAuthリダイレクトが可能になることを明らかにしました。

次に、シンプルなエージェントベースの計測手法とAIワークフローを適用し、DNSドメインおよびサブドメインの探索範囲を拡大しました。これにより、ドメインやサブドメインの発見・列挙といったプロセスが高速化され、「ダングリングDNSテイクオーバー」を大規模かつ迅速に実行することが可能になったのです。

AIを使ってスピードアップ

引き続きAIを調査に活用し、サブドメインを特定・列挙・発見しました。

対象組織のBBPやVDPの条件を基にコンテキストのエンリッチメントを行うことにより、Claudeのモデル「Opus 5」で迅速にスクリプトが生成できるようになりました。このプロセスでは対象組織のドメイン1万2,500件と、EdOverflow氏のGitHubプロジェクト「Can-I-take-over-xyz」に記された脆弱なプロバイダーのCNAMEとの照合が行われました。

Silent PushのDangling DNS APIを活用し、割り当てやDNS登録が行われていないリソースをさらに絞り込みました。この手法で数百件のドメインを特定した上、各プロバイダーに対して利用可能かどうかを交差検証しました。続いてこのプロセスを通じ、DNSドメインの所有権を確認せずにCNAMEをカスタム設定できる新たなレジストラやプラットフォームを速やかに発見することができました。さらにこの発見プロセスを経て、脆弱な詳細不明のプロバイダーをいくつか特定するに至りました。

わずか数時間のうちに、これらすべての脆弱なドメインを一斉にテイクオーバーして悪用できるスクリプトが完成しました。Silent Pushはセキュリティ事業者として、こうした調査を行う際の法的リスクを十分認識しています。高度なスキルを持つ脅威アクターなら、最初に標的範囲を名前解決可能なすべてのドメインに広げるだけで、いとも簡単に「Dangleggedon」を始められるはずです。

脆弱さとサイバーハイジーンの不備を悪用する

被害者のネットワークの多くには古いリソースの呼び出しが残っており、企業のWebサイトとスクリプトからインバウンドの参照やクロスサイトスクリプティング（XSS）を直接受け入れる状態になっていました。これによって模擬攻撃が可能になっただけでなく、世界中のあらゆる業界や組織で「管理が行き届いていないインフラ」が標的になり得ることも裏付けられました。

人員削減や（M＆Aに伴う）インフラ所有権の統合、そして大規模な一時解雇は、極めて攻撃を受けやすい脆弱な状況を生み出しました。特に変更管理や職員の退職手続きの際、サイバーハイジーン（IT衛生管理）が徹底的かつ直ちに実施されなければ、組織は攻撃に対してさらに脆弱な状態に置かれます。

マイクロソフトのインフラ＝最も容易にアクセス可能

Silent Pushの取り組みは、まずMicrosoft AzureのBLOB、VM、Web Apps、API、Power Pagesを使ったインスタンスに焦点を当てました。ミッションクリティカルな産業におけるテイクオーバー事例の実情を検証するため、初期サンプルとして政府、銀行、製薬、自動車の各業界のインフラを選定しました。同じ手法を繰り返し適用した結果、再現性のある「成功」​​を収められることがわかりました。Silent Pushはこの時点で、膨大な規模のテイクオーバーが発生し得ることに気付きました。

影響

シミュレーションでは自動車、銀行・金融をはじめ、エネルギー、政府機関、医療、製薬、製造、輸送、公益事業など幅広い業界の組織を調査しました。

政府機関：米国のある政府機関を選び、マイクロソフトのインフラを利用する全システムとアクセス可能な従業員の認証情報に先述の手法を使った場合、下流に与える影響をモデル化しました。

• テイクオーバーの直接的な影響は無数のシステムと従業員に及び、さまざまな混乱を引き起こす可能性があります。
  • 例えば、国防総省（DoD）では660億米ドルの予算に影響を与え、その余波が下流に広がります。
  • 連邦政府全体のインフラにおいて、DoDが占める割合は推定31％とされていることを踏まえると、200万人以上の職員が利用する数千〜数万ものシステムに影響を与える可能性があります。
• 各部門間の相互依存関係や、文書化されたサイバーセキュリティ監視体制の不備を考慮すると、アタックサーフェスは桁外れに大きくなる可能性があります。
  • 連鎖的な攻撃はDoDの枠を大きく超え、軍の各部門や国家安全保障システムにまで波及する恐れがあり、国家安全保障に深刻な影響を及ぼしかねません。

金融機関：大手国際銀行に同じ手法で同様のシミュレーションを行い、下流への影響を分析しました。この業界ではマイクロソフトのインフラへの依存度が極めて高いことから、業界全体に甚大な影響が及ぶ可能性が示唆されています。

• 推定で大手国際銀行の80％以上、主要金融機関の75％以上がAzureのクラウドサービスを利用しており、同サービスに障害が発生した場合、深刻な混乱やパニックに陥る可能性があります。
• こうした混乱が世界中で発生した場合、バンク・オブ・アメリカ、UBS、モントリオール銀行といった国際金融機関において、高性能なリスクモデリング、セキュアなデータ処理、生成AIを使った機能のデプロイに影響が及ぶと思われます。
• 世界の金融業界に広がる下流への影響としては、オンラインバンキングやリアルタイム決済の機能停止、取引プラットフォームの閉鎖などが挙げられます。顧客の口座が利用できなくなる、取引処理が遅延する、あるいは金融機関の間で広範な通信障害が発生するといった事態は、世界各地の消費者に直接的な影響を及ぼします。 

大手製薬企業：非常に多くの製薬会社がAzureクラウドを利用しているおり、あるグローバル製薬企業を対象にしたシミュレーションでは下流に甚大な影響を及ぼす見通しが明らかになりました。

• 世界各地の主要製薬会社の推定75〜85％が業務にMicrosoft Azureを利用しています。これには同業界のフォーチュン500企業はもちろん、それ以外の企業も含まれます。
• 一例として、2017年のNotPetya攻撃（世界全体での推定被害額は100億米ドル）の影響を受けたメルクでは、わずか数分間で4万ものシステムがダウンし、14億米ドルに上る損失が報告された結果、保険会社側が保険金の支払いを拒否する事態に発展しました。システム停止や連鎖的な障害も発生したこのインシデントは、10年以上にわたる訴訟の末、サイバー保険の定義を一変させました。
• 2026年にはアボット・ラボラトリーズ、ノボ・ノルディスク、ウエスト・ファーマシューティカル・サービシーズなどを標的とした、巧妙なサイバー攻撃やランサムウェア被害が増加しています。
• 複数の国際製薬企業を巻き込む連鎖的なテイクオーバーが急速に進行すれば、高度な研究開発体制が損なわれ、臨床試験が混乱するだけでなく、医薬品や治療ソリューションの世界的供給を支えるサプライチェーンに一層深刻な影響を与える恐れがあります。
• 組織全体における損失額は、推定で数千億米ドル規模に上る可能性があります。

自動車業界：フォーチュン500に名を連ねるメーカーを対象に、歴史ある米自動車企業のサブドメインを乗っ取ることに成功しました。

• これまでの事例を振り返ると、大手自動車メーカーに対するサイバー攻撃で一度に数十億米ドル規模の損失が発生するほか、国内のサプライチェーンが数日以内に麻痺する可能性があります。
  • 2025年に発生したジャガー・ランドローバー（JLR）へのサイバー攻撃は、5週間にわたる生産ラインの停止に加え、3億5,000万米ドルもの直接的な損失を生じさせただけでなく、英国経済全体に推定25億米ドルの損害を及ぼしました。影響を受けたサプライヤーやディーラーは5,000社を超え、英政府がサプライチェーンの維持を目的に支援融資を行う異例の対応を行っています。
• 混乱は急速に拡大し、その影響がJLRという企業の枠を超えて大きく広がりました。実際、イングランド銀行は当該四半期に英国のGDPを押し下げた要因の1つとして、JLRの操業停止を挙げています。これはメーカー1社のシステム障害が国全体の経済指標を揺るがしかねないことを示しており、生産計画からサプライチェーンの物流まで、業務がどれだけ深く影響を受けたかによって、波紋の広がる規模が変わることを浮き彫りにしています。
• 調査対象の自動車メーカーのサブドメインを乗っ取った攻撃者は、以下のような活動を行うことができます。
  • 正規ドメインを使い、フィッシングページやマルウェアなどの有害コンテンツをホスト・配信
  • 信頼されたサブドメインを悪用し、ブランドの評判を毀損
  • ユーザーの認証情報を盗み出し、正規サービスと見間違える巧妙なフィッシングページを作成
  • Cookieを盗み、親ドメインにスコープされている場合はセッションCookieも窃取
  • 正規サブドメインがセキュリティツールのホワイトリストに登録されている場合、セキュリティ制御を回避し、有害コンテンツのフィルタリングを無効化
• 攻撃者が正規ドメインの信頼を悪用して不正な活動を行えるため、この脆弱性は重大なセキュリティリスクをもたらします。

模擬攻撃の詳細

前述のAIを活用した調査で説明したように、ドメイン乗っ取りの最適な手法を突き止めるため、複数の方法で対象アカウントを検証しました。この一連のプロセスを通じて、当社が危険と判断した主な業界と政府機関は、人事異動やインフラへの依存関係によって脆弱な状態になったことが明らかになりました。なお、テイクオーバーの検証は、Silent Pushが責任を持ってすべて開示しています。

いずれのケースにおいても、当該組織のダングリングDNSインフラに紐付く放置リソースのテイクオーバーに成功しました。その後、各組織のサブドメインを当社サイトへリダイレクトさせることにより、任意のコンテンツを配信できる状態にしました。また、これらの組織にはVDPなどの手段を通じてコンタクトを取り、ドメインやダングリングDNSインフラが露出している旨を通知しました。

特定した脆弱なDNSインフラのリストに基づき、各業界から1組織ずつ選んだ上で、このテストを実施することについての意向を確認しました。Silent Pushの狙いは、ダングリングDNSインフラを擁するあらゆる組織は事実上、サブドメインのテイクオーバーに対して脆弱という仮説を検証することでした。

乗っ取られたサブドメインは、それ自体が直ちに侵入を意味するわけではないにせよ、攻撃の足掛かりや信頼できる起点（ランチパッド）になります。親組織の評判を継承し、TLS証明書も取得できるため、攻撃者は通常、本物そっくりなフィッシングページや認証情報窃取フォームのホスト先として、このサブドメインを利用します。設定に不備があるケースでは、共有セッショントークンを直接傍受するために不正利用されることもあります。 

そこからさらに内部システムへ入り込む、あるいは実際に業務を妨害するには、標的の組織にダングリングDNSレコード以外の不備がなければなりません。例えば多要素認証が脆弱だったり、システム間の内部的な信頼関係があまりにも広範に設定されていたりする、またはサードパーティとの信頼関係が本来あるべき範囲を越えているといった問題です。ダングリングDNSはあくまで出発点でしかないため、最終的な被害の深刻さは、足掛かりを得た後にサイバーハイジーンとして追加されたセキュリティ層がどれだけ機能しない（あるいは不具合を露呈する）かにかかっています。それらの多くは、かつて有効だったデバイスの位置や、そのDNSレコードが指していたデバイスへの内部的な信頼関係が引き続き維持されているかどうかに左右されます。

それぞれの業界を対象としたシミュレーションの詳細を以下に記します。

Silent Pushプラットフォームを使った調査

政府機関でのシミュレーション

このシミュレーションでは、当社のサンプルから米連邦政府機関を1つ選定しました。当該組織のDNSレコードは脆弱な状態にあり、所有権が割り当てられていないAzure Blob Storageのリソースを指していました。

そのサイトをホストした後、海事関連のサブドメインでスピアフィッシング攻撃向けのトピックを違和感なく扱えるようになります。このドメインは人間に検知されにくいだけでなく、.govドメインの信頼性を逆手に取って自動のセキュリティ対策を回避できます。

金融機関でのシミュレーション

第2のサンプリング対象として、フランスの大手国際金融機関を選びました。この銀行は米国の姉妹行と同じく、サイバーハイジーンに不備がありました。あるアプリケーションに向けられたAzure Blob Storageのリソースを、割り当て先が設定されていない状態で放置していたのです。

自動車メーカーでのシミュレーション

3つ目のシミュレーションでは、フォーチュン500に名を連ねる米国の巨大自動車メーカーを扱います。

この企業は、Azure Virtual Machine（VM）上でホストされている開発用アプリゲートウェイを指すダングリングDNSレコードを放置していました。これが悪用されると、内部スクリプトやAPI呼び出しから格納型XSS攻撃をパッシブに受ける可能性があります。 

APIキーや認証ヘッダーといった開発者の認証情報は、企業内への侵入経路をさらに広げるために再利用されるかもしれません。さらに、この仮想マシンと高価値なTLS暗号化を併用することで、マルウェアをホストするプラットフォームとして利用される可能性もあります。 

製薬企業でのシミュレーション

Silent Pushが調査を行った大手製薬会社は、Apple製デバイスの利用ガイドを指すレコードを残していました。このように特定のテーマへの関連性が強い場合、攻撃者はより具体的な標的やイベントに焦点を絞ることができます。

発見に至る過程の中で、カスタムCNAMEを登録できるオンライン出版プラットフォーム「Paperturn」を発見しました。このプラットフォームでは、PDFなどのファイルをホストしたり、デジタルブックに変換したりすることができます。

プラットフォームの活用：AIを使った先駆的ハンティングの手法

ClaudeはダングリングDNSレコードの検索だけでなく、大量のデータ要約においても優れた能力を発揮しました。

さらに、リソースを乗っ取れるかどうかもチェックしました。

仮説に基づくシナリオに過ぎなかった「Danglegeddon」は、ほんの数分でひどく現実味を帯びた脅威になりました。 

コンテキストウィンドウをクリアにし、エージェントチームがClaudeをスワップインすると、インフラ構築の自動化は簡単なタスクになり、Cyber Verification Program（CVP）のフラグをバイパスするとともに、あとボタン1つで「Danglegeddon」が発生する状態になりました。

緩和策を導き出す分析エンジン

Silent Pushは、少ない手数でこのサイバーハイジーンタスクを「Defender」プレイブックに追加するために必要な知見を提供しています。このタスクを追加するとDNSレコードの修正が可能になり、「Dangglegeddon」の発生を回避できるようになります。

これまで説明してきた調査はすべて、基となるデータの収集方法が重要な鍵になっていました。サブドメイン乗っ取りに関する調査の大半は、まず推測から始まります。アナリストがターゲットを選び、ワードリストを使って検索を実行し、返ってきた結果を解決して、本来の組織によるクレーム（※）状態が失効し、所有権や管理権が放棄された状態のリソースを示すものがあるかどうか確認するのです。つまりこの方法では、テスト対象の組織をスキャンする時点で推測されたホスト名しか見つけることができません。

（※訳者注：クラウドサービスをはじめとする外部サービス上のリソースを自身のドメインやサブドメインに紐付けたい場合、一般的には利用したいドメインをそのサービス上で登録し、リソースと関連付ける必要があります。このように、外部サービス上で特定のドメインやサブドメインを自分のリソースに割り当て、利用できる状態にすることをここでは「クレーム（claim）」と呼んでいます）

Silent Pushは推測で決定するのではなく、毎回データセット内の全ホスト名を再解決しています。CNAMEのターゲットが解決できなくなったり、MXホストが消えたり、委任されたネームサーバーが応答しなくなったりすると、その日のうちに結果が更新されます。なぜなら、1度に1つのターゲットに絞って監視するのではなく、ネームスペース全体を確認しているからです。わざわざスキャンを実行してダングリングレコードを取得しているのではなく、解決を継続的に行った際の「副産物」としてそのようなレコードが浮かび上がってきます。

この特質は、攻撃者よりも防御者にとってより重要な意味を持ちます。そもそも、組織が侵害される原因となるレコードを作成したこと自体、作った側は誰も覚えていません。構成管理データベース（CMDB）にはその記録がなく、前回のペネトレーションテストの対象範囲にも含まれていない上、もしかしたら2年前に再編成されたチームが管理していた可能性もあります。企業に自社のインフラをスキャンするよう依頼しても、見つけられるものは「所有している」と認識しているものに限られます。Silent Pushの検出プロセスは、そのような依存関係を利用していません。だからこそ、今回の調査対象となった1万2,527件のAPEXドメインから、8万5,254件のダングリングレコードだけでなく、1万6,544件もの精査に値するレコードが得られたのです。

Dangling DNS Viewを読み解く

後述する「さらなる対応策」に添付したスクリーンショットは、ドメインのレコードを1つの画面から確認できるTotalViewの「Dangling DNS（ダングリングDNS）」タブを開いたものです。画面上段部のタブには、「PADNS」 「WHOIS」「Certificates（証明書）」「Subdomains（サブドメイン）」 「Threat Feeds（脅威フィード）」など複数のタブが並んで表示されていますが、これらのレコードとは切り口が違う「Dangling DNS」もここに配置されています。さらにはパッシブDNS履歴や証明書の発行ログ、組織に関するその他の情報などにも、ページ遷移することなく直接アクセスできます。

このタブでは、2つのパネルにダングリングDNSの情報がまとめられています。

「Dangling DNS Records Count（ダングリングDNSレコード件数）」チャートは、検出結果を「Danglers Unchanged（変更なし）」「Danglers Added（追加分）」「Danglers Removed（削除分）」に分類し、レコードの種類を色分けしています。NSレコードは青緑色、MXレコードは青色、CNAMEレコードは黄色です。毎日再解決を行っているため、この記録はスナップショットではなく前回からの変更差分となっています。「Danglers Unchanged（変更なし）」は、遅くとも前回の収集サイクルから存在するエクスポージャーです。また、「Danglers Added（追加分）」は前回のサイクル以降に発生したエクスポージャーであり、防御側が新たに警戒すべきもの。「Danglers Removed（削除分）」はクリーンアップされた、または解決されなくなったレコードを示しています。

その下の「Dangling DNS Record Details（ダングリングDNSレコードの詳細）」では、調査結果をタイプ別に表示しています。各タブにはレコードの件数のほか、それぞれについて次の4項目を確認できます。「Query（クエリ）」は組織が所有するホスト名を、「Answer（応答）」はそのホスト名が現在指している場所を示します。「Foreign_target（外部ターゲット）」は応答が組織の内外のどちらから来ているかをマークし、壊れたポインターが組織によって引き続き管理されている場所にあるのか、そうでない場所にあるのかを示します。これが「external（外部）」になっている場合は、テイクオーバーされるリスクが存在します。また「State（状態）」は「unchanged（変更なし）」あるいは「removed（削除済み）」を示しています。

以下の4枚のスクリーンショットにおいては、放置されたレコードの件数に注目してください。金融機関にはCNAMEが27件、MXが1件あり、自動車メーカーは1,437件のCNAMEがあります。一方、製薬会社にはシミュレーションで使用したPaperturnレコードを含めてCNAMEが271件あり、連邦政府はCNAMEが221件、MXが10件、NSが1件となっていて、そのうちの数件が未所有・未管理のAzure Blob Storageを指しています。Silent Pushが各組織に問い合わせたところ、いずれの組織もこの事態を把握していませんでした。

「ダングリング」状態のCNAME・MX・NSに固有のリスクが存在する理由

CNAME：ホスト名そのものは応答するものの、エイリアスされるサービスがデプロビジョニングされています。プロバイダーでリソース名を所有する者は、ホスト名、親ブランドの評判、そして多くの場合、自動ドメイン検証による有効なTLS証明書を受け継いでおり、Silent Pushではすべてのシミュレーションでこれを悪用しました。また、4組織すべてでCNAMEを示す黄色の棒グラフが一番高くなっているため、このような状況は特に珍しくもないことを示唆しています。

MX：もう存在しないホストにドメイン宛てのメールがルーティングされている状態で、これにより2つの問題が発生します。まず、DMARCレポートやそのエクスチェンジャーを経由するメールを含む正規メールの受信に、気付かぬうちに失敗します。次に、より深刻な問題として、当該メールホストを不正に取得・再登録できる攻撃者が企業宛てのメールを受信できてしまいます。つまり、パスワードリセットリンクや請求書、ベンダーとのやり取りだけでなく、多くのプロバイダーが証明書の発行やアカウント復旧時に必要とするメール認証など、あらゆるメールを攻撃者が盗み見れることを意味するのです。

NS：この3つの中で最も厄介でありながら、発生頻度が最も低いために見落とされがちです。ゾーンまたはサブゾーンが応答しなくなったネームサーバーに委任されている状態を意味し、多くの場合、ドメインの有効期限が切れていることや、ホストされていたDNSゾーンが削除されたことに起因します。あるネームサーバーを制御できる者は、その下のゾーン全体も制御できてしまいます。つまり、あらゆるホスト名の制御に加え、Aレコード、MXレコード、ワイルドカード証明書の検証に使用されるTXTレコードなど、新たにレコードを作成する機能も操作できることになります。攻撃者にとって1件の放置されたNSレコードは、1,000件の「ダングリングCNAMEレコード」よりも価値があるかもしれません。

対処方法

影響範囲の大きいレコードから順に対処してください。まずNS、次にMX、続いて外部CNAME、最後に内部CNAMEです。

各レコードを修正するには、そのレコードを権限ゾーンから削除してください。レコードに紐付くサービスが実際にまだ使用されている場合のみ、再度指定し直します。ホスト名がまだアクティブなページやスクリプトで参照され、基となるリソースが回収可能であれば、まず予防的にリソースの所有権を確保し直し、次にリファレンスとレコードを削除してください。

プロセスの是正では、クラウドリソースよりも先にDNSレコードを削除するという順序付けルールを設ける必要があります。本調査で明らかになった問題の多くは、チームがストレージアカウント、Webアプリ、または仮想マシンのデプロビジョニングを行った際に、レコードを削除せず放置していたことに起因しています。廃止時のマニュアルではこの手順を入れ替えて先にレコードの処理を行うようにすることで、原因となる状況を根本から解消できます。

さらなる対応策

• カスタムホスト名を使う際には、ドメインの所有権を必ず確認するプロバイダーを利用してください。例えばAzureなら、asuidなどのTXT検証レコードを使うプロバイダーです。所有権が確認できないと判断された4,925件のレコードも、このような保護策のあるプロバイダーを使っていれば問題を防げていたかもしれません。
• すべてのDNSレコードに、所有者とメンテナンス実施日を割り当ててください。従業員の削減・一時解雇・M＆A後のインフラ所有権の統合などによって、ほかから分断されたゾーンが生じます。現在、このような出来事に応じてDNSの点検を実施する企業は多くありません。
• CAAレコードを公開して、自社のネームスペースに対して証明書を発行できる認証局を制限してください。要求していない証明書が発行された際には、証明書の透明性ログをチェックしてください。
• ドメインサフィックス／TLDによるリスト表示が可能なセキュリティ制御は、すべて監査してください。特に、信頼できるブランドから引き継いだサブドメインでは、監視の目が行き届いていない可能性があります。
• 定期的にではなく、継続的にDNSを監視・点検してください。Silent PushのDangling DNS APIを使えば、これらの検出結果が自動的に返されます。つまり、四半期ごとに1度だけ確認していた作業は、セキュリティ運用チームとITチームに継続的なアラートを届けるプロジェクトに変化します。

Danglegeddonを克服する

この調査イニシアチブの目的は、企業や組織がより適切に脆弱性を特定し、既存のインターネットインフラを悪用する攻撃者から身を守るための単純な方法を開発することでした。

これを実現するために、主要産業を担ういくつかの組織からインフラサンプルを収集し、攻撃シミュレーションを実行するとともに、その結果を分析しました。シミュレーション全体を通して同じ手法を用い、標的とした各組織に関連付けられた「宙ぶらりん」なインフラ、すなわちダングリングインフラを乗っ取り、安全かつ管理された環境内でリダイレクトすることにより、オープンインターネットでどれほど簡単に悪用できるのかを実証しました。

また、組織がネットワーク全体でサイバーハイジーンを実施していない場合、ダングリングDNSドメインやサブドメインがいかに危険であるかを広く周知することが本イニシアチブの狙いでした。

Silent Pushは、グローバルインフラから採取された小規模ながらも重要なサンプルを対象に、ダングリングDNSが乗っ取られた際に下流にどれほどの範囲で影響が生じるのかを調査しました。その結果、組織のインフラが迅速かつ容易に悪用されることが明らかになりました。特に、攻撃者はまさにその悪用という目的を達成するため、サードパーティのインフラを使って容易に準備を整えることができるからです。

徹底したサイバーハイジーンを遵守することに加え、Silent Pushのプラットフォームを利用し、放置されたインフラやその他のアセットを特定するなど多くの予防策を講じることにより、ネットワークを先駆的に保護することができます。

「Danglegeddon」のシナリオでは、ビジネスや重要なサービスに大きな支障が生じます。しかし、今回注目したマイクロソフトは、同様のリスクを抱える多くのクラウドプロバイダーの1つに過ぎません。マイクロソフト以外のインフラもいまだに相当数が使用されており、広範にわたるアタックサーフェスを生み出しています。このことについては、続編で詳しく検証する予定です。

さらに詳しく知る

まずはSilent Pushのエキスパートにご相談ください。当社のプラットフォームを活用する先駆的サイバー防御により、攻撃が始まる前に攻撃者のインフラを特定し、さらに多くのリードタイムを確保する方法についてご説明いたします。

また、無料で利用可能なコミュニティ版でも、Silent Pushのプラットフォームを使って既存のセキュリティスタックと統合する方法を確認できます。

※日本でのSilent Pushに関するお問い合わせは、弊社マキナレコードにて承っております。

詳しくは、以下のフォームからお問い合わせください。