what-an-email-reveals

メールアドレスから分かること

メールアドレスは通常、調査において最も価値の高い識別子です。名前、ドメイン、アカウントの利用履歴、情報漏えいの痕跡を含んでいるためです。初心者が陥りがちな誤りは、そのアドレスが存在することを証明しようとすることです。存在の有無は最も興味を引かない要素であり、受動的に確かめるのが最も難しく、それを確かめる手法は身元が明らかになります。まず構造と痕跡を調べ、検証できれば追加の収穫と考えましょう。

調査手法として、対象者にメールを送信してはいけません。

ステップ 1 — 許可された範囲

../../ETHICS.mdを読みます。対象者、目的、範囲内の識別子、範囲外の行為、適用される法域を書き出します。SMTPでのやり取り、パスワードリセットのフロー、サインアップフォームを使った列挙など、対話的な調査が許可されているか、あらかじめ判断します。通常は許可されていません。以下の手順は、別途明記されていない限り、すべて受動的なものです。

完了条件：調査範囲を書き出し、対話的な調査を行うかどうかを記録していること。

ステップ 2 — 解析と検証

「メールアドレスの検証」と呼ばれるものは、3種類あります。これらは互換性がありません。

方法	確認できること	コスト
構文	文字列がメールアドレスとして成立する可能性があること	無料、受動的。メールボックスの存在は何も証明しません
ドメイン／MX	ドメインが存在し、メールを受け付けること	無料、受動的、dig MX example.com
SMTP RCPT TOプローブ	サーバーがメールボックスの存在を示すこと	対話的。ブロックされたり、嘘の応答を返されたりすることが多く、ログにも残ります

最初の2つを行います。3つ目、つまりSMTPセッションを開始してRCPT TOを発行し、サーバーが宛先を受け付けるか確認する方法は、自分のIPアドレスから対象者のメールインフラと直接やり取りすることになります。ログに記録され、自分のアドレス範囲がブロックリストに追加される可能性があります。また、全受信アドレスを受け付けるドメインでは無意味です。すべての宛先を受け付けるため、どのアドレスも「存在する」ことになるからです。グレイリスティング、ターピッティング、受け付けてからバウンスさせるポリシーでも、同じく役に立たない結果になります。サードパーティの検証APIも、ほとんどは同じプローブをラップしているだけです。露出先がベンダーに移るだけで、精度の限界は変わりません。

次に、ローカルパートを解析します。first.last、flast、firstl、f.lastはそれぞれ名前を示唆しており、企業ドメインでは全社共通の命名規則を示している場合もあります。reference/corporate-formats.mdを参照してください。

Gmailの正規化は重要です。 Gmailはローカルパートのドットと、+以降のすべての文字を無視します。[email protected]、[email protected]、[email protected]は、同じメールボックスを指します。これにより、2つの情報漏えいデータで異なるように見えるアドレスが、同じ人物のものだと分かることがあります。また、+tagには、そのアドレスを登録したサービス名が含まれていることが多く、対象者がどのサービスにアカウントを持つかを示す情報を無料で得られます。すべてのプロバイダーがこの動作をするわけではないため、決めつける前に確認してください。

完了条件：アドレスを有効／無効／不明に分類し、正規化した形式を記録し、名前の仮説を書き出していること。

ステップ 3 — Gravatar

Gravatarは、小文字化して前後の空白を削除したアドレスのMD5ハッシュを使い、アドレスと公開アバターを関連付けます。ハッシュを計算してアバターをリクエストします。画像が返されれば、そのアドレスがサービスに登録されていたことを意味します。関連付けられた公開プロフィールには、表示名、所在地、他のアカウントへのリンク、他のプラットフォームで認証済みのアカウントが掲載されている場合があります。

printf '%s' "[email protected]" | tr 'A-Z' 'a-z' | md5sum

無料で、受動的で、キーも不要です。アバターをfind-the-original-imageに通します。デフォルトの代替画像が表示された場合は、「アドレスが無効」ではなく「Gravatarなし」として扱ってください。

完了条件：Gravatarの有無を確認し、プロフィールに含まれる項目を記録していること。

ステップ 4 — このアドレスはどこに登録されているか

率直に言えば、メールアドレスによる信頼性の高いアカウント列挙は、オラクル問題です。パスワードリセットやサインアップのフォームは、そのアドレスが登録済みかどうかを明らかにします。だからこそ、それらを自動化するツールが存在するのです。そして、だからこそ、この行為は対話的で、利用規約に違反することも多く、通知が送られる可能性もあります（リセットをリクエストすると、本人にメールが届く場合があります）。リスクとして明示し、明確に許可を得るか、実行しないでください。

コストのかからない受動的な代替手段：

• アドレス全体を引用符で囲み、ローカル部だけでも google-like-a-spy で検索します。履歴書、カンファレンスのプログラム、メーリングリストのアーカイブ、WHOIS の履歴、コミット済みの設定ファイルには、メールアドレスが数多く含まれています。
• what-leaked-about-you を実行します。漏えいデータに含まれていることは、「この人物はどのサービスを使っていたか」という問いに対する最善の答えであり、対話的ではなく過去の記録に基づいています。
• ローカル部をユーザー名の候補として hunt-a-handle に渡します。
• secrets-in-git-history を使い、コミットメタデータ内のアドレスをコードホスティングサービスで検索します。

完了の条件 サービス一覧がまとまり、各項目の来歴に「受動的」または「対話的」の別が記されていることです。

ステップ 5 — メッセージがある場合はヘッダーを読む

正当にメッセージを所持している場合に限ります。メールが単なる検索キーではなく、証拠となるのはヘッダーです。

Received: チェーンは下から上へ読みます。最下部が最初のホップであり、送信プラットフォームによって削除されていなければ、送信元のホストもそこに記録されています。信頼できる最初のサーバーより下にある情報は、すべて丸ごと偽造できます。

• Message-ID — ドメイン部分とIDの形式から、表示されているヘッダーが装飾的なものでも、送信プラットフォームやメールクライアントを特定できることがよくあります。
• Authentication-Results — 受信サーバーによるSPF、DKIM、DMARCの判定です。DKIMのpassはヘッダーブロック内で最も強い情報です。内容に対する暗号署名であるため、転送に関する主張があっても有効性が保たれます。
• X-Mailer / User-Agent — クライアントのフィンガープリントです。一括メール送信ツールでは、そのまま残されていることがよくあります。
• Return-Path と From の違い — メーリングリストでは通常のことですが、個別のやり取りでは疑わしい兆候です。

フィールド別ガイド： reference/header-fields.md。

完了の条件 送信元のインフラが特定されている、または明示的に復元不能と記されていることです。

うまくいかないケース

• キャッチオールドメインでは検証が完全に無意味になります。 すべてのアドレスが有効と判定されます。自分で作ったアドレスを試して検出してください。ランダムな文字列が有効と判定されるなら、そのドメインから得られる結果はすべて無意味です。
• 使い捨てアドレスサービスと転送サービス。 使い捨てドメインは、そのアドレスが継続利用を想定していなかったことを意味します。リレーやエイリアスサービス（プロバイダー発行のプライベートリレーアドレスを含む）は、目に見えるアドレスが、確認できないメールボックスを覆い隠していることを意味します。どちらもアドレスから得られる情報には限界があります。何時間も費やす前に、早めに見分けてください。
• 役割用アドレス（info@、sales@、admin@）は、個人ではなく役割に紐づいています。これを個人のものと誤認するのは、メールOSINTで最もよくある重大な誤りです。発見事項らしく見えるため、報告書にも残ってしまいます。
• 推定したアドレスは仮説です。 会社のパターンから [email protected] を導き出しても、妥当そうなアドレスが得られるだけで、実在するとは限りません。必ず推定と記載してください。
• 漏えいデータは現在の所有者を証明するものではありません。 アドレスは使われなくなったり、プロバイダーによって再利用されたり、同じ会社の新しい従業員に割り当てられたりします。
• 転送は、ひと目では偽造と見分けがつきません。 メーリングリストやセキュリティゲートウェイは、改ざんのように見える形でヘッダーを書き換えます。

信頼度の評価

• 確認済み — そのアドレスからの DKIM 検証に合格したメッセージ、対象者が管理する情報源で対象者自身が公開したアドレス、または別途確認済みの本人と一致する認証済み Gravatar プロフィールがある場合です。
• 可能性が高い — MX が有効で、裏付けとなるセレクターとともに情報漏えいデータに含まれ、ローカル部が対象者の名前のパターンと一致する場合です。
• 未確認 — 企業の形式から推測した場合、または別の情報源がないまま、単一のアグリゲーターやコンボリストで見つかった場合です。
• 棄却 — 裏付けとなる証拠のないキャッチオールドメインだと判明した場合、関連する活動がない既知の使い捨てドメインの場合、またはドメイン以外に根拠がないまま個人に紐付けられた役割アドレスの場合です。

実例

[email protected] が与えられたとします。dig MX を実行するとホスティングプロバイダーのレコードが返されます。つまり、そのドメインはメールを受信できます。Gravatar にはアバターがなく、プロフィールへのピボットはありません。

カンファレンスの PDF にある従業員のアドレスは t.mwangi@ と s.aldridge@ の 2 件で、命名規則は 名のイニシャル.姓 です。このため、j.okonkwo@ は構造上の一貫性があります。これは形式に関する証拠であり、その人物の実在を示す証拠ではありません。SMTP プローブは実行しません。ここでは対話的な手順は対象外です。

行き詰まった点は、what-leaked-about-you でこのアドレスを検索しても何も見つからず、当初は「実在するユーザーではない」と思われたことです。コードホスティングサイトのコミットから復元した、Gmail の正規化済み個人用アドレスを使って再検索すると、3 件の情報漏えいが見つかりました。そのうち 1 件は、ハンドル sunfish_ada を使う開発者フォーラムでした。このハンドルを hunt-a-handle で調査します。企業アドレスの評価は推定のままですが、個人用アドレスは調査に使うセレクターです。

ピボット

新しいセレクター	スキル
ローカル部または Gravatar から得た名前	find-anyone
ユーザー名としてのローカル部	hunt-a-handle
メールドメイン	who-owns-this-domain、recon-a-domain-passively
企業ドメインから判明した雇用主	x-ray-a-company
情報漏えいへの出現	what-leaked-about-you
コミットや設定ファイル内のアドレス	secrets-in-git-history
ヘッダーから得た送信元 IP	find-exposed-servers
Gravatar またはプロフィールのアバター	find-the-original-image
ダンプやチャンネルに投稿されたアドレス	find-leaks-in-the-wild

法律および利用規約に関する注意

SMTP プロービングやパスワードリセットを使ったアカウント列挙は対話的な行為であり、利用規約で禁止されていることが多く、法域によってはシステムへの不正な問い合わせと見なされる可能性があります。実施する前に、書面による許可を得てください。GDPR および英国のデータ保護法では、メールアドレス自体が個人データに当たります。目的の達成に必要な情報のみを収集し、暗号化して保存し、案件ファイルに削除日を設定してください。保有するメッセージの内容には、OSINT の調査目的とは別に、守秘義務や秘匿特権に関する義務が適用されることがあります。

ステップ 6 — 報告

write-the-intel-brief を実行します。有効性とその確認方法、ドメインがキャッチオールかどうか、パッシブ／インタラクティブの区別を明記したサービス一覧、情報漏えいの状況、信頼度評価を添えた本人特定の内容を記載してください。

完了条件 — すべてのアドレスに観測済みまたは推定のいずれかが記され、推定されたアドレスを事実として記述していないこと。