SC午後の記述式は、攻撃手法の名前を覚えていれば解けるものではありません。事例の中に散らばった「誰が、いつ、何をやめたのか」という運用上の事実を拾い集め、そこに残ってしまった穴を自分の言葉で説明できて初めて点になります。シリーズ第4弾は、令和7年度 春期（2025年4月）SC午後 問4のテーマであるIT資産管理と脆弱性管理、そのなかでも「使わなくなったのに消し忘れたもの」が攻撃に使われる構図を扱います。
中心となる論点は2つです。ひとつはサブドメインテイクオーバー（ダングリングDNSレコードの悪用）、もうひとつは公開放置Webサーバ（公開されたまま放置されたWebサーバ）の悪用です。どちらも新しい脆弱性を突く攻撃ではなく、「やめたはずのものが、やめきれていない」という運用の穴を突く攻撃です。だからこそ、午後問題では手を動かしている人ほど強く、机上の暗記だけの人ほど失点します。
なお本記事は、IPAの過去問本文を転載していません。テーマと問われる論点だけを踏襲し、登場する企業・システム・ドメイン名はすべて架空のものに置き換えています。ドメイン名は example.jp、IPアドレスはRFC 5737のドキュメント用アドレス（203.0.113.0/24）を使います。
事例シナリオ：アパレル企業で消し忘れられた2つの資産
登場する企業とシステム
W社は全国に店舗を持つ中堅アパレル企業です。コーポレートサイトとオンラインストアを自社で運営しており、コーポレートドメインとして example.jp を使っています。
W社の公開IT資産は、大きく3か所に分かれています。
- W社DMZ：コーポレートサイト（
www.example.jp）と、その前段のロードバランサ。グローバルIPは203.0.113.10。 - クラウド環境：オンラインストア（
shop.example.jp）。会員のログイン機能があり、セッションCookieを発行しています。 - 外部サービス：各事業部が個別に契約した、キャンペーン用のCDNサービスやマーケティング支援SaaS。
W社の権威DNSサーバはドメイン登録事業者が提供するマネージドサービスを利用しており、ゾーンの編集権限は情報システム部の3名が持っています。ただし、実際のレコード追加依頼は各事業部からメールで届き、依頼のたびに追記されてきました。
ここが最初の伏線です。レコードを追加する運用ルールはあるのに、削除する運用ルールがないという状態でした。
伏線1：2年前に解約したキャンペーン用CDN
2年前、W社の販売促進部は季節キャンペーンのランディングページを外部CDN事業者のサービス上に構築しました。このとき情報システム部に依頼して、権威DNSサーバに次のレコードを追加しています。
text campaign.example.jp. IN CNAME wXXXXX.cdn-provider.example.net.
キャンペーンは3か月で終了し、販売促進部はCDN事業者との契約を解約しました。CDN事業者側のアカウントは閉じられ、wXXXXX.cdn-provider.example.net というホスト名も解放されました。
しかし、権威DNSサーバのCNAMEレコードは削除されませんでした。販売促進部は「契約を切ったから終わり」と考え、情報システム部は「削除依頼が来ていないから残す」と考えていたためです。
その結果、campaign.example.jp を名前解決すると wXXXXX.cdn-provider.example.net へ辿り着き、そこが存在しないため名前解決に失敗する、という宙ぶらりんの状態になりました。これがダングリングDNSレコード（宙づりのDNSレコード）です。
伏線2：廃止したはずのアンケートサーバ
同じ頃、W社DMZには店舗アンケート用のWebサーバ（203.0.113.20）が置かれていました。オープンソースのCMSで構築され、enquete.example.jp というAレコードが割り当てられていました。
アンケート業務はクラウドのフォームサービスに移行することが決まり、担当者は移行完了後に「サーバは停止した」と口頭で報告しました。実際には、アプリケーションのサービスを停止しただけで、OSとWebサーバのプロセスは動いたままでした。ファイアウォールのポート443の許可ルールも残り、IT資産管理台帳では「廃止済み」に更新されていました。
CMSのバージョンは移行時点のまま止まり、その後に公表された任意コード実行の脆弱性に対するパッチは、当然ながら適用されていません。台帳上は存在しないサーバなので、月次の脆弱性スキャンの対象リストにも入っていませんでした。
攻撃の発端
その後しばらくして、攻撃者は example.jp を対象に調査を始めました。手口は特殊なものではありません。
- 証明書透明性（Certificate Transparency）ログの検索サービスで、
example.jpに対して過去に発行された証明書を一覧し、サブドメイン名を収集する。 - 収集したサブドメインを片端から名前解決し、CNAMEの参照先が存在しないものを探す。
- 名前解決できたものについては、TCP 443番ポートに接続してレスポンスヘッダとコンテンツを取得し、ソフトウェアとバージョンを推定する。
この調査で、攻撃者は campaign.example.jp がCDN事業者のホスト名を指したまま宙づりになっていること、そして enquete.example.jp が古いCMSで応答し続けていることを、いずれも外部から無認証で把握しました。
サブドメインテイクオーバーの成立
攻撃者は同じCDN事業者に自分のアカウントを作り、解放済みだったホスト名 wXXXXX.cdn-provider.example.net を再取得しました。多くのクラウド・CDNサービスでは、ホスト名やエンドポイント名は解約後に解放され、先着順で誰でも再取得できます。
この瞬間、campaign.example.jp の名前解決は復活しました。ただし、その先にあるコンテンツはW社のものではなく、攻撃者が用意したものです。利用者から見れば、ブラウザのアドレスバーには紛れもなくW社のドメイン名が表示されます。
攻撃者はさらに、このサブドメインの制御権を使ってACME（証明書の自動発行に使われるプロトコル）のHTTP-01チャレンジを通し、campaign.example.jp に対する正規のDV証明書を無料の認証局から取得しました。ブラウザには鍵マークが表示され、警告は一切出ません。
被害の拡大
攻撃者は乗っ取った campaign.example.jp に、オンラインストアのログイン画面を模したページを設置しました。
被害は3方向に広がりました。
1つ目はセッションCookieの窃取です。W社のオンラインストアは、会員向けセッションCookieを Domain=example.jp で発行していました。この属性が付いたCookieは、example.jp 配下のすべてのサブドメインへのリクエストに自動で付与されます。HttpOnly属性が付いていてもJavaScriptから読めないだけで、ブラウザはリクエストヘッダに載せて送信します。つまり、ログイン中の会員が乗っ取られたサブドメインを一度開くだけで、攻撃者のサーバにセッションCookieが届きました。
2つ目はフィッシングの信頼性向上です。メール本文中のリンクが自社ドメインであるため、利用者も、社内のメールフィルタも疑いにくくなります。W社の社内プロキシは *.example.jp を無条件許可する設定になっており、社内からのアクセスも素通りしました。
3つ目は放置サーバ経由の侵入です。攻撃者は enquete.example.jp の古いCMSに対して、公表済みの任意コード実行の脆弱性を突くリクエストを送り、Webサーバの実行権限でシェルを取得しました。このサーバはDMZに置かれ、運用の都合で社内の資産管理セグメントへの通信が許可されたままだったため、攻撃者はここを踏み台として内部偵察を開始しました。
発覚のきっかけは、会員からの「キャンペーンページのログイン画面でログインできない」という問い合わせでした。販売促進部は「2年前に終わったキャンペーンのページは存在しないはず」と回答しようとして、実際にアクセスしてみて異常に気づきます。
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
設問
事例を踏まえて、次の設問に記述で答えてください。実際の午後問題と同じように、要点を絞って短くまとめることを意識してください。
設問1
campaign.example.jp が攻撃者に乗っ取られた原因となったDNSの状態を答えてください。あわせて、この攻撃を防ぐためにどのサーバの設定をどのように変更すべきだったかを述べてください。
設問2
乗っ取られたサブドメインが、W社のオンラインストア利用者のセッションCookieの窃取につながった理由を、Cookieの属性に触れて説明してください。
設問3(1)
外部サービスの利用を終了する際、DNSレコードの削除と外部サービス側のリソースの解放は、どちらを先に実施すべきか答え、その理由を述べてください。
設問3(2)
enquete.example.jp のように、台帳上は廃止済みでありながら公開され続けている資産を継続的に検出するための施策を、3つ挙げてください。
回答例
記述式の模範解答は、事実を漏らさず、かつ冗長にしないのが肝心です。以下は要点を押さえた解答例です。
設問1の回答例
原因：CDNサービス解約後も、解放済みのホスト名を参照するCNAMEレコードが削除されずに残っていたため、攻撃者が同じホスト名を再取得することで正規のサブドメイン名で自身のコンテンツを配信できた。
対策：権威DNSサーバの設定を変更し、利用を終了したサブドメインのCNAMEレコードを削除する。
設問2の回答例
オンラインストアのセッションCookieがDomain属性に
example.jpを指定して発行されており、配下の全サブドメインへのリクエストに自動送信されるため。乗っ取られたcampaign.example.jpに利用者がアクセスした時点で、攻撃者のサーバにCookieが送信された。
設問3(1)の回答例
DNSレコードの削除を先に実施すべきである。外部サービス側のリソースを先に解放すると、その時点からDNSレコードが宙づりになり、第三者が同名のリソースを取得できる状態が生じるため。
設問3(2)の回答例
1. 権威DNSサーバのゾーン情報を定期的に棚卸しし、参照先が存在しないCNAMEレコードや、応答のないAレコードを抽出する。
2. 自社ドメインに対する証明書透明性ログを監視し、台帳に存在しないサブドメイン名の証明書発行を検知する。
3. 外部から自社の割当IPアドレス範囲と全サブドメインに対して定期的にポートスキャンを実施し、結果とIT資産管理台帳を突合する。
採点ポイント
ここが本シリーズの肝です。同じ趣旨を書いても、要点に触れているかどうかで部分点が大きく変わります。
加点される要点
- 設問1のサーバ名：<strong>「権威DNSサーバ」</strong>と書けているかが最大の分岐点です。単に「DNSサーバ」と書くと、キャッシュDNSサーバとの区別がついていないと判断されて減点される可能性があります。外部からの名前解決に応答するのは権威DNSサーバ（コンテンツサーバ）、社内端末の問い合わせを代行するのがキャッシュDNSサーバ（フルサービスリゾルバ）です。この切り分けは午後で頻出なので、DNSの仕組みと脅威の解説記事で役割の違いを固めておくと安全です。
- 設問1の因果：「レコードが残っていた」だけでは半分です。<strong>「参照先のホスト名が第三者に再取得可能だった」</strong>という、攻撃が成立する側の条件までセットで書けると満点に近づきます。ダングリングDNSレコードは、残っているだけでは単なる名前解決エラーであり、参照先を誰かが取得できて初めて攻撃になります。
- 設問2のCookie属性：<strong>「Domain属性」</strong>という語を明示することです。「サブドメインが同じドメインだから」という書き方では、なぜブラウザがCookieを送るのかという機構の説明になっていません。Domain属性を指定したCookieは、そのドメインと配下のサブドメインすべてに送信される、という仕様に踏み込みます。
- 設問3(1)の順序と理由：「DNSが先」という結論だけでなく、<strong>「逆順だと宙づりの時間帯が発生する」</strong>という理由を書くことです。理由側に配点があります。
- 設問3(2)の多面性：3つ挙げるとき、すべてを「棚卸しする」で埋めないことです。DNS側（ゾーン点検）、証明書側（CTログ監視）、ネットワーク側（外部スキャン）と観測点を変えると、多層の検出という意図が伝わります。
よくある減点・失点パターン
- 「DNSレコードを消す」だけで対象サーバを書かない：設問が「どのサーバの設定を」と聞いている以上、サーバ名は必須の得点要素です。設問文が要求している要素の数と、自分の解答に含まれる要素の数を、書き終えてから数える癖をつけてください。
- サブドメインテイクオーバーをDNSキャッシュポイズニングと混同する：これは学び始めの人が最も陥りやすい罠です。キャッシュポイズニングはキャッシュDNSサーバに偽の応答を覚え込ませる攻撃で、権威DNSサーバの正しいレコードは書き換わりません。一方、サブドメインテイクオーバーでは権威DNSサーバの正しいレコードがそのまま使われ、その参照先が攻撃者のものに変わっただけです。応答自体は正当なので、DNSSECで署名検証しても防げません。この点は設問で理由を問われやすいところです。
- 「HTTPSだから安全」と書いてしまう：攻撃者はサブドメインの制御権を握っているため、HTTP-01のドメイン検証を正規に通過して有効な証明書を取得できます。暗号化されていることと、通信相手が正しいことは別の話です。証明書の検証範囲についてはX.509証明書の構造と検証の記事が参考になります。
- 対策を「教育の徹底」で締める：利用者教育は、アドレスバーが正規ドメインである以上ほとんど効きません。設問が技術的・手続き的な対策を求めているときに運用精神論を書くと、点になりません。
字数調整のコツ
設問1のように「原因＋対策」を求められる場合、40字前後の指定なら原因を1節、対策を1節に圧縮します。「解約済みサービスを指すCNAMEが残存していたから」「権威DNSサーバの当該CNAMEを削除する」のように、修飾を削って主語と動詞だけにすると収まります。逆に字数に余裕があるときは、因果の接続詞（〜のため、〜によって）を明示して論理の筋を見せると採点者に伝わりやすくなります。
頻出パターン
このテーマは形を変えて繰り返し出題されます。出題の型を知っておくと、初見の事例でも当てに行けます。
レコード種別の識別を問う型
「どのレコードを削除すべきか」「どのレコードが悪用されたか」を問う型です。CNAMEはホスト名の別名を示すレコードで、外部サービス利用時に典型的に使われます。一方、Aレコードの残置も同種の危険があります。クラウドで確保していたグローバルIPアドレスを解放すると、そのIPは事業者のプールに戻り、別の契約者に再割り当てされます。Aレコードを消し忘れれば、自社のサブドメインが見知らぬ第三者のサーバを指すことになります。CNAMEの話だと決めつけず、事例に出てくるレコード種別を必ず確認してください。
NSレコードの委譲先ドメインが失効しているケースも同じ構図です。委譲先のドメイン名が第三者に取得されると、そのゾーン全体の名前解決を乗っ取られます。
名前解決の主体を問う型
「対策すべきサーバはどれか」という問い方です。権威DNSサーバとキャッシュDNSサーバ、社内DNSと外部公開DNSの役割分担を、構成図から読み取らせる出題が定番です。図にサーバが複数描かれているときは、どの通信の名前解決を担っているのかを線で追ってから答えると間違えません。
廃止手順の順序を問う型
「作業手順のうち、順序を入れ替えるべきものはどれか」という型です。セキュリティの実務では、公開をやめる作業は外側から内側へが原則です。具体的には、DNSレコードの削除、ロードバランサやリバースプロキシからの切り離し、ファイアウォールの許可ルール削除、サーバの停止、ストレージ・アカウントの削除、台帳の更新という順序になります。逆順にすると、外から見えているのに中身が無い、あるいは中身が無防備という状態が必ず生まれます。
資産の可視化手段を問う型
「未把握の公開資産をどう見つけるか」という型です。解答の引き出しとして、権威DNSのゾーン点検、証明書透明性ログの監視、外部からのポートスキャンとサービス列挙、登録ドメイン一覧と契約情報の突合、クラウド事業者のAPIによるリソース棚卸しを持っておくと、3つ挙げよという設問に困りません。これらを組織的に回す取り組みは、近年ではASM（Attack Surface Management、一般に「攻撃対象領域管理」と訳されます）と呼ばれます。経済産業省のASM導入ガイダンスは、その対象を「組織の外部（インターネット）からアクセス可能なIT資産」と定義しています。台帳運用の考え方はパッチ管理とIT資産管理の記事、スキャナの仕組みはWebアプリケーション脆弱性スキャナの記事でも扱っています。
ドメイン名そのものの手放し方を問う型
サブドメインではなく、ドメイン名ごと使わなくなるケースです。キャンペーン専用ドメインやブランド統合で不要になったドメインを更新せずに失効させると、第三者が取得して過去のリンク資産ごと悪用します。放棄するドメインで運用していたメールアドレスが残っていれば、パスワードリセットの受信さえ奪われかねません。ドメインを手放す前に、そのドメインで発行していたメールアドレスの棚卸し、SPF・DKIM・DMARCレコードの状態確認、外部サービスの登録変更を済ませる必要があります。メール認証まわりの前提はSPF・DKIM・DMARCの解説記事にまとめています。DNSを含むプロトコル横断の弱点整理はプロトコル脆弱性の総まとめ記事が近道です。
この事例が実務と直結する理由
社内システムを預かる立場で一番やっかいなのは、「誰も覚えていない資産」です。稼働中のシステムには担当者がいて、障害が起きれば電話が鳴ります。しかし、役目を終えた仕組みには担当者がいません。鳴らない電話は、安全の証明ではないのです。この事例で問われているのは攻撃手法の知識ではなく、やめる作業にも手順書と承認が要るという運用設計の話です。だからこそ午後問題で問われ、現場でも繰り返し起きています。
まとめ：やめる作業こそ手順化する
令和7年春 午後 問4のテーマを架空事例に置き換えて追いかけてきました。押さえるべき骨格を整理します。
- ダングリングDNSレコードは、残っていることと参照先が第三者に取得可能であることの2条件で攻撃になる。
- 外部からの名前解決に応答するのは権威DNSサーバであり、対策対象を問われたらここを明示する。
- サブドメインテイクオーバーは正規のレコードがそのまま使われるため、DNSSECでも防げず、正規の証明書も取得されうる。
- Domain属性付きCookieは配下の全サブドメインに送られるため、サブドメイン1つの乗っ取りがセッション窃取に直結する。対策としては、Domain属性を付けないホストオンリーCookieにする、
__Host-プレフィックスを付ける、重要なサービスを別ドメインに分離する、といった選択肢がある。 - 廃止作業はDNSレコードの削除を先に、外側から内側へ順に実施する。
- 未把握の公開資産は、ゾーン点検・証明書透明性ログ・外部スキャンという観測点の異なる手段を重ねて洗い出す。
学習の仕上げとして、自分の関わっているシステムのドメイン名を1つ選び、そのゾーンにどんなレコードが何本あるか、参照先が全部生きているかを確かめてみてください。事例が一気に自分ごとになり、記述の言葉も自然と具体的になります。
参考資料
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
