フィッシング対応：最初の報告から復旧確認まで、はい・いいえで進むプレイブック。

最初の質問は「クリックしましたか」だけではありません

フィッシングの報告は、メールの遮断だけで終わることもあれば、セッションの窃取、遠隔操作ツールの導入、不正な振込先への送金につながることもあります。メールの削除で対処できるのは、その一部です。

これは新たな侵害を報じる記事ではなく、繰り返し利用できる対応プレイブックです。図は下記の資料を参考にSecOpsNomadが作成した独自の判断フローです。主要な分岐を扱いますが、すべての環境や事象を網羅するものではありません。組織のインシデント対応権限と、各サービスの手順に従ってください。

該当する分岐をすべて確認します。「いいえ」には根拠が必要です。「不明」は未完了の調査項目です。 通常のリンクをクリックしなくても、返信、QRコード、電話、OAuth同意、振込先変更による被害があり得ます。サイトの分類タグとは別に、ID／IAM担当と経理担当も対応責任を持ちます。

まずここから：最初の1時間

初めて対応する方は、この順番で進めてください。詳しい対応は、このあとの各セクションで行います。例はMicrosoft 365ですが、ほかのメールシステムにも同等の機能があります。

1. 0〜5分：報告者にお礼を伝え、証拠を残す。 Outlookの「Report」ボタンで報告してもらいます（社内の手順で決まっていれば添付ファイルとして転送）。クリック、返信、注意喚起のつもりでの同僚への転送はしないよう伝えます。
2. 5分：案件を作る。 送信者、件名、受信時刻、報告者、報告者がそのメールに対して何をしたかを記録します。
3. 5〜15分：責めずに何があったかを聞く。 クリックした、QRコードを読み取った、パスワードを入力した、MFAの要求を承認した、添付ファイルを開いた、返信した、電話をかけた、のどれか。どの端末でか。
4. 15分：パスワードを入力した、またはMFAを承認した場合は、今すぐアカウントを守る。 ほかの何よりも先に、セッションを取り消してパスワードを再設定します（セクション2）。
5. 20分：すべてのコピーを探す。 ExplorerやMessage traceで、何人に届いたかを確認します（セクション1）。
6. 30分：コピーを削除し、送信者やリンクをブロックする。 ブロックには見直し日を付けます。
7. 35分：ほかにクリックした人を探す。 クリックの記録を確認し、受信者にも聞きます（セクション1）。
8. 40分：添付ファイルを開いた、またはファイルを実行した場合は、その端末を隔離する（セクション3）。
9. 45分：支払いや振込先の変更を求めるメールなら、すぐ経理に伝える。 既知の番号への折り返し確認なしに支払わないようにします。
10. 60分：状況報告を送る。 報告者にも結果を伝えます。

やってはいけないこと： 注意喚起のつもりでフィッシングメールを全社に転送すること（代わりに特徴を説明します）。普段のブラウザーで「確認のため」にリンクを開くこと。保存する前に元のメールを削除すること。返信、QRコード、電話が関わっているのに「クリックしていない」で確認を終えること。

安全に開始し、案件を記録する

報告者には操作を中止し、既知の社内報告窓口を使うよう伝えます。リンクの再表示、添付の実行、同僚への転送は依頼しません。速やかな報告に感謝を伝えてください。

案件に責任者と次回確認時刻を設定します。メール原本・ヘッダー・識別子・受信者・UTC時刻・申告された操作・対象アカウント／端末を保全します。機微な証拠はアクセス制限された調査領域で管理します。容易に確保できる証拠を保全しつつ、緊急の封じ込めを遅らせないでください。URLやファイルの解析には承認済みの環境を使い、機密情報を公開スキャンサービスへ送信しません。

不自然な依頼は別の信頼できる経路で確認します。見慣れた表示名、既存の会話、SPF／DKIM／DMARCの成功だけでは、依頼が正当だとは判断できません。

この手順で使う言葉

用語	意味
フィッシング	情報を聞き出す、アクセスを承認させる、支払わせる、何かを実行させるためにだます連絡です。
おとり	メッセージの餌です。偽の請求書、共有ファイル、配送通知、パスワードの期限切れの警告などです。
類似ドメイン	example.comに対するexamp1e.comのように、本物に見せかけたドメインです。
SPF／DKIM／DMARC	そのドメインの送信を許可されたサーバーからメールが来たかを確かめる仕組みです。合格しても、依頼内容が正当だという証明にはなりません。本物だが乗っ取られたアカウントも合格します。
メッセージヘッダー	メールの経路を記録した技術情報です。追跡やコピーの検索に必要です。
ネットワークメッセージID	Microsoft 365で1通のメールに付く識別子です。すべてのコピーを探すのに使います。
論理的な削除（ソフト削除）	メールボックスから、復元できる場所へメールを移して削除することです。証拠を失いません。
テナント許可／ブロック一覧	Microsoft 365の管理者が、送信者、ドメイン、URL、ファイルをブロックする場所です。
安全なリンク／URLクリック	Microsoft Defenderによるリンクの検査で、メールのリンクを誰がクリックしたかも記録します。スマートフォンで読み取ったQRコードは記録されないことがあります。
認証情報の詐取	パスワードを集める偽のサインイン画面です。
AiTM	本物のサインイン画面を中継し、MFAのあとのセッションを盗む偽の画面です。
同意フィッシング	メールやファイルへのアクセスをアプリに許可させようとするメッセージです。
ビジネスメール詐欺（BEC）	本物や類似のメールアカウントを使い、支払先を変えさせたりデータを得たりする詐欺です。

セキュリティ担当がいない場合の役割分担

表に出てくる担当は「役割」であり、肩書きではありません。小さな会社では1人が複数の役割を持つのが普通です。それでも「メールを削除した人だけが、残っていないことを確認する」状態は避けてください。

この手順での役割	小規模な会社での担当例	事前に用意しておくもの
インシデント責任者	総務責任者または代表者	送信者をブロックする判断と、外部支援を承認する権限
メールセキュリティ	IT管理者、またはITの委託先	Exchange管理センターとDefenderポータルへのアクセス
ID／IAM	同じ管理者	セッションの取り消しとパスワードの再設定ができるEntraの管理者権限
EDR／IT	ITの委託先	端末管理やウイルス対策の管理画面
経理	経理部門	支払いと振込先変更の折り返し確認のルール
法務・個人情報	顧問弁護士、または個人情報保護管理者	入力・送信された可能性のあるデータの情報
報告者と受信者	全従業員	Reportボタンと、責められずにすぐ報告できる雰囲気
外部の支援	ITの委託先、支払い詐欺については取引銀行。国内では警察のサイバー事案の相談窓口と、フィッシングサイトの停止依頼も扱うJPCERT/CC	メッセージヘッダーと時系列

画面の項目名は英語表示の名称で書いています。日本語表示では訳語が異なる場合があります。

1. メールを判定し、配信範囲を確認する

図1。SecOpsNomad独自の判断フロー。以下の表でも同じ判断を確認できます。該当分岐を最後まで確認してください。

判断	はい	いいえ	不明・必要な証拠
Q1. フィッシングを疑う根拠がある？	メールセキュリティ／SOCが配信範囲の調査と封じ込めを開始。	独立した確認で正常と判断できる場合のみ終了。理由を記録し報告者へ連絡。	暫定判定を維持し、原本の取得と既知の連絡先による依頼内容の確認を実施。
Q2. 閲覧可能または配信済みのメールがある？	証拠保全、受信者と類似メールの検索後、権限に基づき隔離・削除。	遮断・隔離結果と以前の配信、別経路での接触を確認。	メール担当がメッセージ追跡、配信、修復の記録を確認。
Q3. 何らかの操作があった？	リンク・QR・返信・添付・認証・電話の内容と使用端末を記録。	申告を利用可能なログで補強し、Q4〜Q8も確認。	SIEM担当が聞き取り、クリック、プロキシ、認証、端末の証拠を突合。

証拠がある場合は、件名や送信者の完全一致だけに検索を限定しません。これらは変更されます。確認可能な範囲で配布リスト、共有メールボックス、社外受信者も調べます。後述の特定メール検索だけではキャンペーン全体を把握できません。遮断対象は根拠のある指標に絞り、担当者と見直し時期を設定します。共有ホスティング全体の遮断は正規業務にも影響します。削除依頼の送信だけでなく、完了と失敗を確認してください。Microsoftのフィッシング調査手順、悪意あるメールの修復。

具体的な操作手順

1. 元のメールを入手します。 報告されたメールは、Defenderポータルの「Submissions」（security.microsoft.com/reportsubmission）のユーザー報告のタブに表示されます。ヘッダーとネットワークメッセージIDを案件に保存します。

2. すべてのコピーを探します。 Defender for Office 365 プラン2ならDefenderポータル →「Email & collaboration」→「Explorer」、プラン1なら「Real-time detections」です。送信者、件名、送信者のドメイン、URLのドメインで絞り込み、時間範囲は広めにします。件名や送信者は波ごとに変わることがよくあります。Defenderがなければ、Exchange管理センター →「Mail flow」→「Message trace」→「Start a trace」で送信者かメッセージIDを指定します（最大90日）。

3. コピーを削除します。 Explorerでメールを選び →「Take action」→「Soft delete」。Explorerがない場合は、セキュリティ／コンプライアンスのPowerShellでPurviewの検索と削除を行います（検索名と条件は例です）。

   Connect-IPPSSession
   New-ComplianceSearch -Name "Phish-2026-10-06" -ExchangeLocation All -ContentMatchQuery 'from:billing@lookalike.example AND subject:"Invoice 4471"'
   Start-ComplianceSearch -Identity "Phish-2026-10-06"
   Get-ComplianceSearch -Identity "Phish-2026-10-06" | Format-List Status,Items
   New-ComplianceSearchAction -SearchName "Phish-2026-10-06" -Purge -PurgeType SoftDelete
   

   削除の前に件数を確認します。1回の削除でメールボックスごとに削除できる件数には上限があるため、検索で見つからなくなるまで繰り返します。

4. ブロックします。 Defenderポータル →「Email & collaboration」→「Policies & rules」→「Threat policies」→「Tenant Allow/Block Lists」で、送信者、ドメイン、URLを追加します。期限と見直し日を設定します。本物の取引先のドメインをブロックするのは、業務への影響を考えてからにします。

5. 操作した人を探します。 ExplorerのURLクリックの情報で、安全なリンク経由でクリックした人が分かります。下のハンティングクエリでも、高度な追求で同じことができます。QRコード、返信、電話はクリックの記録に残らないため、受信者全員に直接聞きます。

確認： メールを検索してもメールボックスにコピーが残っておらず、見直し日付きのブロックがあり、受信者全員について操作の有無が「はい」「いいえ」「不明」で記録されていること（Q1〜Q3、D04〜D10）。

2. アカウント・セッション・アプリの権限を確認する

図2。アカウントと端末は別々に確認します。パスワード変更だけを完了条件にしません。

判断	はい	いいえ	不明・必要な証拠
Q4. パスワード／OTPの入力、意図しないMFA承認、QR／デバイスコード認証があった？	ID／IAM担当が手順に基づき不審なアクセスを遮断し、露出した認証情報を変更、セッションを失効。本人確認は信頼できる経路で実施。	サインインと既存セッションの窃取・悪用を引き続き確認。	対象アカウントとサービスを特定。信頼できる露出の申告は調査中も緊急に扱う。
Q5. 不審なサインイン、MFA追加、転送、ルール、委任、送信メールがある？	記録保全後に不正な変更を除去。アカウントとクラウドの調査範囲を拡大。	ログの取得範囲、保持期間、確認した時間帯を記録。	認証・メール監査ログがないことは、侵害がないことを意味しない。
Q6. 信頼できないOAuthアプリに同意した？	アプリ／IAM担当が権限を確認し、不正な同意を取り消す。アプリの操作と他の利用者への影響を調査。	確認した同意・アプリの証拠を記録。	アプリID、権限範囲、同意した利用者、時刻を取得。パスワード変更でアプリ権限が消えるとは限らない。

復旧には安全性を確認した端末を使用します。接続されたクラウドサービスと、露出した認証情報の使い回しも確認します。アクセス失効には時間がかかることがあり、アプリが独自のセッションを保持する場合もあります。実際にアクセスが停止したことを確認し、対応するアプリ側セッションも失効させます。Microsoftの侵害アカウント対応、アクセス失効の制約、アプリ権限の確認。

具体的な操作手順

1. セッションを取り消し、サインインを止めます。 パスワードを入力した、MFAを承認した、コードを入力した人が対象です。Entra管理センター →「Entra ID」→「Users」→ ユーザー →「Revoke sessions」。調査中は「Account status」でサインインも止めます。詳しい手順はアカウント侵害プレイブックにあります。

2. クリーンな端末からパスワードを再設定し、 「Authentication methods」に本人が追加していないものがないか確認します。

3. メールボックスの転送と隠しルールを確認します。

   Connect-ExchangeOnline
   Get-Mailbox -Identity user@example.com | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
   Get-InboxRule -Mailbox user@example.com -IncludeHidden | Format-List Name,Enabled,RedirectTo,ForwardTo,ForwardAsAttachmentTo,MoveToFolder,DeleteMessage
   

4. アプリへの同意を確認します。 Defenderポータル →「Audit」（security.microsoft.com/auditlogsearch）→ アクティビティ「Consent to application」→ ユーザーと期間を指定。信頼できない許可は、Entra ID →「Enterprise apps」→ アプリ →「Permissions」で確認して削除します。

5. クリックした時刻以降のサインインログを読みます。 本人のサインインの数分後に見慣れないアドレスから成功していれば、セッションの窃取が疑われ、取り消しでしか止まりません。

確認： 取り消しの時刻以降、不明な送信元からの成功サインインがなく、すべての方法、ルール、アプリへの許可が本人の確認済みか削除済みであること（Q4〜Q6、D11〜D15）。

3. 端末・データ・金銭への影響を確認する

図3。メールが消えた時点ではなく、対応の結果を確認できた時点で終結を判断します。

判断	はい	いいえ	不明・必要な証拠
Q7. ペイロード実行、遠隔操作、端末侵害の兆候がある？	EDR／IT担当が承認手順で対象端末を隔離。証拠を保全し、永続化、通信、関連端末を調査。	ダウンロードとプロセス・ブラウザの証拠を確認。取得だけでは実行とは限らない。	未対応・個人所有・オフライン端末はITと責任者へ。証拠取得中は可能なアクセス制限を適用。
Q8. データ送信、送金、口座・給与情報の変更があった？	データ責任者と法務／プライバシーが露出を評価。経理は既知の連絡先で金融機関へ速やかに相談し、不審な変更の処理を止める。	返信やアップロードも含め、業務担当と記録で確認。	影響評価を別の作業として開始。マルウェアの証拠を待たず業務担当を招集。
Q9. 影響範囲・封じ込め・復旧を確認できた？	責任者が終結、監視、改善項目を承認。	未完了の作業を割り当て、案件を継続。	制約を明記し、権限を持つ責任者によるリスク受容、または追加調査を要求。

EDRの隔離要求は、対応OS、接続状態、処置結果を確認して初めて有効性を評価できます。必要な証拠を責任者が判断する前に端末を消去・再構築しません。ただし、進行中の被害には即時の封じ込めが必要な場合があります。Defender for Endpointの対応アクション。

送金詐欺が疑われる場合は、確認済みの電話番号で銀行へ直接連絡します。迅速な連絡は重要ですが、資金回収は保証されません。法域ごとの報告・通知義務は法務／プライバシー担当が判断します。この資料は一律の期限を示しません。FBI IC3のBEC対応情報。

具体的な操作手順

1. 端末： ファイルを開いた、コマンドを貼り付けた、ソフトウェアを入れた場合は、端末を隔離します。Defenderポータル →「Assets」→「Devices」→ 端末 →「Isolate device」。続けてフルスキャンと調査パッケージの収集を行うか、ITの委託先に同等の対応を依頼します。
2. 個人の端末や管理外の端末： QRコードは個人のスマートフォンで読み取られることがよくあります。その端末で業務アプリからサインアウトし、別の端末からパスワードを変えてもらいます。端末を調べられないことも記録します。
3. データ： 何を入力・アップロードしたか（顧客データ、カード番号、書類など）を聞き、その日のうちに法務・個人情報の担当に伝えます。
4. お金： 支払いや振込先の変更があった場合は、経理が既知の番号ですぐ銀行に電話し、組戻しなどについて相談して、受付番号を記録します。速さが大事ですが、回収できるとは限りません。
5. 取引先： 本物の取引先のアカウントからフィッシングが来た場合は、既知の電話番号で知らせ（下のテンプレート）、メールボックスを守ってもらいます。

確認： 影響を受けた端末、データ、支払いのそれぞれに結果が記録され、インシデント責任者が証拠をもってQ9を承認できること（Q7〜Q9、D16〜D30）。

4. 詳細な判断台帳：確認漏れを減らす30項目

Q1〜Q9を全体像、D01〜D30を作業記録として使用します。30個の独立した最終判定ではなく、判断を支える詳細確認です。受付時にD01〜D05を優先し、必要に応じてID・端末・業務影響を並行して調査します。銀行への連絡や進行中の被害の封じ込めを、リストの最後まで待たないでください。

すべての行ではい／いいえ／不明／対象外を選び、証拠の参照先、担当者、UTC判断時刻、処置状態、次回確認を記録します。「はい」「いいえ」自体が安全・危険を示すわけではありません。該当列の行動に従ってください。不明 → 記載された担当が証拠を取得し、期限と相応の封じ込めを設定。「いいえ」に自動変換しません。 対象外には理由と確認者が必要です。重要な不確実性を残して終結する場合は、権限を持つ責任者の明示的な受容が必要です。

訓練として終了できるのは、正式な訓練責任者が対象キャンペーンを確認し、矛盾する証拠がない場合です。正常に見えるメールも別経路で確認し、新たな不審活動があれば調査を再開します。複数の正常回答で重大な影響を相殺するような単純スコアは使用しません。

編集用の判断台帳（CSV）をダウンロード。記入後は社内の制限された調査領域で管理し、この公開ブログへ掲載しないでください。

図4。影響なしと判断する前に、緊急度と可視性を確認。証拠の詳細はD01〜D05を参照。

緊急度と証拠

判断／担当	はい →	いいえ →	判断に必要な証拠
D01. 不審アクセス、暗号化、情報流出、送金などの被害が進行中？ — 対応責任者	緊急対応を宣言し、該当業務の責任者と直ちに封じ込め。	初動調査を継続し、新たな証拠で緊急度を再評価。	最新アラート、活動・セッションの時刻、業務担当の確認。
D02. 特権ID、重要サービス、影響の大きいメールボックスが対象？ — 対応責任者／IAM	重大度を引き上げ、サービス担当と管理権限の到達範囲を確認。	通常の優先順位で対応。ただし影響拡大を再評価。	実際の権限、リソースへのアクセス、業務重要度。役職名だけで判断しない。
D03. 複数の利用者・組織・経路に影響している？ — SOC／第三者リスク	キャンペーンとして調整し、対象ごとに追跡する作業を設定。	現時点の範囲は暫定とし、関連メールや活動を検索。	受信者・検索結果、取引先の報告、関連アラート。
D04. 原本の信頼性と調査に使える状態を確認できる？ — SOC／メール担当	原本、識別子、取得状況を保全し、調査時刻の基準を統一。	原本または信頼できるログを取得。画像や記憶だけの場合は制約を記録。	原本・ヘッダー、取得元、取得時刻、タイムゾーン、証拠の保存場所。
D05. 必要なログに欠落・期限切れ・遅延・対象外がある？ — SIEM／データ担当	不足を記録し、代替証拠と担当・期限を設定。リスクに応じて封じ込め。	確認済みの取得元、保持期間、取り込み状態を記録。	ログ提供状況、センサー正常性、遅延、時刻ずれ、保持制約。

メール・接触経路・利用者の操作

判断／担当	はい →	いいえ →	判断に必要な証拠
D06. 信頼された社内・取引先アカウントが送信元の可能性？ — メール担当／第三者リスク	その信頼境界を調査し、既知の連絡先で送信者に確認。	送信元調査を継続。社外から届いた事実だけでは悪性とは限らない。	原本の経路、会話の状況、送信者の確認、取得可能なアカウント活動。
D07. ヘッダー・類似ドメイン・依頼内容が送信者の主張と矛盾？ — メール担当	不整合を依頼内容や他の証拠と照合。単独の信号だけで判定しない。	本文とアカウントを確認。認証成功でも悪用はあり得る。	From／Reply-To／Return-Path、認証結果、正確なドメイン、別経路での確認。
D08. QR・SMS・チャット・会議招待・電話・個人端末へ接触が移った？ — SOC／IT	実際の経路と端末を対象に追加し、権限内で証拠を取得。ID・端末の分岐へ。	確認した経路を記録し、現在の調査範囲を維持。	利用者の時系列、チャット・招待記録、管理端末または許可されたモバイルの証拠。
D09. 操作はスキャナーやプレビューではなく、本人に結び付く？ — SIEM／SOC	利用者・時刻・端末を照合し、アクセス後の活動を確認。	スキャンを利用者の侵害と扱わない。ID・業務影響の調査は継続。	クリック・プロキシの状況、本人確認、端末・ブラウザの活動。記録なしは不明の場合も。
D10. 共有メールボックスや後続の変種も含め、発見したメールを封じ込めた？ — メール担当	処置完了を記録し、新たな変種を監視。	失敗や対象外への処置を実施し、既知の経路で対象者へ注意喚起。	配信後の状態、処置結果、共有メール、配布先展開、検索範囲。

IDとアプリのアクセス

判断／担当	はい →	いいえ →	判断に必要な証拠
D11. パスワード・回復コード・APIキー等が露出、または使い回されている？ — IAM／秘密情報の管理者	承認された手順で対象を変更し、使い回しと依存サービスを調査。	パスワード露出がなくてもトークン・セッション・同意を確認。	入力内容の聞き取り、管理台帳、認証履歴。秘密の値自体を案件へ貼らない。
D12. セッション窃取・AiTM・デバイスコード認可の証拠がある？ — IAM／SOC	IDを封じ込め、関連セッションを失効し、接続サービスの活動を調査。	他の証拠を確認。通常に見えるログインや正規画面だけでは安全と判断しない。	認証フロー、セッション、アプリID、サインインとクラウド操作の時系列。
D13. MFA・回復情報・登録端末・ロールが無断変更された？ — IAM	監査記録を保全し、不正変更を除去。変更したアカウントも調査。	基準となる状態と確認した監査期間を記録。	認証登録、端末登録、回復、ロール付与、管理操作の監査記録。
D14. アプリ同意・アプリ資格情報・サービスプリンシパル権限が変更された？ — IAM／アプリ担当	委任とアプリ単独のアクセスを区別し、不正な権限・資格情報を封じ込め、対象データを調査。	確認したアプリと権限種類を記録。パスワード変更ではこの確認を代替できない。	同意ログ、アプリ／サービスプリンシパルID、資格情報変更、権限、リソース監査。
D15. ヘルプデスクの回復・ロック解除・電話番号管理が悪用された？ — IAM／ヘルプデスク	別経路で本人確認し、不正変更を停止。必要なら権限を持つ通信契約担当と連携。	回復とヘルプデスクの確認を記録し、他のID調査を継続。	サポート記録、リセット・登録監査、正規利用者への確認。

端末と実行

判断／担当	はい →	いいえ →	判断に必要な証拠
D16. ファイルは取得だけでなく、開く・実行する操作まで行われた？ — EDR／IT	実行時の挙動を再構成し、侵害が疑われる場合は手順に従い隔離。	ダウンロードを保全し、ブラウザ等の操作による露出も確認。	ファイル時刻・ハッシュ、プロセスの親子関係、利用者・端末の時系列。ログ不足は不明。
D17. コマンド貼り付け・マクロ許可・偽の検証や修復操作を行った？ — EDR／SOC	実行の可能性として扱い、提示された命令を再実行せずプロセス・スクリプト証拠を取得。	添付、ブラウザ、遠隔操作の確認を継続。	操作の聞き取り、利用可能なスクリプト・コマンド記録、プロセスと通信。
D18. 遠隔操作ツール・拡張機能・アプリ・構成プロファイルを導入または許可した？ — EDR／IT	承認済み台帳と照合。不正アクセスを封じ込め、権限と永続化を調査。	確認した導入・権限記録を残す。正規ツール名だけでは安全と判断しない。	ソフト・拡張・プロファイルの変更、遠隔セッション、権限、端末管理記録。
D19. 永続化・横展開・不審な外向き通信・他端末への影響がある？ — EDR／SIEM	対象システムとIDを拡大して封じ込め、破壊的活動には専門担当を招集。	対象を限定した監視を継続し、証拠と期間の範囲を記録。	プロセス、サービス・タスク、通信・DNS、遠隔ログオン、関連アラート。
D20. 未管理・オフライン・未対応端末、または隔離未完了？ — IT／対応責任者	代替の封じ込め・証拠取得を手配し、業務・安全への影響を担当者と確認。	実際の隔離完了と管理・対応経路の維持を確認。	処置結果、接続とセンサーの状態。キューに入っただけでは隔離ではない。

データ・金銭・社外への影響

判断／担当	はい →	いいえ →	判断に必要な証拠
D21. 機微なデータが無断閲覧・取得・アップロード・共有された？ — データ責任者／法務・プライバシー	データ種類、対象者、リソースを特定し、確認済みアクセスと可能性を区別。	評価を支える監査記録と制約を記録。	メール・クラウド・ファイル操作、共有変更、利用者の申告、DLP証拠。
D22. 送金・支払予約・取引先口座・給与・カード情報の変更があった？ — 経理／不正対策	既知の連絡先で変更停止と回収を速やかに相談し、取引証拠を保全。	メール受信者だけでなく、業務手続きの責任者に確認。	取引・変更履歴と独立した確認。回収は保証されない。
D23. 返信・転送・取引先との通信でデータや誘導が拡散した？ — メール担当／業務責任者	受信者を調査し、権限を持つ広報・連絡担当と必要な注意喚起や訂正を調整。	送信・返信の確認を記録。元メールの完全一致検索だけでは不十分。	送信・返信・転送記録、メールルール、共有記録、取引先の確認。
D24. 法令・契約・個人情報・保険の報告義務が適用される可能性？ — 法務・プライバシー／対応責任者	法域・契約、期限の起点、判断責任者を記録し、速やかに専門判断を得る。	判断根拠を記録し、範囲変更時に再評価。	データ区分、地域・契約、関係者、法務や責任者の記録された評価。
D25. 保持期限・削除・再構築・証拠保全義務により証拠を失う危険？ — 対応責任者／証拠管理者	必要な証拠を保全し、修復の順序を承認。進行中の被害への対応を不必要に遅らせない。	管理された取り扱いを継続し、保持計画を記録。	取得経緯、アクセス制御、保持・保全判断、破壊的処置の承認。

処置の検証と終結

判断／担当	はい →	いいえ →	判断に必要な証拠
D26. 必要な封じ込めと、接続先への効果をすべて確認できた？ — 対応責任者／各処置担当	完了を記録し、復旧確認へ進む。	未完了として扱い、失敗・待機中の処置と継続アクセスを確認。	メール除去、アクセス遮断、アプリセッション失効、端末処置の結果。
D27. 影響範囲に根拠があり、重要な不明点は解決または明示的に受容された？ — SOC／対応責任者	範囲、確度、受容した制約を記録。	各不足に担当と再確認時刻を設定し、証拠に応じて範囲を拡大。	利用者・端末・アプリ・配信範囲と取得元別のカバレッジ。検索0件だけでは不可。
D28. 観測された侵害を再導入せずにアクセスを復旧できる？ — IAM／IT／サービス担当	段階的に復旧し、機能確認と再発監視を実施。	リスクに応じた制限を維持し、復旧作業を完了。	安全な端末、保護されたID・アプリ権限、永続化の除去、担当者の承認。
D29. 監視・検知改善・再調査の条件に担当者がいる？ — SIEM／検知担当	確認日を設定し、修復・統制改善のチケットを追跡。	終結前に監視期間、対象範囲、責任者を決める。	監視計画、環境内で確認したルール、発動条件、作業の担当。
D30. 業務担当が対応結果と必要な連絡を承認した？ — 対応責任者／業務責任者	D26〜D29の条件を満たしてから理由を記録して終結し、改善を追跡。	終結を保留し、承認・通知・業務影響の確認を完了。	結果の要約、経理・法務判断、報告者への連絡、明示的な承認。

ID・端末の分岐を増やした理由

セッションクッキー窃取、デバイスコードの悪用、不正なアプリ同意は、異なる認可経路です。正規の認証画面でも、攻撃者のセッションやアプリへのアクセスを許可する場合があります。画面のドメインだけでなく、結果として付与されたアクセスを調べます。アプリ単独の資格情報は、利用者のパスワードや委任同意とは別に評価します。Microsoftのセッション窃取調査、デバイスコード悪用の分析、同意フィッシング対策を参照。

端末では偽の修復・検証指示、遠隔サポートツール、ブラウザ拡張、モバイルのプロファイルも明示的に確認します。これらは調査候補であり、すべてが今回の事案で発生したという意味ではありません。署名付きの見慣れたツールでも、承認された業務用途を確認します。正規の遠隔ツールがフィッシングから悪用された事例は、CISAのRMMアドバイザリに記載されています。

図5。終結には証拠が必要です。D26〜D30すべてに対応し、一つの処置成功だけで終了しません。

実際の事案の前に、分岐を演習する

スキャナーだけのクリック、DMARCに成功するフィッシング、取引先メールからのもっともらしい請求、パスワード入力のない不正同意、隔離要求が待機中のオフライン端末、依頼されたが未送金の支払い、発見前に期限切れになったログ、活動が少ない特権ID、責任者が確認できない訓練の主張を試してください。根拠のない安全判定を作らず、担当者・必要証拠・次の行動につながることを確認します。

ハンティングの出発点：判定ではなく証拠を得る

特定事案のIOCは掲載していません。 汎用プレイブックのため、実際のメッセージID、URL、ハッシュと出所は案件内で管理します。被害者のアドレス、セッショントークン、機微なURLパラメータは公開しません。以下は2026年10月2日に資料と照合した読み取り専用の例で、実テナントやSplunk環境では実行していません。

KQL：特定メールの受信者記録を確認する

Microsoft Defender XDR Advanced Huntingで使用します。Defender for Office 365のライセンス、対象データの取得、メール記録への読み取り権限が必要です。DefenderのNetworkMessageIdを設定してください。公開ヘッダーのInternet Message-IDとは別物です。EmailEventsスキーマ。

// Microsoft Defender XDR Advanced Hunting; read-only; not live-tested.
// Replace the message ID copied from Defender. Lookback: 7 days.
let MessageId = "REPLACE_WITH_NETWORK_MESSAGE_ID";
EmailEvents
| where Timestamp >= ago(7d)
| where NetworkMessageId == MessageId
| summarize arg_max(Timestamp, *) by NetworkMessageId, RecipientEmailAddress
| project Timestamp, NetworkMessageId, RecipientEmailAddress,
    SenderFromAddress, Subject, DeliveryAction, DeliveryLocation
| order by Timestamp desc
| take 500

受信者確認用KQLをダウンロード。

受信者ごとの最新記録はメール処理の証拠です。現在の配置と削除完了はメール管理画面でも確認します。7日間・500行に制限しています。上限に達した場合は時間帯や承認済みの対象範囲を分割し、不足を記録します。別のメッセージIDや保持期限切れのデータは検出できません。

KQL：記録されたSafe Links操作を確認する

同じ製品・権限に加え、UrlClickEventsへのデータ取得が必要です。各行をアクセス成功と決めつけず、アクションとクリック続行フラグを確認します。別端末のQR読み取り、直接アクセス、対象外の経路は記録されない場合があります。クリック記録だけで認証情報の入力を証明できません。UrlClickEventsスキーマ。

// Microsoft Defender XDR Advanced Hunting; read-only; not live-tested.
// Safe Links coverage is required. Absence of results is not a no-click verdict.
let MessageId = "REPLACE_WITH_NETWORK_MESSAGE_ID";
UrlClickEvents
| where Timestamp >= ago(7d)
| where NetworkMessageId == MessageId
| where Workload == "Email"
| project Timestamp, AccountUpn, NetworkMessageId, Url,
    ActionType, IsClickedThrough
| order by Timestamp desc
| take 500

クリック確認用KQLをダウンロード。

Splunk：フィールド対応済みのメールログを検索する

Splunk Enterprise／Cloudで、承認済みメールインデックスの読み取り権限を使用します。インデックス、sourcetype、元ログのメッセージ識別子を置換します。パーサーは_time、message_id、recipient、src_user、subject、actionをSplunk Emailモデルの意味で提供する必要があります。対応付けを実環境で確認してください。message_idがMicrosoftのNetworkMessageIdに対応するとは限りません。対応済みの生イベントを検索するため、高速化データモデルは不要です。Splunk CIM Emailフィールド。

index=YOUR_EMAIL_INDEX sourcetype=YOUR_EMAIL_SOURCETYPE earliest=-7d latest=now
message_id="REPLACE_WITH_SOURCE_MESSAGE_ID"
| stats min(_time) as first_seen max(_time) as last_seen count
    values(src_user) as senders values(subject) as subjects
    values(action) as actions by message_id recipient
| sort 0 - last_seen
| head 500
| convert ctime(first_seen) ctime(last_seen)

Splunkクエリをダウンロード。

重複イベントによりcountは増えるため、被害者数ではありません。actionsには過去と後続の状態が混在します。現在の配信・削除状況は時系列で確認します。パーサー不足、保持期間の欠落、500行の上限が判断を制限します。これらの例は認証・端末・決済システムを検索しません。各分岐を別途担当者へ割り当てます。

コピーして使えるテンプレート

［角かっこ］の部分をすべて置き換えてください。パスワードや、有効なフィッシングのリンクは書かず、特徴を説明してください。社外に出す文面は法務が確認します。

報告者への返信

［氏名］さん
「［件名］」のメールを早く報告してくださり、ありがとうございました。このメールは［フィッシングでした／正規のメールでした／確認中です］。
対応：［N件のメールボックスから削除し、送信者をブロックしました］。
もしリンクをクリックした、QRコードを読み取った、パスワードを入力した、サインインの要求を承認した、添付ファイルを開いた場合は、すぐに知らせてください。責めることはありません。早い報告が、早い対応につながります。
［IT／セキュリティ担当］

全従業員への注意喚起（転送せず、特徴を説明する）

件名：【注意】偽の「［おとり：請求書／共有ファイルなど］」メールについて

一部の従業員に、［特徴：差出人名、件名、求めている内容］のメールが届いています。これはフィッシングです。
・まだ届いている場合は、クリック、読み取り、返信をせず、Reportボタンで報告してください。
・すでにクリックした、パスワードを入力した、サインインを承認した場合は、今すぐ［連絡先］に知らせてください。責めることはありません。
・［経理の方へ：このメールにある振込先変更の依頼には対応しないでください。］
当社がメールやチャットでパスワードを尋ねることはありません。
［IT／セキュリティ担当、連絡先］

自社宛てのフィッシングを送ってきたアカウントの持ち主（取引先）への連絡

既知の番号に電話したあとに送ります。

件名：［日付］に貴社のアカウント［アドレス］から送信されたフィッシングについて

［氏名］様

お電話でお伝えしたとおり、［日時］、当社の従業員に［アドレス］からメールが届きましたが、貴社が送信したものではないと考えております。内容は［請求書を見るためQRコードの読み取りを求めるもの／偽のサインイン画面へのリンクを含むもの］でした。
貴社のIT担当の方向けの情報：件名「［件名］」、送信日時［時刻とタイムゾーン］、ネットワークメッセージID［ID］、リンク先のドメイン［ドメイン（クリックできない形で記載）］
貴社のメールボックスの安全が確認されるまで、当社側で［対象］をブロックしております。確認できましたらお知らせください。また、振込先の情報は電話でご確認ください。
［氏名・役職・会社名・電話番号］

経営層向けの要約（5行）

1. 何が起きたか：［日付］、［おとり］を装ったフィッシングメールが従業員［N］名に届きました。
2. 操作の状況：クリック・読み取り［N］名、認証情報の入力［N］名、ファイルを開いた人［N］名。影響を受けたアカウントは［時刻］にすべて保護済み。
3. 影響：［例：1つのメールボックスに40分間アクセスされた、支払いはなし、マルウェアは見つからず］
4. 必要な判断：［例：取引先への連絡、フィッシングに強いMFAの義務化、QRコードのフィッシングの教育］
5. 次回報告／終結予定：［時刻］。責任者：［氏名］

具体例：本物の取引先から届いたQRコード付きの請求書

架空の事例です。会社、人物、時刻、数値はすべて創作で、判断のつながりを示すためのものです。

状況： 従業員80人の設計事務所に、長年の取引先の本物のメールボックスから「請求書をご用意しました。QRコードを読み取ってご確認ください」というメールが届きます。取引先のアカウントは乗っ取られていました。

1. 9:10 報告。 プロジェクトマネージャーがReportボタンで報告します（Q1、D04）。IT管理者が案件を作ります。
2. 9:15 範囲。 Explorerで、件名を変えた3つの波で46通が配信されていたと分かります（Q2、D03、D10）。取引先自身のアカウントから送られたため、SPF、DKIM、DMARCはすべて合格していました（D06、D07）。
3. 9:25 メールの封じ込め。 46通すべてを論理的に削除し、フィッシングサイトのドメインを30日後の見直し付きでブロックします。本物の請求書まで止めないよう、取引先のドメインはブロックしません（Q2）。
4. 9:35 操作の確認。 QRコードはスマートフォンで読み取られたため、安全なリンクにはクリックの記録がありません（D08）。46人全員に聞いたところ、3人が読み取り、1人が個人のスマートフォンでパスワードを入力してMFAを承認していました（Q3、Q4、D09）。
5. 9:45 アカウントの保護。 セッションを取り消し、パスワードを再設定します。サインインログには9:02のホスティング事業者からのサインインと、「支払」を含む返信を隠す新しい受信トレイのルールがありました（Q5、D12、D13）。ルールは記録してから削除します。アプリへの同意は見つかりません（Q6）。
6. 10:30 端末とお金。 ファイルはダウンロードされていません（Q7）。経理担当の1人が「新しい振込先」について返信していましたが、支払いはしておらず、経理が取引先に電話で確認します（Q8、D22、D23）。
7. 11:00 取引先。 契約書の番号で取引先に電話し、取引先向けのテンプレートを送ります。取引先は乗っ取りを確認し、メールボックスを保護します（D06）。
8. 翌日 終結。 不明な送信元からのサインインはその後ありません。責任者は案件を閉じ、改善策を割り当てます。スマートフォンを使う従業員へのフィッシングに強いMFA、教育へのQRコードの例の追加、振込先の変更には必ず折り返し確認を行うルールです（Q9、D26〜D30）。

分かれ目になったこと： QRコードの読み取りが見えないクリックの記録に頼らず、受信者全員に聞いたこと。パスワードだけでなくセッションを取り消したこと。SPF、DKIM、DMARCが合格したことを理由にメールを信用しなかったこと。

証拠をもって終結し、防御を改善する

影響を受けた利用者・端末、証拠の参照先、Q1〜Q9とD01〜D30の判断、処置時刻と結果、不確実性、業務影響、担当者、次回確認時刻を記録します。すべての該当分岐を解決するか、インシデント対応権限を持つ責任者が明示的に受容する必要があります。

アクセス再開前に、担当者とアカウント・端末の復旧を確認します。事案とログ保持期間に応じて監視期間を決め、活動が再開した場合は調査を再開します。結果は認証強化、アプリ同意管理、端末の可視化、メール除去の迅速化、別経路での振込先確認、証拠保持などの改善につなげます。報告者を責めず、有用な報告を促します。

机上演習： 遮断済みメール、個人スマートフォンでのQR読み取り、偽MFA／デバイスコード認証、不正OAuth同意、添付実行、返信による振込先変更を試します。どのケースも担当者と記録された結論につながることを確認してください。「クリックなし」で送金やアカウントの分岐を省略しません。

出典とバージョン

バージョン1.1。30の詳細判断、緊急度・終結の図解、編集用台帳を追加。資料・スキーマの確認日：2026年10月2日。出典は対応する手順の近くに記載しています。分岐設計、証拠による確認条件、優先順位はSecOpsNomadの編集上の提案です。実施可能な処置はツール、ライセンス、組織の権限によって異なります。実際の事案調査やクエリの実行を示すものではありません。

バージョン1.2（2026年10月6日）：初めて対応する方向けに拡充。 最初の1時間のチェックリスト、用語集、少人数の組織での役割分担、セクション1〜3の具体的な操作手順、コピーして使えるテンプレート、具体例を追加しました。判断ID、表、クエリは変更していません。