本サイトは、快適にご利用いただくためにクッキー（Cookie）を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
ここからはドメインやサブドメインを調査する話の後編になります。前編はこちらからどうぞ。
目次
<前編>
・ドメイン・ネットワーク帯を調査する手法
・ドメインの調査
・JPRS whois
・ICANN Registry Listings
・ネットワーク帯（IPアドレス）の調査
・JPNIC whois Gateway
・BGP Tool kit
・その他の調査
・検索エンジンを使った調査
・Webサイトのクローリング
・Google AdSense
・公的データベースの活用
・gBizINFO
・公開情報調査（Passive型の検索サービス）
・Robtex
・PassiveDNS
・viewdns.info
・Microsoft Defender Threat Intelligence
・違うTLDを試す
・RDAP
サブドメインを調査する方法
様々な手法で収集した、ドメインとIPアドレス情報をもとにサブドメインを列挙するフェーズです。ドメイン/ネットワーク帯（IPアドレス）調査と同じく、相手方に影響を与えない縛りでできることに絞っていますので、辞書などを使ったブルートフォースやDNS Zone walkingのようにクエリを繰り返すような手法や、パッシブ系のツールももありますが、ツール（AmassとかSublist3rとかrecon-ngとか）を実行するだけというものは除外しています。
IPアドレスを起点にサブドメインを探す
まずは、IPアドレスを起点にしてサブドメインを探す方法について触れてみます。
・IPアドレスを起点にサブドメインを探す
・公開ポートへのアクセス（Webポート）
・＜通常コンテンツの返却＞
・＜エラーページの返却＞
・＜リダイレクト＞
・公開ポートへのアクセス（Webポート以外）
・証明書の確認
・＜Webサーバの場合＞
・＜SSL/TLSで保護されたプロトコルの場合＞
・＜プロトコル内で暗号化(STARTTLS)の場合＞
・PTRレコード
・公開情報を用いた調査（Passive型の検索エンジン）
・＜Robtex＞
・＜BGP Toolkit＞
・＜Spyonweb＞
・＜Microsoft Defender Threat Intelligence＞
・＜Shodan＞
・＜Censys＞
・＜Bing search＞
公開ポートへのアクセス（Webポート）
通常のユーザが使用するのと同じように、公開しているポート（サービス）に対してIPアドレスで接続することで、サブドメイン（FQDN）の情報を得られる可能性があります。例えばWebポートであれば、ブラウザでHTTPのレスポンスを確認することで、サブドメインを得られる可能性があります。
＜通常コンテンツの返却＞
バーチャルホストなどの設定次第ではありますが、https://<IPアドレス>/ のようにIPで接続した際、FQDNが指定されたコンテンツと同じコンテンツを返すケースがあります。（例えばApache HTTP Serverであれば、configでVirtualHost *:80のように*で指定する場合、configの一番先頭にある記述が優先されるためIPアクセスとFQDNでのアクセスで同じコンテンツが返るケースが出てきます）
こういったケースの場合、HTTP Body内にある、リンクやリソースなどを取得するURLがIPのままのケースまたはFQDNに置き換わって返されるケースが多くありますので、こちらからサブドメインを取得できる可能性があります。
なお、こういった挙動はApacheに限らず、NginxなどのWebサーバやリバースプロキシ、Tomcatのようなミドルウェアの設定による場合が多く、FQDNを確認するための有効な確認方法の1つになります。
■IPのままのケースの例
# curl -iks https://192.0.2.1/
HTTP/2 200
date: Tue, 01 Aug 2023 06:08:48 GMT
content-type: text/html; charset=UTF-8
link: <https://192.0.2.1/wp-json/>; rel="https://api.w.org/"
vary: Accept-Encoding
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="format-detection" content="telephone=no" />
<link rel="icon" href="https://192.0.2.1/wp-content/themes/mytheme/assets/favicon.ico" />
(..snip..)
■FQDNに置き換わって出力される例
# curl -iks https://192.0.2.2/
HTTP/2 200
date: Tue, 01 Aug 2023 06:08:48 GMT
content-type: text/html; charset=UTF-8
link: <https://www.example.com/wp-json/>; rel="https://api.w.org/"
vary: Accept-Encoding
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="format-detection" content="telephone=no" />
<link rel="icon" href="https://www.example.com/wp-content/themes/mytheme/assets/favicon.ico" />
(..snip..)
また、返却されるコンテンツに埋め込まれるURLなどがIPアドレスで返ってくるようなケースでも、Set-Cookieのdomain属性が指定されているとサブドメインを入手できる可能性がありますし、CORSのレスポンスヘッダ（Access-Control-Allow-Origin）からも入手できる可能性があります。
■Set-Cookieの例
Set-Cookie: test_cookie=test; expires=Fri, 28-Jul-2023 04:13:00 GMT; path=/; domain=.example.com; Secure; SameSite=none
■Set-Cookieの例
Access-Control-Allow-Origin: https://www.example.com
特にWebポートの場合は設定等に依存する部分が多くあるため、返却されるコンテンツを注意深く観察してみることが大切です。
＜エラーページの返却＞
エラーページのコードや設定、WAFなどの有無により変化しますが、例えばApacheでServerSignatureの設定がOnになっているケースであれば、403 Forbiddenや400 Bad Requestの画面のフッターなどにサブドメイン（厳密にはServerNameで指定されたホスト名）が表示されるケースがあります。とはいえ、意図的にエラーページを出すためには、少しイレギュラーなリクエストが必要となります。
エラーページのフッターに表示される場合
また、IPアドレスが表示されるケースでも、HTTP/1.0のホストヘッダなしのリクエストを送ることで、表示されると言ったこともあります。なお、Apacheであればエラーページのテンプレートが用意されており、一部ディストリビューションでは以下のようなURLにアクセスすることで、ドメインやサブドメイン、メールアドレスの情報を取得できる場合もあります。こちらはBad Requestのページですが、200 OKでコンテンツを取得することができます（が、あまりお作法は良くないですね）。
http://192.0.2.1/error/HTTP_BAD_REQUEST.html.varにアクセスした場合
＜リダイレクト＞
こちらも設定次第ですが、IPアドレスでアクセスしたケースにおいて、リダイレクト先に設定されたサブドメイン（FQDN）が返ってくるケースがあります（LocationヘッダやHTTP body内）。親切心からIPへのアクセスをちゃんとしたURLにリダイレクトするケースもあれば、Apacheなどの挙動を使ってリダイレクトさせることで確認できるケースもあります。
■親切心からIPへのアクセスをちゃんとしたURLにリダイレクトするケース
# curl -iks https://192.0.2.1/
HTTP/1.1 302 Found
Content-Type: text/html
Connection: close
Date: Tue, 01 Aug 2023 05:24:55 GMT
Location: https://www.example.com/
■Apacheなどの挙動を使ってリダイレクトさせるケース
# curl -iks https://192.0.2.1/icons/small
HTTP/1.1 301 Moved Permanently
Date: Wed, 02 Aug 2023 18:54:49 GMT
Location: http://www.example.com/icons/small/
Content-Length: 242
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.example.com/icons/small/">here</a>.</p>
</body></html>
上記結果は、URLの末尾の/を削ったアクセスで見られる挙動（ApacheのDirectorySlash設定）を利用したケースで、存在するURLの場合には/を勝手に補って解釈してくれる便利機能です。通常コンテンツの返却で紹介した設定が入った上で、リダイレクトするとServerNameで設定された値を埋め込まれるため、サブドメイン（厳密にはServerNameで指定されたホスト名）を得ることができます。
Bugbounty視点の蛇足ですが、リダイレクトのリクエストにおいて、Hostヘッダを削ったHTTP/1.0でアクセスすると内部のIPアドレスや内部のホスト名が出力されるケースもあり、SSRFのための材料となるケースもあります。
■Hostヘッダを削ってHTTP/1.0でアクセスた場合の例
# curl -iks https://192.0.2.1/icons/small --http1.0 -H "Host:"
HTTP/1.1 301 Moved Permanently
Date: Wed, 02 Aug 2023 18:55:29 GMT
Location: http://10.0.0.1/icons/small/
Content-Length: 242
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://10.0.0.1/icons/small/">here</a>.</p>
</body></html>
こういった挙動は、Apacheに限らず、NginxなどのWebサーバやリバースプロキシ、Tomcatのようなミドルウェアでも確認ができるため有効な確認方法の1つになります。また、上記以外にもリダイレクトを引き起こすケース（コンテンツ削除、移動などにより意図的にリダイレクトさせるケース、80/tcpでのアクセスを443/tcpにリダイレクトさせるケース、Webのフレームワークの仕様でPOSTの後にリダイレクトさせるケースなど）もいくつか考えられますので、同様にサブドメインを取得できる可能性があります。
公開ポートへのアクセス（Webポート以外）
上記はWebサーバでの確認ですが、Webサーバ以外のサーバにおいても、似たような形で確認することができます。プロトコルにもよりますが、接続時にバナーが表示されるケース（FTP/SSH/SMTP/POP3など）であれば、バナーからドメインやサブドメイン（ホスト名）を取得できる場合があります。
■メールサーバ（SMTPサーバ）の場合# nc -v 52.98.83.2 587
Connection to 52.98.83.2 587 port [tcp/submission] succeeded!
220 TYBP286CA0007.outlook.office365.com Microsoft ESMTP MAIL Service ready at Wed, 19 Jul 2023 04:50:21 +0000
なお、例示したケースの場合、内部ホスト名が表示されているもので、実際には外から名前解決できるものではありませんが、有効なドメイン(office365.com)やサブドメイン(outlook.office365.com)が取得できます。
また、相手方に影響を与えない縛りであるため、今回は紹介しませんが、メールをBounceさせるなど、不正な手法も含めればさらに情報が集まるかと思います。また、SMTPやDNS以外のプロトコル（FTP/SSH/POPなど）は、基本的に不特定多数からアクセスを受けることををあまり想定していないと思いますので、接続してバナーを収集する行為も注意して実施する必要があります。（一部の海外のサービスでは日常茶飯事でポートスキャンやBanner Grabbingをやってきていますが…）
証明書の確認
SSL/TLSを提供しているサーバであれば、その証明書を確認することで、サブドメインを取得できる可能性があります。
＜Webサーバの場合＞
Webサーバであればブラウザで、https://<ipアドレス>/にアクセスすることで、証明書の情報を取得できます。IPアドレスでアクセスすると、証明書のCN/SANが不一致となるため、ブラウザで接続エラーの画面が表示されると思います。この画面には、証明書に設定されたCN/SANが表示されますので、ドメインやサブドメインを収集することができます。ただし、ワイルドカード証明書を使用しているケースでは、サブドメインを特定することはできません。
ブラウザの証明書のエラー画面に表示される例
もちろん、opensslのコマンドでも同様に確認することができます。
# openssl s_client -connect 52.98.83.2:443 | openssl x509 -text -noout
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
08:00:94:9f:73:5e:2f:5d:4d:16:ce:19:81:66:77:2c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
Validity
Not Before: May 31 00:00:00 2023 GMT
Not After : May 30 23:59:59 2024 GMT
Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d2:(..snip..):fe:3b:
da:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
DD:51:D0:A2:31:73:A9:73:AE:8F:B4:01:7E:5D:8C:57:CB:9F:F0:F7
X509v3 Subject Key Identifier:
E2:50:F5:3E:70:44:79:BB:10:B6:FB:2C:8B:FC:67:75:36:55:93:2E
X509v3 Subject Alternative Name:
DNS:*.clo.footprintdns.com, DNS:*.hotmail.com, DNS:*.internal.outlook.com, DNS:*.live.com, DNS:*.nrb.footprintdns.com, DNS:*.office.com, DNS:*.office365.com, DNS:*.outlook.com, DNS:*.outlook.office365.com, DNS:attachment.outlook.live.net, DNS:attachment.outlook.office.net, DNS:attachment.outlook.officeppe.net, DNS:attachments.office.net, DNS:attachments-sdf.office.net, DNS:ccs.login.microsoftonline.com, DNS:ccs-sdf.login.microsoftonline.com, DNS:hotmail.com, DNS:mail.services.live.com, DNS:office365.com, DNS:outlook.com, DNS:outlook.office.com, DNS:substrate.office.com, DNS:substrate-sdf.office.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
(..snip..)
＜SSL/TLSで保護されたプロトコルの場合＞
Webサーバ以外の場合は、opensslのコマンドで確認します。SSL/TLSで保護されたプロトコル（SMTPS/IMAPS/FTPSなど）であれば以下のように確認して、サブドメインを取得できます。 # openssl s_client -connect 52.98.83.2:993 | openssl x509 -text -noout
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
08:00:94:9f:73:5e:2f:5d:4d:16:ce:19:81:66:77:2c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
Validity
Not Before: May 31 00:00:00 2023 GMT
Not After : May 30 23:59:59 2024 GMT
Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d2:(..snip..):fe:3b:
da:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
DD:51:D0:A2:31:73:A9:73:AE:8F:B4:01:7E:5D:8C:57:CB:9F:F0:F7
X509v3 Subject Key Identifier:
E2:50:F5:3E:70:44:79:BB:10:B6:FB:2C:8B:FC:67:75:36:55:93:2E
X509v3 Subject Alternative Name:
DNS:*.clo.footprintdns.com, DNS:*.hotmail.com, DNS:*.internal.outlook.com, DNS:*.live.com, DNS:*.nrb.footprintdns.com, DNS:*.office.com, DNS:*.office365.com, DNS:*.outlook.com, DNS:*.outlook.office365.com, DNS:attachment.outlook.live.net, DNS:attachment.outlook.office.net, DNS:attachment.outlook.officeppe.net, DNS:attachments.office.net, DNS:attachments-sdf.office.net, DNS:ccs.login.microsoftonline.com, DNS:ccs-sdf.login.microsoftonline.com, DNS:hotmail.com, DNS:mail.services.live.com, DNS:office365.com, DNS:outlook.com, DNS:outlook.office.com, DNS:substrate.office.com, DNS:substrate-sdf.office.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
(..snip..)
＜プロトコル内で暗号化(STARTTLS)の場合＞
SMTPやFTPなど一部のプロトコルでは、従来平文である通信をSSL/TLSを利用して暗号化通信に切り替える仕組みを持っています。opensslコマンドのオプションに-starttlsをつけることで切り替えて接続ができ、証明書内に含まれるCN/SANを確認することができます。
# openssl s_client -connect 52.98.83.2:587 -starttls smtp | openssl x509 -text -noout
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
verify return:1
250 SMTPUTF8
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
08:00:94:9f:73:5e:2f:5d:4d:16:ce:19:81:66:77:2c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
Validity
Not Before: May 31 00:00:00 2023 GMT
Not After : May 30 23:59:59 2024 GMT
Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d2:(..snip..):da:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
DD:51:D0:A2:31:73:A9:73:AE:8F:B4:01:7E:5D:8C:57:CB:9F:F0:F7
X509v3 Subject Key Identifier:
E2:50:F5:3E:70:44:79:BB:10:B6:FB:2C:8B:FC:67:75:36:55:93:2E
X509v3 Subject Alternative Name:
DNS:*.clo.footprintdns.com, DNS:*.hotmail.com, DNS:*.internal.outlook.com, DNS:*.live.com, DNS:*.nrb.footprintdns.com, DNS:*.office.com, DNS:*.office365.com, DNS:*.outlook.com, DNS:*.outlook.office365.com, DNS:attachment.outlook.live.net, DNS:attachment.outlook.office.net, DNS:attachment.outlook.officeppe.net, DNS:attachments.office.net, DNS:attachments-sdf.office.net, DNS:ccs.login.microsoftonline.com, DNS:ccs-sdf.login.microsoftonline.com, DNS:hotmail.com, DNS:mail.services.live.com, DNS:office365.com, DNS:outlook.com, DNS:outlook.office.com, DNS:substrate.office.com, DNS:substrate-sdf.office.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
(..snip..)
PTRレコード
PTRレコードは特定のIPアドレスに対応するホスト名を定義するレコードですので、サブドメインを取得できる可能性があります。ただ実情としては、クラウド環境などの影響もあり、取得できるケースはあまり多くないかもしれません。
# dig -x 117.104.133.164 +noall +answer
164.133.104.117.in-addr.arpa. 86372 IN PTR jprs.jp.
公開情報を用いた調査（Passive型の検索エンジン）
公開情報をDB化したPassive型の検索エンジンを利用することでサブドメインを洗い出すことも可能です。ただし、使う検索エンジンがPassive型であるのか、オンアクセス型であるかは適切に見極める必要があります。筆者は実際にオンアクセス型のツールによりサービスが停止したことがあるという事例も耳にしたことがあり、契約に基づかない調査の場合は特に法律に抵触する可能性があるため注意が必要です。調査サイトはそれぞれ特色があるので、そのサイトの特性（Passive/オンアクセス、結果の精度など）を比較してみると面白いと思います。
＜Robtex（https://www.robtex.com）＞
RobtexであればIPアドレス（もしくはネットワーク帯）をベースに記録されたAレコードやPTRレコードが返却されるため、これらの情報からサブドメインを取得できます。
WIDEプロジェクトのIP帯を検索した例
＜BGP Toolkit（https://bgp.he.net/）＞
同様に、Bgp toolkitでも記録されたAレコードやPTRレコードを収集することが可能です。持っている情報は異なるため、取得できる結果も異なります。
WIDEプロジェクトのIP帯を検索した例
＜Spyonweb（https://spyonweb.com/）＞
Spyonwebでは、同一IP上にホスティングされたFQDNを洗い出すといったことも可能です。
MBSDのコーポレートサイトのIPを検索した例
＜Microsoft Defender Threat Intelligence（https://ti.defender.microsoft.com/）＞
Microsoft Defender Threat Intelligenceでは、脅威インテリジェンス情報として、IPやドメイン/サブドメインだけでなく、様々な情報を取得することが可能です。ResolutionsのメニューにはIPに紐づいたドメイン/サブドメイン情報が表示されており、ここから情報を取得することもできます。
MBSDのコーポレートサイトのIPを検索した例
＜Shodan（https://www.shodan.io/）＞
有名なインターネットスキャンエンジンの１つで、収集した情報をユーザが検索することが可能です。リアルタイムのデータではありませんが、定期的に収集されたデータが蓄積されており、IPアドレスを入力すると、ドメイン/サブドメイン情報を含む様々な情報が返却されます。
WIDEプロジェクトのIPを検索した例
＜Censys（https://search.censys.io/）＞
Shodanと同じく有名なインターネットスキャンエンジンの１つで、収集した情報をユーザが検索することが可能です。こちらもリアルタイムのデータではありませんが、定期的に収集されたデータが蓄積されており、IPアドレスを入力すると、ドメイン/サブドメイン情報を含む様々な情報が返却されます。
WIDEプロジェクトのIPを検索した例
＜Bing search（https://www.bing.com/）＞
Bingの検索機能の演算子にIPというものがあり、特定のIPアドレスがホストするサイトを検索する機能が提供されています。この演算子を使うことで、IPに紐づくWebサイトのドメイン/サブドメインを取得することができます。
MBSDのコーポレートサイトのIPを検索した例
ドメインを起点にサブドメインを探す
続いては、ドメインを起点にサブドメインを探す方法について触れてみます。
・ドメインを起点にサブドメインを探す
・検索エンジンを使った調査、GoogleDorks、BingDorking
・＜site演算子＞
・＜link演算子＞
・Webサイトのクローリング
・＜robots.txt＞
・＜crossdomain.xml＞
・＜security.txt＞
・WebArchiveから探す
・Certificate Transparency
・＜crt.sh＞
・PassiveDNS
・＜Microsoft Defender Threat Intelligence＞
・サブドメイン列挙サービスの利用
・ゾーン転送
・SRVレコード
検索エンジンを使った調査、GoogleDorks、BingDorking
まずはお手軽にできる方法からです。検索エンジンのクエリを活用することで（Webサーバの）サブドメインを収集することができます。今回はサブドメインを収集することが目的ですが、検索エンジンを使ったWebサイトの設定不備やログイン画面の列挙など様々な検索クエリが提唱されています。
Google Hacking Database（https://www.exploit-db.com/google-hacking-database）
＜site演算子＞
site演算子を用いた検索では、siteで指定したドメイン(サブドメイン)やURLを含むサイトをしてしてキーワード検索を行うことができます。この挙動を利用することで、サブドメインを探すことができます。
site演算子でGoogle検索した例（site:mbsd.jp）
検索結果から、www.mbsd.jpやnote.mbsd.jpといったサブドメインを確認することができます。検索結果のリストを眺めても良いのですが、省力化の手法として、-の演算子を使って、確認済みのサブドメインを省くことで効率的にサブドメインを収集できます。
同様の手法がBingでも可能です。Bingもsite演算子をサポートしているため同様の結果が得られます。
site演算子でBing検索した例（site:mbsd.jp）
＜link演算子＞
リンクを検索する演算子でコンテンツ内のURLを収集するのに役立っていたのですが、残念ながらサポートが終了してしまいました。完全に同じ検索はできませんが、intext:演算子やallintext:演算子を用いることで、コンテンツ内の文字列を検索できるため、一部のリンク含む文字列を検索することができます。この挙動を利用し、サブドメインを収集することができます。
intext演算子でGoogle検索した例（intext:mbsd.jp）
同一のサイト上であれば、頻繁にドメイン含むキーワードがでてくるため、-演算子を活用することで、情報を洗練させることが可能です。
intext演算子とsite演算子を組み合わせてGoogle検索した例（intext:"mbsd.jp" -site:mbsd.jp -intext:"www.mbsd.jp"）
Webサイトのクローリング
robots.txtなどでクローラーが制限されて検索エンジンにインデックスされないケースやHTMLでコメントアウトされているケースなどもあるため、Webサイトのクローリングもサブドメインを収集するために有効な手法です。また、security.txt、sitemap.xml、crossdomain.xmlからも情報を収集できるケースがあるため、こちらも有効な手法になります。
＜robots.txt＞
検索エンジンのクローラーに対して、アクセスを許可するファイルと許可しないファイルを設定できます。基本的にGoogleDorksなどでHitしないコンテンツになりますので、許可しないファイルを覗いてみることで、情報が得られる可能性があります。
robots.txtの例（Googleの場合）
＜crossdomain.xml＞
Flashがサポート終了していることもありHit率はかなり低いですが、稀に残存していることがあります。クロスドメインアクセスを実現するため、crossdomain.xmlに許可する通信先を設定することができますので、サブドメインや関連するサイトの情報を得られる可能性があります。（Flash特有のXSSやクロスドメインアクセスをするためにお世話になった方は多いのではないでしょうか。）
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy><site-control permitted-cross-domain-policies="master-only"/><allow-access-from domain="foo.example.com" secure="true"/><allow-access-from domain="bar.example.com" secure="true"/><allow-http-request-headers-from domain="www.example.com" headers="X-foo" secure="true"/></cross-domain-policy>
＜security.txt＞
利用サービスにセキュリティ上の問題を見つけた際に連絡するアドレスを記したファイルで、RFC 9116で提唱されたものです。以下のように、/.well-known/security.txtにアクセスすることで、コンタクト先のドメイン情報やメールに用いているサブドメインなどを入手することができる可能性があります。
/.well-known/security.txtの例（Googleの場合）
ただ検索してみると、Hitが2300件ということで、導入はあまり進んでいなそうですね…。
/.well-known/security.txtのあるサイトを検索した結果
WebArchiveから探す
過去のWebデータを貯めているWebArchiveサービスのWebサイトをクローリングすることも有効です。過去に使用していたリンクなどの情報からサブドメインを収集できる可能性があります。国立国会図書館のサイトにて一覧化してくださっていますので、こちらが参考になるかと思います。
インターネット資料収集保存事業のサイト
Certificate Transparency
Certificate Transparencyは認証局の誤発行や悪意ある攻撃者による不正発行を検知するために構築されたフレームワーク（RFC6962）です。証明書を発行する際に発行証跡をCertificate Transparencyサーバに登録を行いますので、この仕組みを利用することで、サブドメインを確認することができる場合があります。ただし、ワイルドカード証明書のように、Subject Alternative Nameにワイルドカードを指定するケースではサブドメインを特定することはできません。
crt.sh はCertificate Transparencyに関する情報を検索できるサイトの１つです。ドメインを入力することでサブドメインの収集が可能です。
mbsd.jpの情報を検索した例
PassiveDNS
PassiveDNSの情報からサブドメインを集める手段もとても有効で、ケースにもよりますがかなり多くの情報を収集することが可能です。ただし、闇雲に探すことができるわけではなく、ターゲットとなるドメインの情報等から辿るため、質の良い情報を収集するためには、前編で紹介したドメインをしっかり洗い出した上で活用することが重要です。
＜Microsoft Defender Threat Intelligence（https://ti.defender.microsoft.com/）＞
なお、サブドメインを列挙するサイトはいくつか存在しており、Microsoft Defender Threat Intelligenceもその１つです。IPアドレスから検索するケースでも紹介しましたが、ドメインを検索すると、Subdomainのメニューが表示され、Microsoft Defender Threat Intelligenceが持っているPassiveDNSのデータを見ることができます。ここでは、サブドメインの一覧を入手することができます。
mbsd.jpドメインのPassiveDNSのデータを検索した例
PassiveDNSに表示されるデータは過去のデータや無効なサブドメインも含んでおり、現在使えるドメインであるかは別途検証が必要です。過去に利用されていただけで、現在名前解決できないFQDNであれば自明ですが、ワイルドカードレコードを利用している場合、適当なFQDNでのクエリでも名前解決ができるため、この情報が記録されていることがあります。DNSでは特定のレコード（A、AAAA、MX、CNAME、TXT、CAAなど）に対しては、ワイルドカードを指定することができるため、登録されていないレコードは同じ値が返却されます。絶対に存在しないと思われるレコードやワイルドカードに対しての名前解決を行い、サブドメインの有効性を確認するといったことも考えられますが、SaaS型のサービスで顧客ごとホスト名部分を変えるようなサービスである場合もあるため、名前解決の結果だけで判断することは少し難しいかもしれません。
# dig +noall +answer zettaini-sonzaishinai.example.com # 存在しないFQDN
zettaini-sonzaishinai.example.com. 84767 IN A 192.0.2.1
上記挙動の場合の設定イメージ（Bindの場合）、サーバ側のバーチャルホストで有効なサブドメインだった場合に画面を返すような構成。
$TTL 86400
@ IN SOA ns.example.com. root.example.com.(
(..snip..)
stg IN A 203.0.113.1
* IN A 192.0.2.1
また、以下の例のようにサブドメインに対してワイルドカードレコードが有効なケースもあるため、こちらも考慮が必要なポイントになります。
# dig +noall +answer *.amazonaws.com
# dig +noall +answer *.s3.amazonaws.com
*.s3.amazonaws.com. 41824 IN CNAME s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com. 270 IN CNAME s3-w.us-east-1.amazonaws.com.
s3-w.us-east-1.amazonaws.com. 4 IN A 3.5.29.42
s3-w.us-east-1.amazonaws.com. 4 IN A 52.216.56.65
s3-w.us-east-1.amazonaws.com. 4 IN A 52.216.220.193
s3-w.us-east-1.amazonaws.com. 4 IN A 52.217.193.153
s3-w.us-east-1.amazonaws.com. 4 IN A 3.5.0.104
s3-w.us-east-1.amazonaws.com. 4 IN A 52.217.228.209
s3-w.us-east-1.amazonaws.com. 4 IN A 3.5.29.152
s3-w.us-east-1.amazonaws.com. 4 IN A 54.231.235.57
サブドメイン列挙サービスの利用
今回の調査の趣旨とは合わないため紹介は割愛しますが、ドメインの入力をもとにサブドメインを列挙するサービスも存在します。こちらは使う検索エンジンがPassive型であるのか、オンアクセス型であるかは適切に見極め利用することが大切です。
Passive型以外にもオープンデータとしてデータを公開しているケース（例えば、Rapid7社のForward DNS (FDNS)など）もあり、これらの情報を検索することでサブドメインを取得できる可能性があります。ただし、データ活用を行うにあたり、ライセンス上、許可されている行為であるかは確認する必要があります。
ゾーン転送
有効になっているケースはほぼ見かけませんが、ゾーン転送でもサブドメインの一覧を取得することができます。
■ゾーン転送が成功する例
# dig +norec example.com axfr
example.jp. 86400 IN SOA ns1.example.jp. root.jprs.co.jp. 1 3600 900 1814400 900
example.jp. 86400 IN NS ns1.example.jp.
example.jp. 86400 IN NS ns2.example.jp.
ns1.example.jp. 86400 IN A 192.0.2.1
ns2.example.jp. 86400 IN A 192.0.2.11
www.example.jp. 86400 IN A 192.0.2.10
■ゾーン転送が失敗する例
# dig +norec mbsd.jp axfr
<<>> DiG 9.16.1-Ubuntu <<>> +norec mbsd.jp axfr
;; global options: +cmd
; Transfer failed
SRVレコード
公開サービスにおいて設定されているケースは多くありませんが、特定のサービスの情報を通知するSRVレコードがあります。本来は、負荷分散や冗長性を目的としており、指定されたサービスのサブドメインやポート番号を取得することが可能です。 例えば、FTPサーバを探すのであれば、_ftp._tcp.example.co.jpのようなクエリを用いることでFTPを提供するサブドメインを特定することができるようになります。この手法により、サブドメインを収集することができる可能性があります。
■SRVレコードを使ってHTTPを提供するサーバを探す例
# # dig +noall +answer srv _http._tcp.update.FreeBSD.org
_http._tcp.update.FreeBSD.org. 3599 IN SRV 1 50 80 update2.freebsd.org.
_http._tcp.update.FreeBSD.org. 3599 IN SRV 1 50 80 update1.freebsd.org.
おわりに
さて、長々とお付き合い頂きありがとうございました。一部似たような内容もあったと思いますし、書こうと思って忘れたこともあるような気もしています。冒頭でも書きましたが、この他にもこんな方法がある！などフィードバックを頂ければとても喜びますので、是非よろしくお願いします。
おすすめ記事
