ダークウェブモニタリングとは？必要性・監視対象・検知後の対応を企業向けに解説|セキュリティ対策Lab

投稿日時: 2026年09月27日更新日時: 2026年09月27日

ダークウェブモニタリングとは、ダークウェブや犯罪者が利用するフォーラム、リークサイトなどを継続的に監視し、自社に関係する認証情報、機密情報、ランサムウェアの犯行声明などを検知する取り組みです。

米国CISA、FBI、NSAが共同で公開している「#StopRansomware Guide」では、侵害された認証情報をダークウェブ上で監視するサービスの利用を検討するよう企業へ案内しています。イスラエル国家サイバー局（INCD）も、Darknet上で漏洩認証情報が売買され、クラウド環境への不正アクセスに利用される経路を公的資料で示しています。

ただし、「ダークウェブで自社名を見つけること」自体が目的ではありません。検知した情報が現在も有効か、自社システムから流出したものか、すでに不正利用されていないかを確認し、認証情報の無効化、セッション失効、端末調査、ログ確認などへつなげる必要があります。

従業員600人以上の企業では、利用するSaaS、クラウド、委託先、グループ会社、従業員アカウントが増えるため、自社ネットワークの監視だけでは把握できない情報流出を補完する用途があります。

ダークウェブの仕組みや犯罪者による悪用については既存記事で整理しています。ここでは企業のダークウェブモニタリングに絞り、監視対象、必要性、検知結果の見方、導入後の対応を整理します。

ダークウェブモニタリングとは

ダークウェブモニタリングでは、自社に関連する文字列やデジタル資産をあらかじめ登録し、漏洩情報、売買情報、攻撃者の投稿などに含まれていないかを継続的に確認します。

企業向けサービスでは、Tor上のWebサイトだけを対象とするとは限りません。犯罪フォーラム、ランサムウェアグループのリークサイト、Paste系サイト、Telegramなどのメッセージングサービス、既知の漏洩データセットなどを横断して監視するものがあります。

そのため、実務上は「ダークウェブだけを見るサービス」というより、外部に流出した情報や攻撃予兆を自社環境の外側から探す脅威インテリジェンスの一部として扱う方が実態に近くなります。

主な監視対象は次の通りです。

監視対象	検知したい内容	検知後の主な確認
会社ドメイン	`@example.co.jp`を含むメールアドレス、認証情報	対象アカウントが現役か、同じパスワードを利用していないか
従業員メールアドレス	メールアドレスとパスワードの組み合わせ	パスワード変更、MFA、ログイン履歴
特権・管理者アカウント	VPN、Microsoft 365、Google Workspace、クラウド等の認証情報	即時無効化、セッション失効、操作履歴
APIキー・トークン	GitHub、クラウド、SaaS等のシークレット	キー失効、再発行、利用履歴
自社名・ブランド名	犯行声明、攻撃予告、データ販売	投稿の真正性、社内インシデントとの関連
ドメイン・IP・ホスト名	内部情報、設定ファイル、アクセス情報	情報源と流出経路
機密文書の特徴語	内部文書、顧客情報、設計情報等	本物か、過去流出情報の再掲載か
グループ会社名	子会社・海外拠点に関する漏洩・犯行声明	当該組織のCSIRT・情シスへの確認

監視対象を多く登録すればよいわけではありません。検知した後に担当部署が判断できる単位まで資産を整理しておく必要があります。

ダークウェブモニタリングはなぜ必要か

ダークウェブモニタリングの役割は、社内のEDR、SIEM、メールセキュリティでは見えない「外部で流通している情報」を補完することです。

漏洩した認証情報が初期侵入に使われる

CISA、FBI、NSAの「#StopRansomware Guide」は、侵害された認証情報をランサムウェアの初期アクセス経路の一つとして扱っています。同ガイドは、メール、VPN、重要システムに対するフィッシング耐性のあるMFAに加え、ダークウェブ上の侵害認証情報を監視するサービスの利用検討を挙げています。

英国NCSCも、同センターが対応するインシデントの多くで侵害済みの正規認証情報が利用されていると説明しています。正しいIDとパスワードでログインされると、単純な「ログイン失敗回数」だけでは異常を見つけにくくなります。

ダークウェブモニタリングで先に認証情報の露出を確認できれば、不正利用される前にパスワード変更、セッション失効、トークン再発行などを実施できる場合があります。

自社から直接漏洩していない認証情報もリスクになる

企業メールアドレスが流出する経路は、自社へのサイバー攻撃だけではありません。

従業員が外部のEC、予約サービス、イベントサイト、業務関連サービスなどへ会社メールアドレスで登録していた場合、その外部サービスが侵害されると、会社ドメインを含むメールアドレスが漏洩データに含まれる可能性があります。

セキュリティ対策Labの週刊CSIRTブリーフィング 2026年9月第1週でも、大規模な消費者向けサービスの情報漏洩について、会社メールアドレスで登録していた利用者が確認されるケースを踏まえ、同一・類似パスワードの使い回し確認や、企業アカウント側の認証情報変更を検討する考え方を整理しています。

この場合、会社メールアドレスが漏洩データに含まれていても、「自社システムが侵害された」とは限りません。漏洩元サービス、対象データ、パスワードの利用状況を切り分ける必要があります。

ランサムウェアのリークサイトで自社名が掲載される場合がある

二重脅迫型ランサムウェアでは、攻撃者がダークウェブ上のリークサイトに被害組織名や窃取したとするデータを掲載します。

こうした投稿を早期に把握することは、CSIRTや広報、法務が事実確認を始めるきっかけになります。

ただし、犯行声明は攻撃者側の主張です。

セキュリティ対策Labの2026年6月ランサムウェア被害事例まとめでも、ランサムウェアグループによるリークサイトへの掲載と、実際の情報漏洩が確認された状態を分けています。攻撃者は古いデータを再掲載したり、被害規模を誇張したりする場合があるため、リークサイトへの掲載だけで「情報漏洩が確定した」と判断しません。

ダークウェブモニタリングで何が分かるのか

検知結果は、内容によって意味が異なります。

1. メールアドレスだけが見つかった場合

メールアドレスが外部に出ている事実は確認できますが、それだけで企業アカウントへの侵入が成立するわけではありません。

確認するのは次の項目です。

どのサービスから流出した情報か
パスワードやハッシュが含まれているか
現在も利用中のアカウントか
社内で同じメールアドレス・パスワードを利用しているか
流出後に不審なログインがないか
フィッシングやBECの標的になっていないか

メールアドレスは、フィッシングやパスワードスプレーの対象リストにも利用できます。パスワードを含まない漏洩でも、対象部門への注意喚起やログ監視強化につなげます。

2. IDとパスワードの組み合わせが見つかった場合

現在も有効な認証情報であれば、優先度を上げて対応します。

英国NCSCは、パスワードが侵害されたことを把握または疑った場合は変更するよう案内しています。また、通常と異なるIPアドレス、端末、時間帯、アクセス先などを確認し、懸念があればアカウントをロックまたはリセットし、追加侵害を調査するよう示しています。

企業では、対象アカウントだけでなく、同一パスワードが他サービスで利用されていないかを確認します。

3. InfoStealer由来の情報が見つかった場合

イスラエル国家サイバー局は、クラウド環境の認証情報が窃取される経路として、InfoStealerによるブラウザ保存パスワードや入力情報の窃取を挙げています。

この場合、パスワード変更だけでは対応が不足する可能性があります。

端末上から認証情報が窃取されたのであれば、保存されていたCookie、セッショントークン、クラウド認証情報なども影響を受けている可能性を確認します。

対応対象は、次のようになります。

対象端末をEDRで調査
利用中のセッションを失効
パスワードを変更
APIキーやトークンを再発行
ブラウザに保存された認証情報を確認
同端末から利用していた他サービスを棚卸し
不審なログイン・権限変更・メール転送設定を確認

4. ランサムウェアグループの犯行声明が見つかった場合

まず、社内で把握している障害、不正アクセス、EDRアラート、VPNログ、異常なデータ転送などと突き合わせます。

攻撃者が公開したサンプルが存在する場合でも、真正性を確認する前に「自社の情報が漏洩した」と対外発表するのは避けます。

監視事業者からの通知には、次のような区分があると判断しやすくなります。

自社名のみ掲載
データ窃取量の主張あり
サンプル画像あり
実データの一部公開あり
自社側でも同時期の侵害を確認
第三者調査で真正性を確認

この段階を分けることで、攻撃者の主張と企業側で確認済みの事実を混同しにくくなります。

ダークウェブモニタリングで分からないこと

ダークウェブモニタリングを導入しても、情報漏洩や不正アクセスをすべて検知できるわけではありません。

ダークウェブに出ていない漏洩は検知できない

攻撃者が情報を非公開で販売している場合、限定コミュニティで共有している場合、窃取後すぐに自分で悪用している場合は、監視対象に現れない可能性があります。

「検知されていない」ことは「情報漏洩していない」ことの証明にはなりません。

検知した情報の流出元までは確定できない場合がある

会社メールアドレスとパスワードが見つかっても、自社システムから漏洩したのか、外部サービスから漏洩したのか、従業員端末のInfoStealerから取得されたのかは、検知情報だけでは判断できない場合があります。

社内ログ、EDR、IdP、SaaS監査ログなどと組み合わせて調査します。

古い漏洩情報が再流通する

漏洩データは複製され、複数のフォーラムやデータセットへ転載されます。

同じ認証情報が数年後に再掲載されることもあるため、「初出日時」「過去に検知済みか」「現在も有効か」を確認しないと、同じ事象を新規インシデントとして扱ってしまいます。

攻撃者の主張が事実とは限らない

リークサイトやフォーラムへの投稿は一次情報ではありますが、内容の正確性を保証するものではありません。

犯行声明、販売件数、窃取データ量、侵入経路などを、そのまま企業側の確認済み事実として扱わない運用が必要です。

ダークウェブモニタリングは必要か

ダークウェブモニタリングの必要性は、従業員数だけでは決まりません。ただし、従業員600人以上の企業では、監視対象となるID、SaaS、クラウド、グループ会社、外部委託先が増えるため、導入効果を得られる場面が増えます。

次の条件が複数当てはまる場合は、導入を検討しやすい状態です。

Microsoft 365、Google Workspace、VPN、クラウドを大規模に利用している
多数の従業員アカウントを管理している
国内外にグループ会社がある
顧客情報、決済情報、研究開発情報などを保有している
ランサムウェアのリークサイト掲載を早期に把握したい
役員や管理職を狙った攻撃を監視したい
サプライチェーンや委託先経由の認証情報漏洩を把握したい
SOC、CSIRT、MDRなど通知後に調査する体制がある
インシデント対応時に外部で流通している情報を確認したい

一方、通知を受けても誰が判断するか決まっていない場合は、監視サービスを導入してもアラートが蓄積します。

Googleは個人向けの「ダークウェブレポート」を2026年2月16日に終了しました。セキュリティ対策LabのGoogle「ダークウェブレポート」提供終了の記事で整理した通り、Googleは利用者から「一般的な情報の提示にとどまり、具体的な対処が分かりにくい」とのフィードバックがあったと説明しています。

企業向けモニタリングでも同じ問題が起こります。

「検知しました」という通知だけではなく、どのアカウントを停止するか、どのログを調べるか、どの部門へ連絡するかまで決めておくことで、監視結果を実際の防御へつなげられます。

ダークウェブモニタリングを導入した後の対応フロー

導入時には、監視対象と一緒に対応フローを決めます。

1. 検知内容を分類する

まず情報の種類を分けます。

メールアドレスのみ
パスワードを含む認証情報
InfoStealerログ
Cookie・セッショントークン
APIキー・クラウドシークレット
内部文書
顧客・従業員情報
ランサムウェアの犯行声明
攻撃予告・アクセス販売

すべてを同じ優先度にしません。

2. 現在も有効な情報か確認する

認証情報であれば、アカウントが現役か、パスワードが現在も使われているかを確認します。

ただし、不審な認証情報を実際のサービスへ入力して有効性を試すような確認方法は避けます。ID管理システム、パスワード変更履歴、管理者情報など、自社で管理している情報を使って確認します。

3. 高リスクな認証情報を無効化する

管理者、VPN、クラウド、メール、GitHubなどの認証情報で現在利用中の可能性がある場合は、パスワード変更だけでなく、既存セッション、APIキー、トークンの失効範囲も確認します。

CISAは、侵害済み認証情報への対策としてMFA、IAM、侵害認証情報の監視を組み合わせています。英国NCSCも、侵害が疑われるアカウントについてリセット・ロックと追加調査を案内しています。

4. ログで不正利用の有無を調査する

次のログを確認します。

IdPの認証ログ
Microsoft 365・Google Workspaceの監査ログ
VPNログ
クラウド操作ログ
EDR
メール転送ルール
特権ID利用履歴
GitHub等の開発基盤ログ

「漏洩情報を見つけた」で調査を終えず、その情報がすでに使用された形跡がないか確認します。

5. 漏洩元と影響範囲を特定する

外部サービスの漏洩なのか、自社端末のマルウェア感染なのか、自社システムへの侵害なのかで、対応範囲は変わります。

特にInfoStealerが疑われる場合、1つのパスワードだけでなく、その端末から利用していた複数サービスへ調査対象を広げます。

6. 再発防止へ反映する

検知結果を次の対策へ反映します。

フィッシング耐性のあるMFA
パスキー
パスワード再利用の防止
特権IDの分離
セッション有効期間の見直し
EDRによるInfoStealer検知
SaaS利用ルール
会社メールアドレスの外部サービス利用ルール
APIキー・シークレット管理
SIEMの検知ルール

セキュリティ対策Labの事例から見る「監視後の判断」

ダークウェブモニタリングでは、見つけた情報の量より、検知後の事実確認が実務上の差になります。

犯行声明を見つけても「被害確定」としない

セキュリティ対策Labでは、ランサムウェアグループのリークサイトを継続的に確認していますが、記事では「攻撃者が主張している状態」と「企業が情報漏洩を確認した状態」を分けています。

2026年6月のランサムウェア事例では、Qilinが武蔵野大学への攻撃を主張し、内部資料とみられるサンプルを掲載していました。一方、記事掲載時点で学生・教職員の個人情報までは確認しておらず、攻撃者の主張と確認済み情報を分離しました。

ダークウェブ監視サービスを利用する企業でも、この判断基準は同じです。

通知を受けた時点では「外部で自社に関する投稿を検知した」と扱い、社内ログ、対象データ、公式な調査結果を確認してから事実認定します。

ダークウェブに掲載されていなくても監視を続ける場合がある

精電舎電子工業のランサムウェア最終報告では、Active Directoryサーバー上のデータが外部転送されたと判断された一方、記事執筆時点でダークウェブへの掲載は確認されておらず、監視が継続されています。

この事例は、「ダークウェブに出ていない＝外部流出していない」ではないことを示します。

フォレンジック調査で外部転送が確認されている場合、リークサイト掲載の有無とは別に情報漏洩対応を進めます。ダークウェブモニタリングは、侵害調査を代替するものではなく、その後の公開・販売・二次悪用を把握するための追加監視として位置付けられます。

認証情報は見つけた後の対処速度が影響する

2026年には、認証情報の漏洩を起点とする国内インシデントも複数確認されています。

イノベーションのGitHub不正アクセス事案では、GitHubの認証情報が漏洩し、不正アクセスによって62,691名分の個人情報漏洩が確認されました。

ダークウェブモニタリングですべての認証情報漏洩を先に検知できるわけではありません。しかし、認証情報やシークレットが外部へ出た兆候を得た場合、調査開始までの時間を短縮できれば、不正利用の有無を確認し、キーやセッションを早く失効させる余地があります。

ダークウェブモニタリングサービスの選び方

企業向けサービスを比較する場合は、検索できる件数より、監視範囲と通知後の運用を確認します。

比較項目	確認したい内容
情報源	Tor、犯罪フォーラム、リークサイト、Telegram、Paste、漏洩DBなど、何を対象にするか
認証情報	メール・パスワードだけか、InfoStealerログやトークンまで対象か
ランサムウェア	リークサイトの新規掲載と更新を追跡できるか
監視単位	ドメイン、子会社、ブランド、役員名、メールアドレス等を登録できるか
重複排除	過去流出情報の再掲載と新規漏洩を区別できるか
コンテキスト	初出日時、情報源、関連する侵害、信頼度などを確認できるか
通知速度	高リスク情報をどの程度の時間で通知するか
優先度付け	特権ID、一般社員、退職者などを分けられるか
SOC連携	SIEM、SOAR、チケット管理システムへ連携できるか
アナリスト支援	真正性や影響範囲の分析を支援するか
グループ会社	複数ドメイン・海外子会社を一元管理できるか
データ管理	検知した個人情報・認証情報をどこに保存し、誰が閲覧できるか

従業員600人以上の企業では、全社員分のアラートを情報システム部門が手作業で確認する運用は負荷が高くなります。

特権アカウント、役員、VPN、クラウド管理者などを高優先度にし、一般アカウントはIdPやSOARと連携して対応を標準化できるかを確認すると、運用負荷を見積もりやすくなります。

導入時に決めておきたい運用ルール

ダークウェブモニタリングを契約する前に、次のルールを決めます。

監視するドメイン・子会社・ブランド
特権アカウントの定義
役員・重要人物を監視対象に含めるか
どの情報を重大アラートとするか
夜間・休日の通知先
認証情報を強制失効する条件
端末調査へ移行する条件
CSIRTへエスカレーションする条件
法務・広報・個人情報保護部門へ連絡する条件
攻撃者の犯行声明を社外へ説明する際の表現
誤検知や過去情報をクローズする方法
検知データの保存期間とアクセス権限

自社担当者がダークウェブへ直接アクセスし、漏洩データをダウンロードして真正性を確認する運用は避けた方が管理しやすくなります。マルウェア、違法コンテンツ、窃取された個人情報、攻撃者との接触などを扱う可能性があるためです。

必要な情報は、専門事業者の分析結果や法的・セキュリティ上管理された調査環境を通じて確認します。

情報システム部門・CSIRTが確認したいポイント

ダークウェブモニタリングを導入済み、または検討している企業は、次を確認すると運用上の不足を見つけやすくなります。

自社とグループ会社の全ドメインを監視対象として把握しているか
退職者・休眠アカウントを識別できるか
特権ID、VPN、クラウド管理者を高優先度で扱っているか
認証情報検知時にパスワード変更だけでなくセッション失効まで実施できるか
InfoStealer由来の場合に対象端末まで調査できるか
IdP、Microsoft 365、Google Workspace、VPNのログをすぐ確認できるか
ランサムウェアの犯行声明と確認済みの情報漏洩を区別して報告しているか
過去流出情報の再掲載を新規インシデントと区別できるか
外部サービスから会社メールアドレスが漏洩した場合の対応基準があるか
アラートをSOC、CSIRT、情シスのどこが受けるか決まっているか
高リスクアラートの初動時間を定めているか
検知後の調査結果をIAM、EDR、SIEMの改善へ反映しているか

ダークウェブモニタリングの評価は「何件見つけたか」ではなく、「有効な認証情報や自社データを見つけた際に、侵害前または被害拡大前に対応できたか」で判断します。

ダークウェブモニタリングとは？必要性・監視対象・検知後の対応を企業向けに解説

ダークウェブモニタリングとは