企業のウェブサイトやサービスで使われるドメインは、インターネット上の「住所」であり、顧客からの信頼の礎となる重要な資産です。しかし今、そのドメインの一部である「サブドメイン」が、設定のわずかな見落としから第三者に乗っ取られ、巧妙なサイバー攻撃に悪用される事例が世界中で深刻化しています。「サブドメイン乗っ取り（Subdomain Takeover）」と呼ばれるこの脅威は、使われなくなったクラウドサービスや外部サービスへのDNS設定を削除し忘れたまま放置してしまう、いわゆる「ダングリングDNS（宙ぶらりんのDNSレコード）」を足がかりにします。攻撃者はこの隙を突いて、本来の組織が持つ正規ドメインのサブドメインを掌握し、フィッシングサイトやマルウェア配布の拠点として悪用するのです。見た目は完全に正規のURLであるため、利用者は疑うことなくアクセスしてしまい、被害はブランドイメージの毀損から、サプライチェーン全体を巻き込む大規模なインシデントへと発展しかねません。2025年に入り、日本の政府機関ドメインでもこの問題が発覚し、決して他人事ではない脅威として国内でも急速に関心が高まっています。本稿では、この静かで深刻な脅威の実態を国内外の最新事例から読み解き、なぜ攻撃が起きるのか、そして組織としていかにして自社のドメインを守るべきか、その具体的な対策を深く掘り下げていきます。

日本でも顕在化した静かなる脅威――政府機関ドメインで起きたこと

2025年1月、日本のセキュリティ界隈に大きな衝撃が走りました。国土交通省をはじめとする複数の省庁や関連機関において、過去に利用していたサービスのサブドメイン設定が削除されないまま放置され、第三者がそれを悪用できる危険な状態にあったことが、大手メディアによって次々と報じられたのです。特に深刻だったのは、国土交通省が過去に使用していた特定のサブドメインが、実際にある海外のオンラインカジノの広告サイトへ利用者を誘導する目的で悪用されていたという事実でした。政府機関の公式サイトのドメイン（go.jp）を冠したURLが、全く無関係な、それも公序良俗に反する可能性のあるサイトに繋がっていたこの出来事は、「サブドメイン乗っ取り」の危険性を日本国内に広く知らしめる象徴的な事件となりました。

この攻撃の根源にあるのは、「ダングリングDNS」と呼ばれる状態です。これを分かりやすく例えるなら、引っ越した後の古い家に、以前の住人の表札が残っているようなものです。新しい住人がその表札を悪用して郵便物をだまし取ったり、なりすましたりできるように、インターネットの世界でも同様のことが起こります。企業や組織がウェブサイトのリニューアルや、利用するクラウドサービスの変更を行った際に、古いサービス（例えば、Amazon S3のストレージやMicrosoft Azureのウェブアプリなど）は解約します。しかし、その古いサービスに向けて設定されていたDNSレコード、特にドメインの別名を定義する「CNAMEレコード」を消し忘れてしまうことがあるのです。攻撃者は、インターネット上を常にスキャンし、このような「宛先を失って宙ぶらりんになったCNAMEレコード」を探しています。そして、その宛先と同じ名前で新しいクラウドサービスを契約しさえすれば、DNSの設定上、そのサブドメインへのアクセスはすべて攻撃者が用意したサーバーへと向かうことになります。これが、サブドメイン乗っ取りの基本的な仕組みです。

go.jpドメインでの事件を受け、日本のドメイン登録管理組織であるJPRS（日本レジストリサービス）は、直ちに技術的な解説と対策に関する注意喚起を発表しました。そこでは、サービス終了時にDNS設定、特にCNAMEレコードや、子会社や関連組織に委任していたNSレコードの削除を徹底することの重要性が改めて強調されました。これまでDNSの設定管理は、一部の技術専門家の間での課題と認識されがちでしたが、この一件を機に、企業の広報や経営層までもが無視できない、事業継続に関わる重大なリスク管理マターとして認識されるようになったのです。技術的な設定ミスという小さな綻びが、組織全体の信頼を根底から揺るがしかねないという厳しい現実が、白日の下に晒された瞬間でした。

世界で「産業化」する乗っ取り攻撃――巧妙化する手口とその実態

日本での事件がDNS運用の見直しを促す警鐘となった一方で、海外ではサブドメイン乗っ取りはすでに「産業化」の様相を呈しています。攻撃者は、これを一過性のいたずらではなく、継続的な収益源として確立しようと活動を活発化させているのです。2025年春、セキュリティ企業のInfobloxは、「Hazy Hawk」と名付けられた攻撃者グループの活動を報告しました。彼らは、組織が放置したクラウド資産に向けられたダングリングDNSを体系的に探し出し、米疾病対策センター（CDC）のような公的機関や、Bose、Panasonic、Deloitteといった世界的に著名な大企業のサブドメインを次々と乗っ取り、マルウェアの配布や悪質なスパムサイトへの誘導に利用していました。この攻撃手法の厄介な点は、サーバーへの不正侵入のような派手な痕跡を残さないことです。攻撃者はただ、正規の運用プロセスからこぼれ落ちた「運用のほころび」を突くだけで、正規ドメインの権威を悪用できてしまいます。そのため、被害組織側での検知が遅れがちになり、気づいた頃にはブランドイメージが大きく傷つけられているという事態に陥りやすいのです。

このような攻撃は、もはや単に偽のウェブサイトを公開するだけには留まりません。近年の攻撃者は、TDS（Site visitors Distribution System）と呼ばれる仕組みを組み合わせ、アクセスしてきたユーザーの地域やデバイス、OSなどの情報に応じて、表示するコンテンツを動的に切り替えます。あるユーザーにはフィッシングサイトを、別のユーザーにはマルウェアをダウンロードさせるサイトを見せるなど、効果を最大化するよう最適化されているのです。さらに、ウェブサイト訪問時に表示される「通知を許可しますか？」というポップアップを悪用し、一度許可してしまったユーザーに対して、その後も持続的に偽の警告や詐欺的な広告を送り続けるといった手口も横行しています。表面上は「○○社の公式サイト」という信頼性の高い顔をしていながら、その裏側では、攻撃者が自由に使い捨てるためのインフラとして機能し、広告配信ネットワークなどを介して被害はネズミ算式に拡大していきます。

クラウドコンピューティングの普及が、この問題に拍車をかけている側面も無視できません。AWS S3、GitHub Pages、Heroku、各種CDN（コンテンツデリバリネットワーク）といったサービスは、誰でも手軽にウェブサイトやアプリケーションを公開できる利便性を提供します。その利便性を支えているのが、柔軟なCNAMEレコードの運用です。しかし、この手軽さが仇となり、「とりあえず作って、終わったら消し忘れる」という事態を誘発しやすくなっています。セキュリティ研究者のコミュニティでは、どのクラウドサービスのどのような設定状態であれば乗っ取りが可能か、という知見が「can-i-take-over-xyz」のような公開リポジトリに蓄積されており、攻撃者にとっても格好の参考情報となっています。利便性とリスクは常に表裏一体であり、クラウド時代の恩恵を安全に享受するためには、その光と影を正しく理解することが不可欠なのです。

脅威の連鎖を断ち切るために――今、組織が取り組むべき対策とは

サブドメイン乗っ取りという脅威の根は、突き詰めれば「ライフサイクル管理の失敗」という非常にシンプルな問題に行き着きます。プロジェクトの開始、クラウドサービスの導入、ウェブサイトの公開といった「始まり」には多くの時間と注意が払われる一方で、プロジェクトの終了、サービスの解約、サイトの閉鎖といった「終わり」の手続きは、しばしば軽視されがちです。このギャップこそが、攻撃者に付け入る隙を与えてしまうのです。この脅威の連鎖を断ち切るためには、「技術的な設定」と「組織的な運用習慣」の両面から対策を講じ、それを組織文化として根付かせる必要があります。

まず、技術的な対策としては、各クラウドプラットフォームが提供している「なりすまし防止機能」を正しく活用することが挙げられます。例えば、Microsoft AzureのApp Serviceでは、ドメインの所有権を確認するために「asuid」という固有のIDを含んだTXTレコードをDNSに設定する仕組みがあります。このTXTレコードが存在する限り、たとえCNAMEレコードが残っていても、第三者が同じ名前でサービスを立ち上げてドメインを乗っ取ることをブロックできます。これは、万が一DNSレコードを消し忘れてしまった場合の、最後のセーフティネットとして機能します。すべてのプラットフォームが完璧な保護機能を提供しているわけではありませんが、利用するサービスの仕様を正しく理解し、推奨されるセキュリティ設定を施すことは、防御の第一歩として極めて重要です。

しかし、より本質的で重要なのは、組織的な運用習慣の見直しです。具体的には、サービスやプロジェクトを終了する際の公式な手順書、いわゆる「退役手順書（Runbook）」の中に、「関連する全DNSレコードの削除」を必須のチェック項目として明記し、実行を義務付けることです。そして、その手続きが徹底されているかを、変更管理プロセスの中で確実に監査する体制を整えなければなりません。さらに、人間の注意力には限界があることを前提に、定期的に自社の管理するドメイン全体を自動スキャンし、ダングリングDNSの兆候がないかを洗い出す仕組みを導入することが望ましいでしょう。近年では、EASM（外部攻撃対象領域管理）と呼ばれるソリューションも登場しており、こうしたツールは自社の気づいていないIT資産や、今回のような設定不備を自動的に検知するのに役立ちます。

最終的に最も重要なのは、組織の壁を越えた連携です。ドメイン名の管理を担当する情報システム部門、クラウドサービスを契約・利用する事業部門や開発部門、そしてアプリケーションのライフサイクルを管理するチーム。これらの担当者が縦割りで業務を進めている限り、資産のライフサイクル全体を見通すことは困難です。ドメインという会社の「表札」を誰が管理し、その「表札」がどの「家」（クラウド資産）を指しているのか、そしてその「家」がいつ取り壊されるのか。この一連の流れを一元的に把握し、それぞれの責任者が連携して管理する文化を醸成することこそが、サブドメイン乗っ取りという脅威に対する最も強力な対抗策となります。この脅威は、特定の製品の脆弱性ではなく、私たちの「運用文化」そのものに潜んでいます。プロジェクトの「始まり」にかけるのと同じだけの情熱と規律をもって「終わり」を設計し、管理しきること。それこそが、最小のコストで最大のセキュリティ効果を生む、確実な道筋と言えるでしょう。