analyzing-phishing-emails

フィッシングメールの分析

メールは複数の主張を積み重ねたものです。誰が送信したのか、どこから届いたのか、リンクは安全なのか。フィッシング分析では、送信者が偽造できない証拠、つまりReceivedチェーン、認証結果、すべてのリンクと添付ファイルの実際の宛先に照らして、それぞれの主張を確認します。Fromヘッダーは表示にすぎず、事実ではありません。誰でもそこに任意のアドレスを入力できます。あなたの役割は、裏付けとなる証拠や反証となる証拠を見つけることです。

使用する場面

• ユーザーから不審なメールの報告があり、判定とIOCが必要な場合
• オフラインで分析する.emlまたは.msgファイルがある場合
• 生のヘッダーを渡され、メッセージがなりすましかどうか尋ねられた場合
• メッセージに、安全なトリアージが必要なリンクや添付ファイルが含まれている場合
• ビジネスメール詐欺、請求書詐欺、取引先なりすましの事案
• ドメインやブランドがユーザーに対してなりすましに使われたか確認する場合

使用しない場面

• 添付ファイルを抽出して実行環境で解析する必要がある場合 — まずここで安全に抽出して無害化し、その後ペイロードをanalyzing-malwareに引き渡します
• フィッシングがすでに成功し、テナント内のメールボックスやOAuthの侵害を追跡している場合 — investigating-m365-entraを使用します
• フィッシングキャンペーンを実施する側であり、分析する側ではない場合 — performing-social-engineeringを使用します
• フィッシングをきっかけに発生した、より広範なインシデントに対応する場合 — responding-to-incidentsを使用します
• 実行環境で解析したペイロードのコールバック通信を分析する場合 — analyzing-network-trafficを使用します

安全な取り扱い — まず最初に行うこと

報告されたメッセージはすべて、現在も有効なものとして扱ってください。ヘッダーを読み違えることではなく、本番環境のメールクライアントでリンクをクリックしたり、自分のホスト上で添付ファイルをダブルクリックしたりすることが危険です。

• メッセージを稼働中のクライアントで開かないでください。攻撃者が制御するリモート画像は開封ビーコンを送信し、リンクを1回クリックするだけで相手の情報収集サーバーに認証情報を送信してしまいます。
• 生のソースのみを使用してください。転送されたコピーではなく、.eml／.msgを使います。転送するとヘッダーが書き換えられ、必要な証拠が失われます。
• 報告書、チケット、チャットに記載する前に、すべてのインジケーターを無害化してください。http → hxxp、. → [.]、@ → [at]とします。たとえば、http://evil.com/loginはhxxp://evil[.]com/loginになります。無害化することで、後から誤ってクリックされるのを防ぎ、リンクのプレビューを行うボットが代わりにリンクを実行するのを防ぎます。
• 抽出や実行環境での解析は、ホスト共有を無効にし、送信通信をシミュレートまたは監視する隔離VMでのみ行ってください。環境の構築についてはanalyzing-malwareを参照してください。

生のメッセージを取得する

画面に表示されるメールはレンダリングされたものです。すべてのヘッダーを含むソースが必要です。

• Outlook／Exchange：.msgとして保存するか、OWAで「メッセージのソースを表示」を使用します。
• Gmail：「原文を表示」→「原文をダウンロード」を選択すると、.emlを取得できます。
• .msg → 読み取り可能な形式：msgconvert sample.msgを実行すると、.eml（RFC822）が生成されます。
• 構造を確認する：emldump.py sample.emlでMIMEパートとインデックスを一覧表示します。emldump.py -s 4 -d sample.emlは、開かずにパート4（添付ファイル）をダンプします。.msgはOLE複合ファイルです。oledump.py（DidierStevens）でストリームを一覧表示できます。
• すべてのヘッダーを表示する：生ファイルの先頭部分を直接読むか、Message Header Analyzer（MHA）／Googleのmha／MXToolbox Header Analyzerに貼り付けて、解析済みのホップテーブルを確認します。

元のファイルはハッシュを計算して変更せずに保管し、コピーを使って作業してください。

受信経路

Received: ヘッダーは、メッセージが通過する各メールサーバーによって追加され、新しいものが上に並びます。下から上へ読みます。一番下の Received が送信元サーバーであり、最も早く、偽造されにくい経由点です。

Received: from mail.contoso.com (mail.contoso.com [203.0.113.9])
    by mx.recipient.com ... ; Tue, 21 Jul 2026 09:14:02 +0000   <- final hop
Received: from smtp.sketchy-vps.ru ([185.220.101.5])
    by mail.contoso.com ...   ; Tue, 21 Jul 2026 09:13:58 +0000  <- origin

• 送信元 IP を追跡する：一番下の経由点にある [bracketed IP] を確認します。位置情報と WHOIS を調べ（whois 185.220.101.5）、レピュテーションを確認し、申告された送信者と照合します。「From: [email protected]」のメールがロシアの VPS から送信されているなら、それが調査結果です。
• 偽造された経由点を見抜く：攻撃者は、信頼できる送信元を装うために偽の Received 行を先頭に追加します。信頼できるのは、信頼するサーバーが追加した経由点だけです。自分の管理下にない最初のサーバーで、信頼は途切れます。ある経由点が、次の経由点の by に記載されていないサーバーを参照している場合、それは捏造されています。
• タイムゾーンと経由時間の異常を確認する：経由点のタイムスタンプは、上に進むにつれて数秒ずつ増加するはずです。負の時間差、数時間の飛躍、または不自然なタイムゾーンの混在は、偽造や不審なインフラを経由したことを示しています。
• 申告された送信者と照合する：送信元ドメイン、その PTR/rDNS、From ドメインが一貫した説明になっているか確認します。フィッシングメールでは、たいてい一致しません。

認証結果

SPF、DKIM、DMARC は、偽造に強い検証方法です。受信サーバーは結果を Authentication-Results に記録します。これを読み、要約を鵜呑みにせず、自分で再検証してください。

Authentication-Results: mx.recipient.com;
  spf=pass (sender IP is 185.220.101.5) smtp.mailfrom=bounce.sketchy-vps.ru;
  dkim=pass header.d=sketchy-vps.ru header.s=selector1;
  dmarc=fail (p=reject sp=reject dis=none) header.from=contoso.com

• SPF が認証するのは エンベロープ 送信者（Return-Path／smtp.mailfrom／MAIL FROM）であり、表示される From ではありません。値の意味は、pass（エンベロープドメインで IP が許可されている）、fail（強制的な -all による拒否）、softfail（~all。不審だが配信されている）、neutral／none（ポリシーがない）です。ドメインのレコードを確認します。dig txt contoso.com を実行し、v=spf1 ... 文字列を読み取ってください。
• DKIM は、選択されたヘッダーと本文に対する暗号署名です。dkim=pass は、メッセージが d= のセレクターにある鍵で署名され、改変されていないことを証明します。重要な確認点はアラインメントです。header.d= は From ドメインと一致していますか？ From: contoso.com を名乗るメッセージが d=mailer-xyz.com から有効な署名を受けていても、contoso からのメールではありません。dkimverify < sample.eml（dkimpy）で再検証し、dig txt selector1._domainkey.contoso.com で鍵を取得してください。
• DMARC は、アラインメント によって SPF／DKIM を表示される From に結び付け、ドメイン所有者の ポリシー を適用します。dmarc=pass となるには、SPF または DKIM が合格し、かつ header.from とアラインメントしている必要があります。ポリシーを確認します。dig txt _dmarc.contoso.com → v=DMARC1; p=reject; ...。p=reject／quarantine が設定されているドメインで dmarc=fail となった場合、所有者はそのメールを信頼しないよう指示しています。
• ARC（ARC-Seal／ARC-Authentication-Results）は、転送によって SPF／DKIM が無効になる場合に、上流での認証結果を保持します。メーリングリストやゲートウェイがメッセージを転送する前の認証結果を確認するために使用します。
• エンベロープ From とヘッダー From：Return-Path／envelope-from はバウンスメールの送信先であり、SPF が検証する対象です。ヘッダーの From: はユーザーに表示されます。フィッシングでは両者が異なるように仕組まれます。見た目は無害な From に、たまたま SPF に合格する使い捨てのエンベロープドメインを組み合わせるのが、典型的な手口です。

表示名のなりすましと類似ドメインの偽装

多くのフィッシングメールは、実在するメールボックスから類似ドメインを使って送信されるため、認証を通過します。そのドメインに対する認証チェックは合格します。偽装は見た目によるものです。

• 表示名のなりすまし：From: "IT Helpdesk" <[email protected]>。名前は自由に設定できるラベルです。実際のアドレスを確認してください。
• 類似ドメイン：cont0so.com、contoso-support.com、contoso.co。実際のドメインと一文字ずつ比較してください。
• ホモグリフ／IDN：ASCII 文字と同じように表示される Unicode 文字（ラテン文字の a に見えるキリル文字の а など）。Punycode でエンコードされたドメインは、ヘッダー内で xn-- のように表示されます（例：xn--cntoso-...）。idn／python3 -c "print('xn--80ak6aa92e.com'.encode().decode('idna'))" でデコードし、表示形式を比較してください。
• Reply-To の不一致：From: [email protected] なのに、Reply-To: [email protected] となっています。返信は気づかれないまま攻撃者に送られます。これは BEC の典型的な特徴です。
• ペイロードのない BEC：電信送金、ギフトカード、W-2 データを求めるテキストだけのメールです。リンクも添付ファイルもなく、サンドボックスで検査するものは何もありません。兆候はすべてヘッダー（Reply-To、送信元、認証）と口実に表れます。

ヘッダーのフォレンジック分析

• Message-ID の妥当性：形式は <unique@sending-domain> です。ドメインは送信インフラストラクチャと一致している必要があります。Message-ID のドメインが送信元と一致しない場合や、ID の形式が不正または重複している場合は、なりすましツールの使用が疑われます。
• X-Originating-IP：一部のウェブメールサービスは、実際のクライアント IP をここに記録します。調査の手掛かりとして利用してください。ただし、クライアント側で設定でき、偽装も可能である点に注意してください。
• X-Mailer／User-Agent：送信に使われたクライアントがわかります。一斉フィッシング用キットやスクリプト（PHPMailer、Python、カスタムメーラー）は、Outlook や送信者が主張する通常の環境とはまったく異なります。
• メーラーのフィンガープリント：正規の一斉送信サービス（SendGrid、Amazon SES、Mailchimp）は、特徴的な X- ヘッダーや Received の経路を追加します。CEO からの「個人的な」メッセージにこれらが含まれているのは矛盾です。

URL の分析

すべてのリンクは、リンク先に関する主張です。アクセスせずに解決してください。

• リダイレクトと短縮 URL を展開する：curl -sI hxxp://bit[.]ly/xyz で bit.ly／t.co を展開する（Location: を読み取り、リダイレクト先にはアクセスしない）か、プレビューサービスを使用します。すべての中継先をたどり、実際のランディングページを特定してください。
• ラッパーによる書き換えをデコードする — 実際の URL はラッパーの中にあります。
  • Microsoft SafeLinks：https://*.safelinks.protection.outlook.com/?url=<encoded>&... — url= パラメーターを URL デコードします。
  • Proofpoint URLDefense：https://urldefense.com/v3/__<encoded>__;... — 公開されている urldefense デコーダーでデコードします（v2 と v3 では方式が異なります）。 これらのラッパーはリンク先を隠します。必ず元の URL を抽出してください。
• クイッシング（QR コードを使ったフィッシング）：ペイロードはリンクではなく画像です。画像部分を抽出し（emldump.py -s N -d）、次のコマンドでデコードします。 zbarimg qr.png または python3 -c "from PIL import Image; import pyzbar.pyzbar as z; print(z.decode(Image.open('qr.png')))"。デコードした URL は、ほかの URL と同じように分析してください。
• 目的 — 情報窃取か配信か：複製されたログインページ（Microsoft、DocuSign、銀行など）へのリンクは認証情報の窃取を目的とし、ファイルをダウンロードするリンクはマルウェアの配信を目的とします。それぞれ必要な対応は異なります。
• 安全に実行して調査する：URL を urlscan.io（標的型フィッシングの場合は、攻撃者に気づかれないよう非公開または限定公開のスキャンを使用してください）またはサンドボックスに送信し、実際のランディングページ、スクリーンショット、配信コンテンツを取得します。IOC セット用に、ランディングページとキットのファイルを抽出してください。

添付ファイルの分析

何かを実行する前に、特定して無害化します。

• ハッシュを計算して特定する：sha256sum att.ext && file att.ext を実行します。emldump.py -s N -d sample.eml > att.ext で抽出し、ダブルクリックは絶対にしないでください。
• よくある配信ラッパー：HTML スマグリング（ブラウザー内で Blob を使ってペイロードを組み立てる .html）、ISO/IMG/VHD（マウントすると MOTW を回避）、LNK ショートカット、スクリプトが埋め込まれた OneNote（.one）、パスワード保護されたアーカイブ（メール本文にパスワードがあるとゲートウェイのスキャンを回避します）。
• ドキュメント／マクロ：exiftool att.docx でメタデータと作成者の指紋を確認します。マクロは oleid att.xls と olevba --deobf att.xls／oledump.py att.doc で確認します。埋め込みオブジェクトは rtfobj att.rtf で確認します。
• 特定後、サンドボックスでの実行、アンパック、C2 の抽出のため、実際のペイロードを analyzing-malware に渡します。このスキルの役割は安全な抽出とトリアージであり、実行ではありません。

IOC の抽出とパッケージ化

ブロックとハンティングに使う、クリーンで無害化されたインジケーター一式を抽出します。

• 送信元インフラ：発信元 IP、エンベロープ From のドメイン、From／類似ドメイン、Reply-To、Message-ID のドメイン、メーラーの指紋。
• URL：ラップされた形式とラップされていない形式、最終ランディングページ、短縮 URL のチェーン、urlscan で見つかったキットのホスト名。
• ハッシュ：すべての添付ファイルと、デコードまたはダウンロードしたペイロードの SHA-256。
• ハンティング用セレクター：メールゲートウェイやほかのメールボックスを検索するための件名、送信者の表示名、本文の指紋。

フィッシングが追跡対象のキャンペーンの一部である場合は、これらを producing-threat-intelligence に渡します。報告書の作成には reporting-security-findings に渡します。

キャンペーンの範囲を特定する

報告された宛先が唯一の受信者であることは、ほとんどありません。対応を終える前に、ほかの受信者も見つけてください。

• M365：すべてのメールボックスを対象に、件名、送信者、URL で Search-UnifiedAuditLog と Content Search／New-ComplianceSearch を検索します。一致するメールは Get-QuarantineMessage／eDiscovery のパージで完全削除するか、隔離します。
• メールゲートウェイ（Proofpoint、Mimecast、Defender for O365）：メッセージトレース／Threat Explorer で送信者のドメイン、URL、添付ファイルのハッシュを検索し、すべての受信者と、クリックまたは返信した人がいるかを特定します。
• 受信者が何らかの操作を行っていた場合、フィッシングが成功した可能性があります。テナント側のハンティング（サインイン、受信トレイルール、OAuth の許可）には investigating-m365-entra を、より広範な対応には responding-to-incidents を使用します。

却下すべき合理化

• 「SPF に合格したので、正規のメールです。」 SPF が認証するのはエンベロープのドメインであり、表示される From ではありません。類似ドメインや使い捨てのエンベロープドメインで SPF に合格するのは、巧妙なフィッシングメールによく見られます。DMARC のアラインメントを確認してください。
• 「DKIM が有効なので、相手からのメールです。」 有効な署名が証明するのは、d= のドメインが署名したということだけです。d= が From ドメインとアラインメントしていなければ、別の誰かが署名しています。確認すべきなのはアラインメントであり、署名の有効性ではありません。
• 「添付ファイルもリンクもないので、無害です。」 BEC や送金詐欺のフィッシングメールには、どちらも含まれないことがあります。武器は口実と Reply-To です。ヘッダーを確認してください。
• 「DMARC に失敗したのに配信されたので、問題ありません。」 配信されたという事実が示すのは、受信側の適用設定であり、メッセージの正当性ではありません。p=reject に対する dmarc=fail は、そのドメインの送信者が信用しないよう伝えているということです。
• 「From アドレスが自社の正規ドメインなので、社内からのメールです。」 From ヘッダーは自由に記述できます。SPF／DKIM がアラインメントしておらず、もっともらしい送信元の経路もなければ、社内に見える From に意味はありません。
• 「リンクをクリックして、どこに行くか確認します。」 クリックすると、認証情報を窃取するサイトで認証してしまうか、ビーコンが発火します。URL の解決には、ヘッダーのみを使うリクエスト、ラッパーのデコーダー、urlscan を使用し、実際のブラウザーは絶対に使わないでください。
• 「ゲートウェイを通過したので、クリーンです。」 ゲートウェイは、類似ドメイン、新しく登録されたインフラ、HTML スマグリング、パスワード保護されたアーカイブを、設計上見逃すことがあります。メッセージが配信されたからといって、検証済みとは限りません。

ATT&CK のカバレッジ

secskills-core/ttp-index.json から生成されています。編集後、python3 scripts/sync_attack.py --write を実行してください。 レポートで引用する前に、ID が現在の ATT&CK リリースに対応していることを再確認してください。

偵察（TA0043）

• T1598 情報を狙ったフィッシング — performing-social-engineering も参照してください

初期アクセス（TA0001）

• T1566 フィッシング — performing-social-engineering も参照してください
• T1566.001 標的型フィッシング添付ファイル — performing-social-engineering、analyzing-malware も参照してください
• T1566.002 標的型フィッシングリンク — performing-social-engineering も参照してください

これらのいずれかに対する検出コンテンツ：engineering-detections。プロアクティブな調査：hunting-threats。侵害後の対応：responding-to-incidents。

参考資料

• analyzing-malware — 添付ファイルのサンドボックスでの実行と C2 の抽出
• investigating-m365-entra — フィッシングが成功した場合のテナント側での脅威ハンティング
• performing-social-engineering — フィッシングキャンペーンの構築（攻撃目的）
• analyzing-network-traffic — 実行したペイロードからのコールバック通信
• producing-threat-intelligence — IOC を追跡対象のキャンペーンに関連付ける
• reporting-security-findings — トリアージと判定の報告書を作成する
• oletools（olevba、oleid、rtfobj）、oledump.py／emldump.py（DidierStevens スイート）、msgconvert（Email::Outlook::Message、Perl）、および exiftool（メッセージと添付ファイルの解析用）
• Message Header Analyzer（MHA）と MXToolbox（Received チェーンの解析、および SPF／DKIM／DMARC レコードの照会用）
• urlscan.io と VirusTotal（URL／ファイルの実行とレピュテーション確認用）
• PhishTool（フィッシングの分析とレポート作成をエンドツーエンドでガイド）