ドメイン調査の全体像

ドメインとDNSの調査は、標的のインターネットインフラを把握するための基本的なOSINT手法です。標的に直接接触せずに実施できる**受動偵察（パッシブ偵察）**の代表例であり、ペネトレーションテストの偵察フェーズでは必ず実施します。

ドメイン調査で得られる情報は、「どのサービスを使っているか」「どこにインフラがあるか」「どんな技術スタックか」という問いに直接答えてくれます。

WHOIS 調査

WHOISはドメイン登録情報を公開するプロトコルです。登録者の連絡先・登録日・更新日・ネームサーバーなどが確認できます。ドメイン調査の出発点として最初に実行する手法です。

# コマンドライン

whois example.com

# 主な取得情報

# Domain Name: EXAMPLE.COM

# Registrar: Example Registrar, Inc.

# Creation Date: 1995-08-14

# Registry Expiry Date: 2026-08-13

# Name Server: NS1.EXAMPLE.COM

# Registrant Organization: Example Corp.

GDPR とプライバシー保護

2018年のGDPR施行以降、多くのドメインでWHOIS情報が「REDACTED FOR PRIVACY」になりました。プライバシー保護サービスの利用が標準化しつつあります。ただし、Internet ArchiveやDomainToolsなどの過去のWHOISデータベースには、プライバシー保護前の情報が残っている場合があります。調査の際はこうした履歴情報を活用するのも一手です。

DNS レコード調査

DNSには複数のレコードタイプがあり、それぞれが組織のインフラについて異なる情報を持っています。TXTレコード1つから、そのサービスがどのクラウドやSaaSを使っているかまで読み取れます。

レコードタイプ用途OSINT での活用
Aドメイン → IPv4Webサーバーのホスト先特定
AAAAドメイン → IPv6同上（IPv6版）
MXメールサーバーメール基盤（Google Workspace、Microsoft 365等）の特定
TXTテキスト情報SPF/DKIM/DMARCポリシー、ドメイン所有確認トークン
CNAMEエイリアスCDNやクラウドサービスの利用状況把握
NSネームサーバーDNS管理者・利用DNSサービスの特定
SOAゾーン権威情報管理者メール、更新頻度

# 基本的なDNS引き当て

dig example.com A dig example.com MX dig example.com TXT dig example.com NS

# すべてのレコードタイプ（全件返ってこない場合もある）

dig example.com ANY

# 特定のDNSサーバーに直接問い合わせ

dig @8.8.8.8 example.com A

# Windows の場合

nslookup -type=MX example.com

TXT レコードから読み取れる情報

example.com. TXT "v=spf1 include:_spf.google.com ~all"

このTXTレコードから次のことがわかります：

  • メールにGoogle Workspace（Google Cloud）を使っていること
  • SPFの ~all（ソフトフェイル）設定から、メールセキュリティ設定が緩めであること

また _dmarc.example.com のTXTレコードを確認すれば、DMARCポリシー（p=none/quarantine/reject）から組織のフィッシング対策の成熟度も読み取れます。

サブドメイン探索

標的組織が運営するサブドメインを発見することで、攻撃対象領域（アタックサーフェス）の全体像が見えてきます。本番環境以外にステージングや開発環境が公開されていることも珍しくありません。

受動的サブドメイン探索（推奨）

# crt.sh — 証明書透明性データベース検索

# ブラウザで以下のURLにアクセス

# https://crt.sh/?q=%.example.com

# APIとして使用（jqコマンドが必要）

curl -s “https://crt.sh/?q=%.example.com&output=json” | jq ’.[].name_value’ | sort -u

CT Logとは

証明書透明性（Certificate Transparency）ログは、発行されたすべてのTLS証明書の公開記録です。ブラウザがCA（認証局）を信頼するための仕組みの一部として義務付けられており、結果的に全証明書が公開データベースに記録されます。crt.shで組織のドメインを検索すると、公式サイトに掲載されていない内部向けサービスやサブドメインが見つかることがあります。

DNSゾーン転送の試みと対策

# 設定ミスのあるDNSサーバーではゾーン転送が可能な場合がある

# 自組織の確認のみに使用すること

dig axfr example.com @ns1.example.com

# 正しく設定されていれば以下のエラーが返る

# ; Transfer failed.

DNSゾーン転送はセカンダリDNSサーバーがプライマリからゾーン情報を同期するための機能です。設定ミスで外部からゾーン転送が可能になると、ドメイン内のすべてのホスト名が一括で取得できてしまいます。対策はDNSサーバーでゾーン転送を許可するIPをセカンダリDNSのみに制限することです。

IP/ASN 調査

ドメインのIPアドレスが判明したら、そのIPが属するASN（自律システム番号）を確認します。ASN単位で調べると、組織が保有するIPアドレスの範囲全体が把握できます。

# IPアドレスのASN・組織情報を確認

whois 93.184.216.34

# ipinfo.io でも確認可能（JSON形式）

curl ipinfo.io/93.184.216.34

ASN情報からわかること：

  • 組織が利用するIPレンジ全体（CIDR）
  • クラウドプロバイダー（AWS、Azure、GCP）の利用有無
  • オンプレミスとクラウドの比率

たとえばAWSのIPレンジを使っていればEC2インスタンスの可能性が高く、Cloudflareのレンジであれば実際のオリジンIPが隠蔽されていると推測できます。

理解度チェック

TLS証明書の透明性ログ（CT Log）を検索することで何が分かりますか？