セキュリティ

EASMとは:外部公開資産をsubfinder・crt.sh・Shodanで洗い出す手順

EASMとは:外部公開資産をsubfinder・crt.sh・Shodanで洗い出す手順

EASM(External Attack Surface Management)は、インターネット側から届く自社の資産を、攻撃者と同じ公開情報を使って見つけ、弱点を継続して確かめる取り組みです。この記事では、経済産業省のガイダンスにある定義を押さえたうえで、証明書透明性ログ(crt.sh)とsubfinderでホスト名を集め、dnsxとhttpxで生きているかを確かめ、Shodanで開いているポートを見るまでの手順をコマンド付きで示します。最後に、OSSでの棚卸しで足りる組織と、商用のEASMや脆弱性診断へ進むべき条件を言い切ります。ツールの版は2026年11月4日時点のものです。

まとめ:EASMはドメイン起点の棚卸しから始め、継続監視の要否で商用を選ぶ

EASMの中心は、管理台帳に載っていない公開資産を見つけることです。最初の一歩に製品は要りません。自社ドメインを起点に、crt.shとsubfinderでホスト名を集め、dnsxとhttpxで生存と中身を確かめれば、どの部署のどのサーバーが外から見えているかの一覧ができます。

見つかった資産の中で先に手を打つのは、外部サービスを指したまま使われていないCNAMEと、持ち主が分からないまま応答を返しているWebサーバーです。ドメインが10未満で年に数回の棚卸しで足りるならOSSで十分です。子会社を含めて毎日の監視が要るなら商用のEASMを、見つけた資産の弱点を深く確かめたいなら脆弱性診断・セキュリティ診断を使い分けます。

EASMとは何か:外部から見える資産を攻撃者と同じ情報源で見つける仕組み

EASMは製品名ではなく、作業の呼び名です。まず範囲を定義で固め、手元の脆弱性管理のどこに入るのかを決めます。

経済産業省ガイダンスの定義と脆弱性診断・CTEMとの範囲の違い

経済産業省は2023年5月29日にASM(Attack Surface Management)導入ガイダンスを公表しました。そこでのASMは「組織の外部(インターネット)からアクセス可能なIT資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」です。EASMのEは、この外部からの視点を強調した呼び方と考えてかまいません。

脆弱性診断との違いは、調査の出発点です。診断は「この範囲を調べてほしい」と対象を決めてから深く検査します。EASMは対象そのものを探すところから始めます。継続的な管理の枠組みであるCTEMの中では、EASMは対象を決める段階と発見の段階を受け持つ道具です。枠組み全体はCTEMとは?脆弱性管理との違い・5つの段階と企業の導入判断で整理しています。

EASMが拾う資産の種類:サブドメイン・公開IP・証明書・開いたポート

実務で一覧に載せる資産は4種類です。重みは均等ではなく、上ほど見落としが事故につながりやすい順に並べています。

  • サブドメイン:キャンペーン用のサイトや検証環境など、部署が個別に立てて台帳から漏れやすいもの
  • 公開IPアドレスと開いたポート:管理画面やデータベースのポートが外へ開いたままのもの
  • 証明書:有効期限切れや、想定外の名前で発行された証明書
  • 外部サービスへの向き先:CNAMEの先にあるSaaSやクラウドの設定

経済産業省の公表ページも、ASMの効果として「組織管理者の未把握の機器や意図しない設定ミス」を攻撃者の視点で見つけられる点を挙げています。部署がIT部門を通さずに立てたサイトの扱いは、シャドーITとは?該当する例とBYODとの違い・公的資料に沿った対策も参考になります。

検証環境の準備:自社ドメインに限った調査範囲とGo製ツールのインストール

ここから先のコマンドは、Goを入れたLinuxかmacOSの端末を前提にしています。手を動かす前に、調べてよい範囲を文書で決めておきます。

調査してよい範囲の決め方:自社が管理するドメインと書面で許可を得た範囲

crt.shやsubfinderは公開情報を読むだけで、相手のサーバーには触れません。一方で、後半のhttpxは見つけたホストへ実際にHTTPの要求を送ります。ポートを直接叩くnaabu(v2.7.0、2026年10月28日公開)のような能動的なスキャンは、相手の監視に検知される前提で扱うべきです。

対象は、自社がドメインを登録・管理しているものと、グループ会社などから書面で許可を得たものに限ります。似た名前の他社ドメインが結果に混ざるのはよくあることで、そこへ要求を送らないよう、範囲外の名前を外してから次の工程へ渡します。許可の取り方の考え方はペネトレーションテストとは?種類・手法・手順と実施前に必要な許可と共通です。

subfinder・dnsx・httpxをgo installで入れる手順と版の確認

使うのはProjectDiscoveryが公開している3つのツールで、いずれもMITライセンスです。11月4日時点の最新版はsubfinderがv2.17.0、dnsxがv1.3.1、httpxがv1.12.0でした。各READMEはGoのgo1.26.10以上を求めています。

# 3つのツールを入れる($HOME/go/bin に PATH を通しておく)
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
go install -v github.com/projectdiscovery/dnsx/cmd/dnsx@latest
go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

# 版を確かめる
subfinder -version
dnsx -version
httpx -version

Pythonの同名ライブラリhttpxを入れた環境では、コマンド名が重なって別物が起動することがあります。which httpxで$HOME/go/bin側が先に見つかるかを確かめてから進めます。

証明書透明性ログをcrt.shのJSONで引き、発行済み証明書からホスト名を集める

最初の情報源は証明書です。HTTPSで公開したホスト名は、証明書の発行時に公開のログへ記録されています。

CTログに名前が残る仕組みとワイルドカード証明書で漏れるホスト名

Certificate Transparency(CT)は、認証局が発行した証明書を公開のログへ記録させる仕組みで、現行の仕様はRFC 9162(Certificate Transparency Version 2.0)です。certificate.transparency.devは、ログが追記専用(append-only)で誰でも検証できると説明しています。消えないので、すでに止めたサイトの名前も残ります。

弱点は2つあります。*.example.comのようなワイルドカード証明書では個々のホスト名がログに出ません。HTTPだけで公開しているホストも証明書が無いので載りません。CTログだけで一覧を作らず、次のsubfinderで補うのはこのためです。

crt.shのJSON出力をjqで重複除去してホスト名一覧にするコマンド例

crt.shはSectigoが運営するCTログの検索サイトで、output=jsonを付けるとJSONで結果を返します。各要素のname_valueに証明書へ載った名前が改行区切りで入っています。

# %25 は URL エンコードした % で、example.com 配下のすべての名前に一致させる
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' \
  | tr 'A-Z' 'a-z' \
  | sed 's/^\*\.//' \
  | sort -u > ct_hosts.txt

wc -l ct_hosts.txt

sedでワイルドカードの「*.」を外しているので、一覧には親の名前だけが残ります。件数が多いドメインではcrt.shが応答を返すまで時間がかかり、混雑時にはエラーになる場合もあるため注意が必要です。失敗したら時間を空けて取り直し、結果は日付を付けたファイルで保存しておきます。前回との差分が、新しく公開された名前の一覧になるからです。

subfinderで受動的にサブドメインを列挙し、dnsxとhttpxで生存を確かめる

CTログで漏れる名前を、DNSの履歴や検索サービスなど複数の公開情報源から補います。集めた名前は、そのままでは生きているかどうか分かりません。

subfinderの-allとAPIキーの設定ファイルで情報源を増やす設定例

subfinderはREADMEで受動的なサブドメイン列挙だけを行うツールだと説明されています。既定で使うのは一部の情報源だけで、すべての情報源を回すための指定が-allです。時間はかかりますが、棚卸しの目的なら-allを付けます。

# APIキーを置く設定ファイル(既定は $CONFIG/subfinder/provider-config.yaml。Linux では ~/.config 配下)
# 形式は「情報源の名前: キーの一覧」
#   securitytrails:
#     - YOUR_SECURITYTRAILS_KEY
#   shodan:
#     - YOUR_SHODAN_KEY

subfinder -d example.com -all -silent -o subfinder_hosts.txt

# CTログの結果と合わせて1つの一覧にする
cat ct_hosts.txt subfinder_hosts.txt | sort -u > hosts.txt

READMEは多くの情報源がAPIキーを要すると書いています。キーなしでも動きますが、結果の件数は減ります。設定ファイルの場所は環境変数SUBFINDER_PROVIDER_CONFIGで変えられるので、CIで定期実行するならキーを秘密情報の保管庫から渡し、リポジトリには置きません。

dnsxでCNAMEを引き、外部サービスを指したままの宙に浮いた設定を探す

次にdnsxで名前を解決します。Aレコードが返る名前が今も使われている候補で、CNAMEの先がどのサービスかも同時に分かります。

# A と CNAME を引き、応答の中身も表示する
dnsx -l hosts.txt -a -cname -resp -silent -o dns.txt

# CNAME の先が外部のホスティングを指している行だけを抜き出す
grep -E 'github\.io|herokuapp\.com|azurewebsites\.net|cloudfront\.net|s3\.amazonaws\.com' dns.txt

ここで最も危ないのは、外部サービス側のサイトを消したのに、自社DNSのCNAMEだけが残っている状態です。GitHub Pagesのドキュメントは、サイトを無効にしたままカスタムドメインの設定が残っていると、第三者が自社のサブドメインで別のサイトを公開できる恐れがあると警告しています。該当する行は、向き先のサービスで今も自社のアカウントが使っているかを確かめ、使っていなければCNAMEを削除する対象です。DNSの引き方そのものは名前解決とは?DNSの仕組み・dig/nslookupでの確認方法で解説しています。

httpxで応答コード・タイトル・使用技術を一覧にして持ち主を突き合わせる

名前が引けたホストへhttpxでHTTPの要求を送り、応答コード、ページのタイトル、使っている技術、CDNの有無を1行ずつJSONで残します。

# 応答コード・タイトル・使用技術・IP・CDN を JSON Lines で保存する
httpx -l hosts.txt -sc -title -td -ip -cdn -silent -j -o web.jsonl

# 一覧表に起こすときは URL・応答コード・タイトルだけを取り出す
jq -r '[.url, .status_code, .title] | @tsv' web.jsonl

この一覧を、情報システム部門の台帳と1行ずつ突き合わせます。台帳に無いホストは、タイトルや使用技術から持ち主の部署を探し、使い続けるか止めるかを決めてもらいます。持ち主が最後まで見つからないホストが、EASMで見つけるべき本命です。証明書の期限切れが見つかった場合の更新手順はSSL証明書の更新手順:certbotの自動更新と反映されない原因にまとめました。

Shodanで自社IPレンジと証明書名から開いたポートとサービスを確かめる

ここまでは名前から資産を探しました。Shodanはインターネット全体を走査した結果を持っているので、自社のIPレンジ側から、どのポートが開いているかを自分で走査せずに確かめられます。

IPレンジ・証明書名・逆引き名で絞るShodanフィルタの使い分け

Shodanの検索は「フィルタ名:値」の形で、コロンの前後に空白を入れません(Shodanヘルプの検索の基本)。Shodanのフィルタ一覧に載っているもののうち、棚卸しで使うのは次の3つです。

  • net:203.0.113.0/24:契約しているIPレンジの中で応答した機器
  • ssl.cert.subject.cn:example.com:自社名の証明書を載せた、他社のIP上のサーバー
  • hostname:example.com:逆引き名に自社ドメインを含む機器

ssl.cert.subject.cn:は、クラウド上に部署が立てたサーバーを見つけるのに効きます。IPレンジを自社で持っていなくても、自社名の証明書を載せていれば引っかかるからです。結果にport:3389やport:5432のような管理用・データベース用のポートが出たら、最優先で外からの到達を止めます。

host/countとhost/searchのクレジット消費差とAPIでの定期取得の注意

Shodan APIのドキュメントによると、host/searchはフィルタを含む検索か2ページ目以降の取得で1クレジットを消費します。host/countは件数とファセットだけを返し、クレジットを消費しません。dns/domainは1回の照会ごとに1クレジットです。

# まず件数とポート別の内訳だけを無料枠で確かめる(クレジット消費なし)
curl -s "https://api.shodan.io/shodan/host/count?key=$SHODAN_API_KEY&query=ssl.cert.subject.cn:example.com&facets=port,org" | jq .

# 中身が必要なときだけ host/search を呼ぶ(フィルタ付きなので 1 クレジット)
curl -s "https://api.shodan.io/shodan/host/search?key=$SHODAN_API_KEY&query=ssl.cert.subject.cn:example.com" \
  | jq -r '.matches[] | [.ip_str, .port, (.hostnames | join(","))] | @tsv'

定期取得では、countで内訳が前回から変わったときだけsearchを呼ぶ作りにすると、クレジットを抑えられます。Shodanの結果は走査した時点の記録なので、すでに閉じたポートが残っている場合もある点に注意が必要です。結果は「確認の候補」として扱い、止める判断の前にサーバーの担当者と実機の設定を確かめます。

判断:OSSの棚卸しで足りる組織と商用EASMや外部診断へ進む条件

ここまでの手順は半日あれば一巡できます。問題は、それを誰がどの頻度で続けるかです。

年数回の棚卸しで足りる条件:ドメイン数10未満と担当者の確保

次の条件をすべて満たすなら、OSSでの棚卸しを四半期に1回回せば足ります。商用のEASMは過剰です。

  • 管理するドメインが10未満で、グループ会社の資産を含めなくてよい
  • 前回の結果との差分を見て、持ち主へ確認を回す担当者が1人決まっている
  • 新しいサイトやサーバーの公開が月に数件以下で、公開の申請窓口がある

このやり方で失敗するのは、一度だけ実行して一覧を作り、二度と回さない場合です。CTログもDNSも毎週変わります。スクリプトをcronやCIに載せ、差分が出たときだけ担当者へ通知が届く形にしてください。脆弱性の情報収集や優先順位付けまで含めた自動化の範囲は、脆弱性対応の自動化:情報収集・優先順位付け・修正・検証で任せる範囲で工程ごとに分けています。

商用EASMや脆弱性診断へ進む条件:子会社・M&Aと継続監視の要件

子会社や買収した会社のドメインを含めると、起点にするドメイン名そのものが分かりません。商用のEASMの多くは、組織名やドメインの登録情報から関連ドメインを推定する機能を備えており、ここが自前のOSSとの一番の差です。ドメインが数十を超える、または取引先から毎月の監視結果の提出を求められているなら、商用を選びます。

もう1つの分かれ目は、見つけた資産の中身です。EASMで分かるのは「外から見えている」ことまでで、ログイン画面の先にある認可の不備やSQLインジェクションは見えません。持ち主不明のWebアプリや古いCMSが見つかったら、範囲を決めて診断に回します。診断の種類と費用の目安は脆弱性診断とは?種類・費用相場・進め方と外注時の判断基準に、棚卸しで見つかった資産の検査は脆弱性診断・セキュリティ診断で受け付けています。

EASMの導入と運用でよくある質問:無料ツール・頻度・法的な注意への回答

EASMを自社で始めるときに出てきやすい疑問に、11月4日時点の一次情報の範囲で答えます。

EASMとASMは何が違いますか?

経済産業省のガイダンスはASMを「外部からアクセス可能なIT資産」を対象とするプロセスと定義しており、実務上はEASMとほぼ同じ範囲を指します。製品によっては、社内ネットワークの資産まで含むものをASM、インターネット側に限るものをEASMと呼び分けています。比較するときの判断軸は呼び名ではなく、起点(ドメイン名か、組織名か)と、能動的な走査をするかどうかです。

無料のツールだけでEASMはできますか?

発見と生存確認までは、この記事のcrt.sh、subfinder、dnsx、httpxで足ります。Shodanも件数の確認はクレジットを使わずにできます。不足するのは、関連ドメインの推定、結果の差分管理、持ち主への確認の流れです。最初の2つはスクリプトで補えますが、確認の流れは人と手順で作るしかありません。

どのくらいの頻度で実行すればよいですか?

公開の申請窓口があり、新しいサイトが月に数件以下なら四半期に1回で回ります。キャンペーンサイトを頻繁に立てる組織や、開発チームが自分でクラウドに公開できる組織では、週に1回の差分取得が目安です。頻度を上げても確認する人がいなければ意味がないので、担当者が処理できる量に合わせます。

他社のドメインを調べてしまうと問題になりますか?

crt.shやsubfinderのような公開情報の参照は、相手のサーバーに要求を送りません。一方で、httpxやポートスキャンは相手のサーバーへ実際に要求を送るため、許可なく他社の資産へ行えば攻撃の予兆として扱われることがあります。結果に混ざった他社の名前は、能動的な工程へ渡す前に必ず外してください。

見つかった資産はどの順に対応すべきですか?

先に手を打つのは、外部サービスを指したまま使われていないCNAME、外へ開いた管理画面やデータベースのポート、持ち主不明のWebサーバーの順です。どれも攻撃者が最初に試す入口です。既知の脆弱性を抱えた機器が見つかった場合の期限の決め方は、BOD 26-04とは?KEVの是正期限を4変数で決める仕組みが参考になります。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.03 テックブログ ノジマ不正アクセスで約700万件漏えい:対象確認・窓口と乗っ取り注文を止める実装
  2. 2026.10.29 テックブログ ソニー生命の情報漏洩38.5万件|ログインできない理由、再開状況と窓口の電話番号
  3. 2026.11.03 テックブログ クラブツーリズム不正アクセス:約432万件の対象確認と偽メールの見分け方・流出検知の設計
  4. 2026.11.02 テックブログ アララの不正アクセス:メール約7,700万件の持ち出しと契約企業が行うAPIキー再設定・代替送信・連名報告
  5. 2026.11.03 テックブログ Securitize不正アクセス:丸井・PPIHのデジタル社債で漏れた項目と投資家情報の分け方

RELATED POSTS 関連記事

目次