> **結論:** 使わなくなった外部サービス（GitHub Pages / Heroku / S3 など）向けの CNAME レコードを消し忘れて残す（dangling CNAME = 宙ぶらりん CNAME）と、攻撃者が同名リソースを再取得して御社のサブドメインで偽サイトを配信できてしまいます。これがサブドメインテイクオーバーです。対処はシンプルで、不要になった CNAME を DNS から削除することです（OWASP Web Security Testing Guide）。

## この記事でわかること

- サブドメインテイクオーバー（subdomain takeover）の仕組み
- なぜ dangling CNAME が踏み台になるのか
- 現場で起きやすい状況と実害
- 棚卸しと是正の進め方

## サブドメインテイクオーバーとは

![サブドメインテイクオーバーの仕組み図](/blog/subdomain-takeover-toha/takeover-mechanism.svg)

社内で過去に **GitHub Pages / Heroku / AWS S3 / Vercel / Netlify** などの SaaS を試したサブドメインを、利用停止後に CNAME を消し忘れたまま放置している状態を **dangling CNAME**（宙ぶらりん CNAME）と呼びます。

このとき、攻撃者が同じ SaaS で同名のリソースを再取得すると、**御社のサブドメイン経由で攻撃者のサイトが配信される**ようになります。これが「サブドメインテイクオーバー（乗っ取り）」です。

```
顧客のブラウザ
   ↓
campaign.example.co.jp（御社の DNS は CNAME → old-app.herokuapp.com）
   ↓
old-app.herokuapp.com ← 攻撃者が解約済リソース名を再取得
   ↓
攻撃者のフィッシングサイトが御社のドメインで表示される
```

## なぜ「御社のドメイン」で攻撃が成立するのか

ブラウザのアドレスバーに表示されるのは、最初にアクセスした **御社のサブドメイン**です。CNAME は内部的な転送なので、エンドユーザーには見えません。

その結果:

- 御社のドメイン名で偽の請求書ページや偽のログインフォームが配信できる
- HTTPS 通信は **攻撃者が SaaS 側で取得した正規証明書** で成立するので、ブラウザの鍵マークも付く
- メールフィルタや URL フィルタは「御社のドメイン = 信頼できる」と判定する

## 現場で起きやすい状況

![EC・スタートアップで dangling CNAME が生まれる典型的な状況](/blog/subdomain-takeover-toha/typical-scenarios.svg)

### 1. 退職者が立てた検証環境
過去に開発担当者が `staging.` `dev.` `app.` で SaaS を試して、退職時に DNS の整理を忘れた。

### 2. 解約済 SaaS の残骸
過去にキャンペーンで使った Vercel / Netlify を 1 年で解約したのに、CNAME を消し忘れた。

### 3. 部門ごとの shadow IT
営業部・マーケ部が個別に SaaS を契約・解約しており、情シスが全体を把握していない。

### 4. M&A 後のドメイン整理漏れ
吸収合併後にドメインだけを引き継いだが、過去のサブドメイン群の状況が分からない。

## 想定される実害

| シナリオ | 実害 |
|---|---|
| フィッシングサイト配信 | 御社のドメインで偽ログイン画面が表示され、顧客の認証情報が盗まれる |
| なりすまし請求書 | 御社のドメインから偽請求書 PDF が配信され、取引先が振り込み詐欺に遭う |
| ブランド毀損 | 攻撃者が悪意ある内容を御社ドメインで公開、SNS 拡散 |
| メール認証の悪用 | DMARC / SPF が御社ドメイン基準で評価され、迷惑メール扱いされにくい |

## 棚卸しと是正の進め方

### 1. 全サブドメインを洗い出す

CT log（証明書透明性）から過去〜現在の全証明書を辿るのが最も確実です。crt.sh / CertSpotter で `%.example.co.jp` 検索が基本。詳細は [CT log でサブドメインを列挙する方法](/blog/ct-log-subdomain-enumeration) を参照。

### 2. 各サブドメインの状態を確認

- DNS の解決状況（CNAME チェーン、A / AAAA の有無）
- HTTPS 応答の有無
- CNAME 宛先の SaaS 解約状況

### 3. dangling CNAME を削除

利用停止済の SaaS への CNAME は **DNS から削除**します。SaaS アカウントが残っている場合は、リソース名を**自社で再取得して占有**するのも有効。これは [OWASP Web Security Testing Guide の "Test for Subdomain Takeover"](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover) でも整理されている基本対処です。

### 4. 再発防止

- サブドメイン作成・削除のルール化（誰が・いつ・なぜ）
- 退職時のドメイン整理チェックリスト
- 定期棚卸し（半年〜1 年に 1 回）

詳しくは [Web 担当者向け サブドメイン棚卸しチェックリスト](/blog/subdomain-audit-checklist-smb) を参照してください。

## よくある質問

### サブドメインテイクオーバーはなぜ HTTPS でも防げないのですか？

攻撃者が乗っ取るのは CNAME の宛先となる SaaS リソースであり、そこで攻撃者自身が正規の証明書を取得できるためです。ブラウザのアドレスバーには御社のサブドメインが表示され、鍵マークも付くので、利用者は偽サイトだと気付けません。HTTPS は通信の暗号化を保証するだけで、配信元が正当かどうかは保証しないためです。

### dangling CNAME かどうかはどう確認すればよいですか？

まず CT log（証明書透明性ログ）から過去・現在の全サブドメインを洗い出し、各サブドメインの CNAME 宛先が現在も自社管理下の有効なリソースを指しているかを確認します。宛先の SaaS を解約済みなのに CNAME が残っていれば dangling CNAME です。手順は [CT log でサブドメインを列挙する方法](/blog/ct-log-subdomain-enumeration)を参照してください。

### 対処はどうすればよいですか？

利用停止した SaaS への CNAME レコードを DNS から削除するのが基本です（OWASP も推奨）。SaaS アカウントが残っている場合は、リソース名を自社で再取得して占有する方法も有効です。あわせて、サブドメインの作成・削除ルール化と定期棚卸しで再発を防ぎます。

### 一度確認すれば安心ですか？

いいえ。新しい SaaS の試用や解約は継続的に発生するため、dangling CNAME は時間とともに再び生まれます。半年〜1年に1回の定期棚卸しを推奨します。

## まずは現状を把握しましょう

ドメイン番人の [サブドメイン棚卸し 単発チェック](/subdomain/check) で 30 秒で現状を確認できます。CT log + DNS 解決確認 + 既知 SaaS パターンへの dangling CNAME 検出をまとめてレポートします。

棚卸しと是正対応の支援は [サブドメイン棚卸し＋テイクオーバーリスク診断](/contact)（5 万円〜）でご相談いただけます。

関連記事:
- [dangling CNAME のリスクと検出方法](/blog/dangling-cname-risk)
- [サブドメインテイクオーバーの公開事例 5 選](/blog/subdomain-takeover-cases)
- [シャドー IT サブドメイン棚卸しの実践手順](/blog/shadow-it-subdomain-audit)

総合点検は [無料のドメイン診断](/diagnose)、SSL 単独は [SSL 単発チェック](/ssl/check)、Web セキュリティヘッダは [/security-headers/check](/security-headers/check) をご利用ください。