what-leaked-about-you

あなたについて漏えいした情報

漏えいデータは、ほかの方法では簡単に答えられない問いへの手がかりになります。それは、この人物が実際にどのサービスを利用していたか、という問いです。通常、このサービス一覧は記録内の認証情報よりも調査にとって価値があります。そして、認証情報には決して触れてはいけません。漏えいデータがどれほど公開されていたとしても、漏えいしたパスワードを使うことは不正アクセスです。

記録に実際に含まれるものと、重要な情報

漏えい記録は、サービスのユーザーテーブルから取り出した1行です。一般的なフィールドには、メールアドレス、ユーザー名、パスワードハッシュ（悪質なケースでは平文）、登録日、最終ログイン日時、登録時のIPアドレス、表示名、生年月日、住所、秘密の質問、その他サービスが収集していた情報が含まれます。

どの場合も、認証情報よりメタデータのほうが重要です。

フィールド	重要な理由
サービス名	そのサービスに登録していたという事実です。ほかの方法で確認するのが難しい事実です
登録日	IDの時系列を特定できます。複数サービスで登録時期が重なっていると、アカウント同士を関連付けられます
記録内のユーザー名	これまで把握していなかったハンドル名です。そのまま hunt-a-handle に使えます
登録時または最終ログイン時のIPアドレス	おおまかな位置情報を把握でき、さらに有用なのは、ホスティング環境か一般家庭の回線かを分類できることです
表示名、生年月日、住所	別の情報と照合するための属性です。決して確定情報として扱わないでください
パスワードのパターン	分析上の関連付けを示す証拠です。ログインフォームに入力してはいけません

各フィールドの解釈について： reference/record-fields.md。

情報源の選び方

手元にあるもの	利用するサービス	理由
メールアドレスがあり、サービス一覧を知りたい	Have I Been Pwned	内容が精査・重複排除されており、侵害元とデータの種類が分かります。認証情報は返しません
すでに所持しているパスワード（自分のもの、または調査対象範囲内のもの）	HIBP Pwned Passwords range API	パスワードを開示せずに、流通しているかどうかを確認できます
実際のフィールド値が必要、またはユーザー名、電話番号、IPアドレス、氏名で検索したい	API キーが必要な商用サービス	メンバーかどうかを検出するだけでなく、記録そのものへとたどる唯一の方法です
現在流通している特定のダンプ	find-leaks-in-the-wild	ペーストサイト、フォーラム、チャンネルを対象に、インデックスに登録される前に探します

Have I Been Pwnedは、まず最初に利用するサービスです。精査されたサービスであり、読み込み前に侵害が検証され、データの種類にもラベルが付けられるため、検索結果には意味があります。メールアドレスでのウェブ検索は無料です。API は API キーが必要で、プログラムからの検索やドメイン全体の確認が可能です。意図的にパスワードは提供しません。

Pwned Passwordsは、その仕組みこそが重要なので、きちんと理解しておく価値があります。パスワードの SHA-1 ハッシュをローカルで計算し、ハッシュの先頭5文字の16進数だけを range エンドポイントに送信すると、その接頭辞と一致するすべてのハッシュ接尾辞と出現回数が返されます。照合はローカルで行います。サービス側は、どのパスワードについて問い合わせたかを知ることはありません。この仕組みなら、正当に所持している認証情報を安全に確認でき、自己監査やクライアントの修正作業に適したツールです。

API キーが必要な商用サービスには、よく使われる DeHashed、IntelX、Snusbase があります。それぞれの違いは次のとおりです。

• 多様な検索条件を使った記録単位の検索で、実際のフィールド値が返されます。これが関連付けを進めるための仕組みです。メールアドレスだけでなく、ユーザー名、電話番号、IPアドレス、氏名でも検索できます。
• コーパスの網羅性と精査の度合いはトレードオフです。より広範なコーパスはコンボリストを多く取り込むため、不要なデータも増えます。精査されたコーパスでは情報を見落とすことがあります。利用する情報源がどちらに当たるのか把握しておきましょう。
• ユーザーテーブルを解析するのではなく、ドキュメント、ペースト、ダークウェブのページ、漏えいファイルをインデックス化するサービスもあります。漏えいデータベースというより、漏えい情報を対象にした検索エンジンに近いものです。

アクセス方式と対象範囲の比較： reference/source-catalogue.md。

例外のないルール

漏えいした認証情報を使って、何かに認証しないでください。「アカウントが存在することを確認する」ためであっても、テストアカウントであっても、対象者のアカウントで、クライアントから口頭で許可されていても同じです。クレデンシャルスタッフィングは、ほとんどの法域でコンピューターの不正使用に関する法律上の不正アクセスに該当します。また、パスワードが公開されていることは弁護の根拠になりません。../../ETHICS.mdを参照してください。

関連する行為にも同じことが当てはまります。パスワードリセットを試みたり、復元した秘密の質問への回答を使ったり、パスワードが別のサービスでも使い回されているか確認するために試したりしないでください。パスワードの使い回しは、すでに手元にあるデータから推測するものであり、試して確かめるものではありません。

本当に重要な着眼点：サービスの列挙

漏えいリストをアカウントマップとして活用してください。あるメールアドレスがゲームフォーラム、フィットネスアプリ、地域の出会い系サービスに登場すれば、調査対象となるプラットフォームが3つ、登録日が3つ、そして多くの場合、ユーザー名も3つあることが分かります。それぞれがhunt-a-handleの手がかりになります。サービス自体から、その人物の職業、地域、言語、関心に関する兆候を把握できます。こうした情報は、プロフィールページからは得られません。

パスワードのパターンは、適切に扱えば人物同士を結び付ける証拠になります。異なる身元情報を持つ2つのレコードに、同じ特徴的なパスワード――長く、辞書に載っておらず、明らかに個人的な文字列――が含まれていれば、それは意味のある相関関係です。分析上の所見として記録し、メモには文字列自体を伏せるか、ハッシュ化してください。一般的なパスワード（password1、キーボードのキーを順に打ったもの、サッカーチーム名など）は何も結び付けません。何千人もの人が使っているからです。重要なのは特徴の強さであり、証拠となるのは偶然の一致であって、認証情報ではありません。

ハッシュは対象外です

レコードには、ハッシュが含まれていることがよくあります。古い漏えいデータではMD5やソルトなしのSHA-1、新しいデータではソルト付き方式や専用のパスワードハッシュが使われています。サービスがハッシュ化せずに保存した平文や、誰かが不適切な方法を選んだことで可逆暗号化されたデータを目にすることもあります。

ハッシュの種類を記録してください。漏えい時期を特定でき、サービスのセキュリティ体制を把握できます。これはデューデリジェンスにおいて本当に役立つ情報です。その後は作業を止めてください。ハッシュをクラックすると、使用が許されない認証情報が得られるため、この作業に正当な成果はありません。例外は、パスワードの保有者がクライアントであるセルフ監査または許可を受けたセキュリティ評価です。その場合でも、クラックせずにレンジAPIで答えが得られます。

うまくいかないケース

• コンボリストの混入。 広く出回っている大規模な「漏えいデータ」の多くはコンボリストです。複数の情報源から集めた認証情報を重複排除し、並べ替え、出所情報を取り除いたものです。コンボリストに該当する情報があっても、その組み合わせがどこかに存在したことが分かるだけで、どのサービスに由来するかは分かりません。これは、そもそもの目的であったサービスの特定に役立つ価値を損ないます。
• 再利用された偽の漏えいデータ。 古いデータが新しい名前を付けて再包装され、新規データとして販売されることがあります。「漏えいデータ」の中には、完全な捏造や、ハッキングと称して販売された公開プロフィールのスクレイピングデータもあります。疑われている情報源がインシデントを公表したことがあるか、また記録の構造がそのサービスで保存されていても不自然でないものかを確認してください。
• 漏えい発生日は流出日ではありません。 重要な日付は、データが取得された日、初めて出回った日、情報源に取り込まれた日の3つです。それぞれ何年も離れていることがあります。「X年付の漏えいデータに含まれていた」というのは、そのアカウントがX年より前に存在したことを示すだけで、その時点で利用されていたことを示すわけではありません。
• 見つからなくても何も証明できません。 どのデータセットにも見つからない場合でも、その人物が利用するサービスで漏えいがなかったとは限りません。漏えいが公表されていない場合や、利用している情報源に含まれていない場合もあります。
• スクレイピングと漏えいの混同。 公開プロフィールをスクレイピングして作成したデータセットは、侵害の証拠ではありません。それを漏えいとして報告するのは事実誤認であり、レポートの信頼性を損ないます。
• 古い情報の誤った帰属。 メールアドレスや電話番号は使われなくなり、別の人に再割り当てされることがあります。10年前の記録は、まったく別の人物についてのものかもしれません。
• ベンダー間の重複を裏付けと誤認。 2つの商用サービスで一致が頻繁に見られる場合、同じダンプを取り込んでいる可能性があります。

信頼度の評価

• 確認済み — 検証と漏えい元の特定が行われた精選済みの情報源に記録があり、フィールドの構造が名称の示すサービスと一致し、記録内の別の識別子でも独立して裏付けられています。
• 可能性が高い — 信頼できる商用データセットに記録があり、名称の示すサービスへの帰属が明確で、フィールドの整合性も取れています。
• 未確認 — コンボリストで見つかった情報、出所不明のダンプ、または裏付けとなる識別子がない単独の記録です。該当する情報が見つかった事実を報告し、情報源の帰属先が不明であることを明記してください。
• 否定 — 疑われている情報源に妥当なインシデントがなく、フィールドがそのサービスで収集される情報と一致しない、または公開情報のスクレイピングデータに漏えいというラベルを付け直したものです。

記録だけでなく、漏えいそのものの信頼度を評価してください。漏えい元が適切に特定されたデータなら、その中のすべての記録の信頼性が高まります。匿名の寄せ集めなら、すべての記録の信頼性が低くなります。

実例

[email protected] を使用するクライアントのセルフ監査を行います。HIBP では4件の漏えいが見つかりました。そのうち1件は数年前の大規模なフォーラムでの漏えいで、データの種類としてメールアドレス、ユーザー名、IP アドレス、パスワードハッシュが記載されています。

その漏えいデータに含まれるユーザー名は merce_ada です。クライアントは以前それを使っていたことを忘れていました。そのハンドルを hunt-a-handle で調べたところ、クライアント自身もまだ公開状態だと知らなかった、現在も利用可能なアカウントが2件見つかりました。これがこの調査で最も価値のある成果であり、認証情報とは無関係です。

行き止まりの例：ある商用情報源から、ある小売業者に帰属するとされる5件目の「漏えいデータ」が返され、そこには自宅住所が含まれていました。その小売業者はインシデントを公表したことがなく、フィールドの配置も小売業者の注文テーブルには見えず、同じ住所が2件のデータブローカーの記録にも含まれていました。漏えいデータと偽ってラベルを付け直された、アグリゲーターによるスクレイピングデータと判断しました。判断の根拠を記録したうえで、レポートから除外しました。

修正対応：クライアントが現在も使っているパスワードは Pwned Passwords のレンジ API で照合するため、パスワードが端末の外に出ることはありません。どの記録に含まれる認証情報も、いかなる場所でも使用しません。

ピボット

新しいセレクター	スキル
レコードから復元したユーザー名	hunt-a-handle
追加のメールアドレス	what-an-email-reveals
レコードに含まれる電話番号	whose-number-is-this
登録時の IP アドレス	find-exposed-servers
氏名、生年月日、住所のフィールド	find-anyone, dig-through-data-brokers
多数のレコードにまたがる企業ドメイン	x-ray-a-company
流通しているダンプそのもの	find-leaks-in-the-wild
エンティティマップとしてのサービス一覧	graph-the-network

法的事項と取り扱い上の注意

漏えいデータの保有は規制の対象であり、ほとんどの OSINT 素材よりも厳しく規制されています。 GDPR と英国のデータ保護法では、漏えい記録は個人データであり、多くの場合は特別カテゴリーのデータです。その処理には、適法な根拠、明確な保管期間、そしてデータ最小化を実証できることが必要です。一部の法域では、特定の盗難データを保有すること自体が、入手方法にかかわらず犯罪とみなされます。複数の商用サービスでは、ライセンスによってデータの用途を特定の目的に制限しています。結果をクライアント向けレポートに記載する前に、利用規約を確認してください。

実務上は、目的に必要な最小限のフィールドだけを取得し、認証情報は一切保持せず、ケース資料は保存時に暗号化してアクセスを記録し、最初に決めたスケジュールに従って削除してください。対象者本人のデータについて本人のために作業している場合、それが最も問題の少ない立場であり、パスワードを試すことが許される唯一の立場です。