コンテンツに移動
Cloud
ブログ
お問い合わせ 無料で開始
Cloud
ブログ
お問い合わせ 無料で開始
脅威インテリジェンス

.com を超えたハッキング - プライベート TLD の列挙

2024年9月10日
Mandiant

 ※この投稿は米国時間 2024 年 8 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

 

背景

話は数か月前、私が大手小売企業のレッドチーム評価を実施したときに遡ります。オープンソース インテリジェンス（OSINT）フェーズで、クライアント名を含む SSL 証明書を確認し、そのクライアントが独自のトップレベル ドメイン（TLD）を所有していることを特定しました。TLD とはドメイン名の最後の部分、つまり最後のドットの後に続く文字です。たとえば、ドメイン名「google.com」の場合、TLD は「.com」です。Google のような企業は、.goog、.go、.google など、複数の TLD を所有しています。Google は、これらの TLD とその下のドメイン（「site.goog」など）のすべてを管理しています。

TLD の所有は珍しいことではありません。次の表に、さまざまな企業が所有する TLD を示します（TLD の全リストについては、TLD-List または IANA リストをご覧ください）。

企業

TLD

Google

.google、.go

Marriott

.marriott

American Express

.americanexpress、.amex

Barcelona

.Barcelona

Gucci

.gucci

Jaguar

.jaguar

Kia

.kia

Netflix

.netflix

クライアントの TLD に興味を引かれ、Google と GitHub を使用して、組織が所有する TLD のリストを表示したり、特定の TLD の下のドメインを検索したりするツールを探してみました。驚いたことに、そのようなツールはひとつも見つかりませんでした。

なぜ私がそこまで TLD にこだわるのか不思議に思われるかもしれません。私のお気に入りのバグ報奨金ハンターの一人であり、ハッカー コミュニティではその OSINT 能力の高さで知られている Jason Haddix 氏は、Bug Hunter's Methodology Live Course において、「Apex ドメインが 1 つ見つかるごとに、標的のハッキング チャンスは 4 倍になります」と述べています。基本的に、企業に属する TLD が多く検出されるほど、悪用しやすい脆弱性を見つけやすくなります。

そこで私は、クライアントが所有する TLD のリストを作成し、これまで知られておらずスキャンされていない可能性のある新しいドメインを特定しようとしました。

問題点

前述したように、TLD と各 TLD の特定のドメインのリストを表示するツールやサイトは見つかりませんでした。

現時点では、列挙ツールはいずれもサブドメインに重点を置いています。サブドメイン列挙は、OSINT やバグ報奨金コミュニティにおいて重要なテーマとなっていますが、TLD に基づいたドメイン列挙は違います。Trickest による Zip（リポジトリは DMCA 削除通知により無効になりました）など、特定の TLD（この場合は「.zip」TLD）に基づいたドメインのブルート フォースに重点を置くプロジェクトがあります。このツールは、単語リストに基づいてドメインをアクティブにブルート フォースします。これは良いアイデアではありますが、私はパッシブ サブドメイン列挙を行う方法と同じように、より良い結果につながる可能性のあるパッシブな方法がほかにないものかと考えました。

Internet Corporation for Assigned Names and Numbers（ICANN）や Centralized Zone Data Service（CZDS）などの他のサイトでは、これらのドメイン名について TLD の所有者に対してリクエストを行うことができます。ただし、この方法ではお客様に私の行動が通知されるため、現実的なソリューションではありません。Mandiant レッドチームの業務の性質上、検出されないでいることが求められます。

そのため、何か新しいものを作る必要がありました。こうして、新しいツールのアイデアが実を結ぶことになりました。

解決策

検討後、目標の達成に必要なアクションを次の 2 つのステップに分けることにしました。

  1. TLD のリストでクライアント名とその名前のバリエーションの正規表現検索を行い、TLD を見つける。これは、IANA リストや TLD-List などのサイトを使用して達成できます。

  2. TLD 内のドメインを検索する方法を決定する。サブドメイン列挙手法のいずれかを使用して、「*.domain.tld」ではなく「*.tld」を検索できるかどうか。

サブドメイン列挙をパッシブおよびアクティブに行うツールは多数あります。パッシブに行うには、さまざまなデータソースでサブドメインをクエリします。アクティブに行うには、単語リストを使用してブルート フォースします。パッシブに行う場合と同じデータソースを使用して、サブドメインを検索する代わりにドメインを検索する場合はどうすればよいでしょうか。データソースはこれをサポートしているでしょうか。

最も一般的な（そしておそらく最も広く使用されている）サブドメイン列挙ツールの一つが、ProjectDiscovery の Subfinder です。私は Subfinder から現在のデータソースを抽出しました（これを行うには、ソースコードを確認するか、「-list」フラグを使用します）。次に、各データソースを手動でチェックして、サブドメインではなくドメインを検索できるかどうかを確認しました。

数日かけてすべての API を試し、新しい正規表現を使用できるかどうかを判断しました。そしてわかったのは、使用できるものもあれば、使用できないものもあるということです。

たとえば、SSL 証明書の検索アプリケーションである crtsh では、公開されている Postgres SQL サーバーを使用してドメインを検索できました。

crtsh を使用してこれを行うには、たとえば、psql -t -h crt.sh -p 5432 -U guest certwatch というコマンドを使用して Postgres データベースに接続します。psql ユーティリティのインストールは、このブログ投稿の範囲外ですが、検索すれば簡単にインストール手順が見つかります。次のクエリを実行すると、特定しようとしているドメインの TLD 部分が検索されます。

SELECT ci.NAME_VALUE NAME_VALUE FROM 
certificate_identity ci WHERE ci.NAME_TYPE = 'dNSName' AND 
reverse(lower(ci.NAME_VALUE)) LIKE reverse(lower(‘%.TLD'));

Netlas でも同様のアプローチを使用できます。Netlas は、ユーザーが新しいユーザーを登録したり、API を使用してドメイン情報をクエリしたりできるようにする OSINT 企業です。Netlas と次のクエリを使用して、特定の TLD に基づいたドメインのリストを取得できました。

curl -H 'X-API-Key: *****' https://app.netlas.io/api/domains/?q=*.google | jq .
https://storage.googleapis.com/gweb-cloudblog-publish/images/enumerating-tlds-fig.max-900x900.jpg

図 1: Netlas を使用した TLD の列挙

次のリストは、ドメインの検索クエリを実行できたデータソース、実行できなかったデータソース、API キーが有料だったため検証できなかったデータソースを示しています。

  • ドメイン列挙ができた: Crtsh、netlas、bufferover、censys、github、dnsrepo、wayback machine

  • ドメイン列挙ができなかった: Alienvault、anubis、bevigil、binaryedge、chaos、commoncrawl、digitorus、dnsdumpster、fullhunt、hackertarget、intelx、leakix、rapiddns、redhuntlabs、securitytrails、shodan、sitedossier、virustotal、zoomeyeapi

  • 不明: C99、Certspotter、Chinaz、Dnsdb、Fofa、Hunter、Passivetotal、Quake、Riddler、Robtex、Threatbook、whoisxmlapi、Facebook、builtwith

さて、いよいよ皆様お待ちかねの新しい tldfinder ツールの説明に入りましょう。

ツールのリリース

ProjectDiscovery との連携のもと、TLD、関連付けられているサブドメイン、関連するドメイン名を効率的に検出できるツール、tldfinder を発表いたします。

サポートされているすべてのオプションを確認するには、次のようにして tldfinder のヘルプを表示してください。

$ ./tldfinder -h

このツールには 3 つの検出モードがあります。

  • DNS（デフォルト）: TLD セクションに入力された入力文字列を検索します。

  • TLD: ドメイン フィールドの入力文字列を検索し、dnsx を使用してファジングを行います。

  • ドメイン: 逆引き WHOIS を使用して、指定された入力ドメインの関連するドメイン名を取得します（dnsrepo、whoxy、whoisxmlapi のいずれかの API が必要）。

DNS モードと TLD モードはアクティブであることにご注意ください。つまり、これらのモードでは DNS ブルート フォースが実行されます。ドメインモードはパッシブです。つまり、ドメインには触れず、データソースからのクエリのみを実行します。

ソース

リリース時の現時点では、tldfinder は次の API に対して情報をクエリします。

$ ./tldfinder -ls

  __  __   ______         __      
 / /_/ /__/ / _(_)__  ___/ /__ ____
/ __/ / _  / _/ / _ \/ _  / -_) __/
\__/_/\_,_/_//_/_//_/\_,_/\__/_/  

        projectdiscovery.io

[INF] Current list of available sources. [9]
[INF] Sources marked with an * need key(s) or token(s) to work.
[INF] You can modify /home/idanron/.config/tldfinder/provider-config.yaml 
to configure your keys/tokens.

whoisxmlapi *
bufferover *
censys *
dnsrepo *
dnsx
whoxy *
netlas *
waybackarchive
crtsh

DNS および TLD 検出モードでは、すべてのソースがクエリされます（TLD モードでは、さらにファジングが行われます）。ドメインモードでは、dnsrepo、whoxy、whoisxmlapi のみがクエリされます（これらだけが逆引き WHOIS をサポートしているため）。

DNS モードの使用

次の例では、tldfinder をデフォルトの DNS 検出モード オプションで使用して、「.google」TLD に含まれるドメインを検索します。

$ ./tldfinder -d .google

  __  __   ______         __      
 / /_/ /__/ / _(_)__  ___/ /__ ____
/ __/ / _  / _/ / _ \/ _  / -_) __/
\__/_/\_,_/_//_/_//_/\_,_/\__/_/  

        projectdiscovery.io

[INF] Loading provider config from 
/home/idanron/.config/tldfinder/provider-config.yaml
[INF] Enumerating domains for google
partners.cloudskillsboost.google
community.grow.google
epp.registry-sandbox.google
epp.registry.google
www.registry.google
registry-qa.google
support.registry-qa.google
citystpaul.google
jira-testing.gss.google
cloudskillsboost.google
stg.cloudvmwareengine.google
domains.google
environment.google
cloud.google
design.google
netbotzcircunvalacion.google
app.google
channel-app.google
xc-8d1db3.dns.google
whois.registry-sandbox.google
epp.nic.google
service.cloudvmwareengine.google
dev.cloudvmwareengine.google
travel.google
lxc-wordpress.dns.google
registry-sandbox.google
www.registry-sandbox.google
www.registry-qa.google
lxc-gftcloud.dns.google
lers.google
test.cloud.gss.google
www.cloudskillsboost.google
grow.google
registry.google
8888.google
europe-west2-test.prodtest.cloudvmwareengine.google
mail.ai.google
dns64.dns.google
earlydays.google
privx.google
whois.registry.google
support.registry.google
fx06b9f1.google
whois.nic.google
dns.google
cloud.gss.google
partner.cloudskillsboost.google
support.registry-sandbox.google
[INF] Found 48 domains for google in 637 milliseconds 994 microseconds

TLD モードの使用

次の例では、tldfinder を TLD 検出モード オプションで使用し、文字列「google」を含むドメインを検索します。次に、dnsx（前述の ProjectDiscovery ツール）を使用して TLD 部分に対してファジングを行います。

$ ./tldfinder -d google -dm tld

  __  __   ______         __      
 / /_/ /__/ / _(_)__  ___/ /__ ____
/ __/ / _  / _/ / _ \/ _  / -_) __/
\__/_/\_,_/_//_/_//_/\_,_/\__/_/  

        projectdiscovery.io

[INF] Loading provider config from 
/home/idanron/.config/tldfinder/provider-config.yaml
[INF] Enumerating domains for google

google.meme
google.xn--fiq228c5hs
google.ltda
google.vote
google.amsterdam
google.hiphop
google.sv
google.boo
google.cymru
google.llc
google.us
google.xn--kprw13d
google.christmas
google.dad
google.app
google.monster
google.rs
[--snip--]
[INF] Found 468 domains for google in 3 minutes 3 seconds

* Please note that the results were redacted due to the length of the results.

ドメインモードの使用

次の例では、tldfinder をドメイン検出モードで使用して、入力文字列（この場合は「projectdiscovery.io」）に関連する可能性のあるドメインを検索します。これは、このモードで許可されている API の一つ（または複数）を使用して逆引き DNS を行うことで機能します（詳細については、「ソース」セクションをご覧ください）。

$ ./tldfinder -d projectdiscovery.io -dm domain
  __  __   ______         __      
 / /_/ /__/ / _(_)__  ___/ /__ ____
/ __/ / _  / _/ / _ \/ _  / -_) __/
\__/_/\_,_/_//_/_//_/\_,_/\__/_/  

        projectdiscovery.io

[INF] Enumerating domains for projectdiscovery.io
projectdiscovery.org
projectdiscovery.in
projectdiscoveryinc.org
projectdiscoveryu.com
projectdiscoverycaribbean.org
nuclei.projectdiscovery.io
projectdiscovery.tech
projectdiscovery.org.uk
projectdiscoveryofva.com
projectdiscoveryou.com
projectdiscovery.dev
projectdiscovery.co.uk
projectdiscoveryprograms.com
projectdiscoverymovie.com
dns.projectdiscovery.io
projectdiscovery.com
projectdiscovery.net
projectdiscovery.io
projectdiscoveryprograms.org
docs.projectdiscovery.io
[INF] Found 20 domains for projectdiscovery.io in 1 second 571 milliseconds

結果を改善する方法

これまでどおり、API キーを provider-config.yaml ファイルに追加することをおすすめします。これを行うには、Linux では /home/{USER}/.config/tldfinder/provider-config.yaml に、Windows では C:\Users\{USER}\.config\tldfinder\provider-config.yaml（{USER} はオペレーティング システムのユーザー名に置き替えてください）にこのファイルを作成します。このファイルは初めてツールを実行したときにも自動的に作成されます。

ファイル形式は次のようになります（REDACTED を API キーに置き換えてください）。

bufferover: ["REDACTED"]
censys: []
dnsrepo: ["REDACTED"]
netlas: ["REDACTED"]
whoisxmlapi: ["REDACTED"]
whoxy: []

謝辞

このツールの作成にご協力、ご支援くださった ProjectDiscovery に感謝の意を表します。

-Mandiant、執筆者: Idan Ron

 

投稿先
関連記事
https://storage.googleapis.com/gweb-cloudblog-publish/images/threat-intelligence-default-banner-simplifie.max-700x700.png
Threat Intelligence

ギャップを埋める: アプリケーション セキュリティ テストでレッドチーム診断を向上

執筆者: Mandiant • 所要時間: 16 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/threat-intelligence-default-banner-simplifie.max-700x700.png
Threat Intelligence

QR コードを利用した侵入経路: ブラウザ分離環境での C2

執筆者: Mandiant • 所要時間: 13 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/threat-intelligence-default-banner-simplifie.max-700x700.png
Threat Intelligence

どこまで短くなるのか？2023 年の脆弱性悪用までの時間の傾向分析

執筆者: Mandiant • 所要時間: 14 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/threat-intelligence-default-banner-simplifie.max-700x700.png
Threat Intelligence

コード インタープリタと Google Threat Intelligence によるマルウェア分析を目的とした Gemini の機能強化

執筆者: Bernardo Quintero • 所要時間: 10 分