アカウント侵害対応：偵察からC2・復旧まで、36の判断ポイント。

最初に見つけた1つのアカウントから、調査を広げる

最初に見つけた侵害IDは調査の起点であり、被害範囲の境界ではありません。盗まれたパスワードは問題の一部かもしれません。セッション、回復手段、アプリ権限、メール権限、接続端末によってアクセスが残る場合があります。

この再利用可能なアカウント侵害プレイブックには36の判断ポイントがあり、はい・いいえの処置、証拠、担当者を示します。新たな侵害の報道ではなく、SecOpsNomad独自の手順です。主に人が使用するIDの侵害疑いを対象とします。特権・ゲスト・共有・ワークロードのIDは専門担当者を招集し、サービスプリンシパルへ利用者のパスワード再設定手順を当てはめたり、1つのテナントがゲストの所属先IDまで制御できると考えたりしないでください。

SOCFortressのAccount Compromisedプレイブックは対応ライフサイクルの構成を考える参考にしました。本文・判断台帳・図は独自に作成しており、提携や推奨を意味しません。対応フェーズは作業を整理し、Cyber Kill Chainは侵入の段階を表します。ここでは準備・初動、7つの分析段階、復旧・終結の判定を組み合わせています。

侵害を疑う確かな根拠があれば、全段階の解明を待たずに封じ込めます。 未観測・対象外の段階もあります。武器化は被害側に見えない場合があり、クラウドIDだけの侵害にはマルウェア導入や典型的なC2がない場合もあります。証拠を無理に物語へ当てはめず、そのまま記録します。

偵察から影響までの7段階、即時のID封じ込め、独立した復旧判定を示す全体図。

全体図：偵察 → 武器化 → 配信 → 悪用 → インストール → C2（指揮統制） → 目的の遂行・影響。初動と復旧は追加の対応作業です。図と同じ判断を直後の表で確認できます。

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

初めて対応する方は、この順番で進めてください。詳しい調査は、このあとの各段階で行います。例はMicrosoft 365とEntra IDですが、他のID基盤でも名前が違うだけで手順は同じです。

0〜5分：分かっていることを書き留める。 誰が報告したか、どのアカウントか、何がおかしかったか、いつか（UTC）。元のアラートやメールは残しておきます。
5分：案件を作る。 インシデント責任者を決めます。アカウントのオブジェクトID（Entra管理センター → ユーザー →「Overview」）を記録します。ユーザー名やメールアドレスは変わりますが、オブジェクトIDは変わりません。
5〜10分：本人に電話する。 不審なメールや返信に書かれた番号ではなく、手元にある番号を使います。何を受け取り、何をクリック・入力・承認したか、どの端末だったかを聞きます。もう一度試してもらうことはしません。
10分：サインインを止め、セッションを取り消す（場所は段階0）。パスワードを変えるだけでは、攻撃者はサインアウトされません。
15分：特別なアカウントか確認する。 管理者ロール、共有メールボックス、依存しているサービス、緊急用アカウントであれば、先に進む前にそれぞれの担当者を巻き込みます。
15〜30分：証拠を保存する。 誰かが何かを消す前に、少なくとも直近30日のサインインログと監査ログをダウンロードします（段階1）。
30〜40分：攻撃者の置き土産を探す。 新しいMFAの方法、受信トレイのルール、転送、メールボックスの代理人、アプリへの同意（段階5）。削除する前に、それぞれを記録します。
40分：送信されたメールを確認する。 アカウントが送ったメールのメッセージ追跡で、顧客や同僚がフィッシングを受け取ったかが分かります（段階7）。
45分：経理に注意喚起する。 アカウントが請求や支払いに関わる場合、折り返し確認なしの振込先変更をしないよう伝えます。
50〜60分：最初の状況報告を送る。 このページ末尾のテンプレートを使い、次の報告時刻を決めます。

やってはいけないこと： パスワードを再設定して案件を閉じること。侵害されたメールボックスに本人宛てのメールを送ること。ルールやアプリを記録する前に削除すること。端末を確認する前に本人を戻すこと。

事前準備と判断ルール

利用者制限、セッション失効、メール調査、アプリ確認、ID基盤復旧を誰が実施できるか、平常時から確認します。承認済みの緊急アクセス、サービス依存先、信頼できる連絡先、ID・資源監査の保全方法を準備します。テストIDを使い、アプリへのアクセス停止を検証するところまで演習してください。

はい： 処置を行い、他の該当する確認もすべて実施します。
いいえ： 回答を裏付ける証拠、範囲、時間帯を記録します。アラートなしだけでは不十分です。
不明： 未解決の作業として担当と再確認時刻を決め、調査中もリスクに応じて封じ込めます。
対象外： 理由と確認者を記録し、ログ不足の代わりに使いません。

案件ID、テナント・オブジェクトID、ID種別、UTC時間帯、回答・根拠、証拠保管先、処置・結果、実担当、再確認時刻を残します。機微なログは制限された案件領域に保全し、パスワード・Cookie・トークン・個人データを公開手順や公開スキャンサービスへ載せません。

日本語の判断台帳をダウンロード（CSV）。空欄は非公開の案件記録用です。表計算ソフトへ追記する文字列は信頼できない入力として扱ってください。

担当： SOC／SIEMは時系列と範囲、IAM／ディレクトリはID封じ込め、メールセキュリティはメール調査、EDR／DFIRは端末評価を担当します。アプリ担当は独自セッションと認証情報、サービスデスクは本人確認、経理は送金詐欺、法務／プライバシーはデータと通知を評価します。責任者が復旧・終結を承認します。サイトのタグより細かな役割も含みます。

この手順で使う言葉

用語	意味
アカウント侵害	パスワードの有無にかかわらず、持ち主以外がアカウントを使える状態です。
オブジェクトID	Entra IDでアカウントを一意に表す、変わらない識別子です。記録にはメールアドレスではなくこれを使います。
セッション／トークン	パスワードとMFAの確認のあと、サインイン状態を保つものです。盗まれたセッションはパスワードなしで使えます。
セッションの取り消し	アカウントのリフレッシュトークンを無効にし、再サインインを求めることです。発行済みのアクセストークンは最大で1時間ほど使えることがあります。
MFAの方法	Authenticatorアプリや電話番号などの2つ目の確認です。攻撃者は戻ってくるために自分の方法を追加することがよくあります。
中間者型フィッシング（AiTM）	本物のサインイン画面を中継し、利用者がMFAを終えたあとのセッションを盗むフィッシングサイトです。
デバイスコードフィッシング	攻撃者がコードを送り、本物のMicrosoftのページで入力させることで、攻撃者の端末をサインインさせる手口です。
受信トレイのルール	メールボックスの自動処理です。攻撃者は隠しルールでメールを転送したり、返信を本人から隠したりします。
OAuthの同意／アプリへの許可	アプリケーションに利用者のデータを扱わせる許可です。削除するまで、パスワードを変えても残ります。
サインインログ／監査ログ	Entra IDの、すべてのサインインの記録と、ユーザー・グループ・アプリ・設定の変更の記録です。
統合監査ログ	Exchange、SharePoint、TeamsなどMicrosoft 365のサービス内での操作の記録です。
条件付きアクセス	サインインにMFAや管理された端末を求めたり、遮断したりする条件を決めるEntra IDのルールです。

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

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

この手順での役割	小規模な会社での担当例	事前に用意しておくもの
インシデント責任者	代表者または総務責任者	アカウントを止める判断と、外部支援を承認する権限
IAM／ディレクトリ	IT管理者、またはITの委託先	MFAで守られたMicrosoft 365の管理者アカウントと、緊急用アカウント
SOC／SIEM	同じ管理者、または監視サービスの事業者	サインインログ、監査ログ、統合監査ログへのアクセス
メールセキュリティ	IT管理者	Exchange管理センターとDefenderポータルへのアクセス
EDR／DFIR	ITの委託先、またはインシデント対応会社	端末管理やウイルス対策の管理画面、端末を回収する方法
サービスデスク	パスワードを再設定している人	侵害されたメールボックスに頼らない本人確認の手順
経理	経理部門	支払い変更の折り返し確認のルール
法務・個人情報	顧問弁護士、または個人情報保護管理者	アカウントで見られたデータの情報
外部の支援	ITの委託先、Microsoftのサポート、インシデント対応会社。国内ではJPCERT/CCと、警察のサイバー事案の相談窓口	案件の概要と時系列

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

0. 初動：対応の主導権を確保

テナント、変更されないアカウント・オブジェクトID、別名、ID種別、最初の検知、根拠のある不正操作を記録し、案件責任者と判断権限を決めます。
信頼できる管理環境から組織の手順でアクセスを制限します。重要なワークロードと緊急用IDの依存先を調整し、緊急封じ込めを遅らせずに証拠を保全します。
既知の独立した連絡先で本人確認します。疑わしいメールボックスへ回復用秘密情報を送らず、攻撃者に指示された操作を再現させません。

A01〜A04のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A01. 失敗した認証試行だけでなく、不正アクセスを疑う根拠があるか？	インシデントを起票し、リスクに応じて封じ込める。全体像の完成を待たない。	不審な試行の調査を続け、正常と説明できる証拠を確認してから終結する。	元のアラート、成功した操作、信頼できる経路での本人確認、UTC時刻。	SOC＋IAM
A02. 特権・共有・外部利用者・ワークロードのIDか？	影響範囲を引き上げて担当者を招集。緊急用アクセスと業務依存先を保護する。	一般利用者の権限と接続先サービスを確認。低権限でもデータは露出し得る。	テナント・オブジェクトID、ロール、グループ権限、ID種別、アプリ依存関係。	IAM＋サービス担当＋責任者
A03. 悪用が進行中、または追加の不正アクセスが懸念されるか？	権限に基づきサインインとセッションを制限。重要サービスの例外は関係者と調整する。	証拠を保全し、過去のセッションを確認。活動停止だけでは根絶を示せない。	直近のアプリ操作、セッション、制限結果、業務影響。	IAM＋SOC＋アプリ担当
A04. 信頼できる連絡先・正常な管理環境・証拠へのアクセスがあるか？	責任者と収集担当を決め、原本と対応履歴をUTCで記録する。	別の信頼できる連絡経路と管理アクセスを確保し、ログ不足をエスカレーションする。	案件ID、検証済み連絡方法、ログ可用性、取得時刻、証拠アクセス。	インシデント責任者＋DFIR

Microsoft 365では侵害アカウントへの対応ガイドを確認してください。アクセス制限、認証方式、メール設定、アプリ権限の確認は別々の作業です。本台帳は運用上の独自設計であり、ベンダー手順の転載ではありません。

具体的な操作手順

サインインを止めます。 Entra管理センター →「Entra ID」→「Users」→「All users」→ ユーザーを選ぶ →「Account status」の「Edit」→「Account enabled」のチェックを外す →「Save」。
セッションを取り消します。 同じユーザーの「Overview」ページで「Revoke sessions」を選びます。Microsoft 365管理センターでは「Users」→「Active users」→ ユーザー →「Account」タブ →「Sign out of all sessions」が同じ操作です。PowerShellでは次のとおりです。
```
Connect-MgGraph -Scopes "User.ReadWrite.All","User.RevokeSessions.All"
Update-MgUser -UserId <user-object-id> -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId <user-object-id>
```
ハイブリッドのアカウント： オンプレミスのActive Directoryから同期しているアカウントは、そちらでも無効にします（Disable-ADAccount -Identity <sAMAccountName>）。そうしないと、同期で再び有効になることがあります。
遅れがあることを知っておきます。 発行済みのアクセストークンは最大で1時間ほど有効です。継続的アクセス評価に対応したアプリは、より早く反応します。後の活動と比べられるよう、操作した時刻を記録します。
本人を確認します。 社内名簿や人事記録の電話番号を使います。アカウントが戻るまでの連絡方法を決めておきます。

確認： ユーザーのサインインログで新しい試行が無効化により失敗しており、取り消しの時刻が案件に記録されていること（A01〜A04）。Microsoft：ユーザーアクセスの取り消し

1. 偵察：標的化と侵入後の探索を確認

最初の不審な成功より前から時系列を作り、古い証拠が見つかったら遡ります。タイムゾーン、実イベント時刻、取り込み遅延、保持期間を確認します。
外部の標的化と侵入後の探索を比較します。すべてのスキャン・認証失敗・ディレクトリ照会を同じ攻撃に結び付けません。
利用者・端末・ネットワーク・資源の情報を併用します。海外IP、あり得ない移動、見慣れたIPは判断材料であり、それだけで結論を出しません。

A05〜A08のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A05. 公開されたID情報や既知の関係が標的化の手掛かりになるか？	標的化の仮説を記録し、関連IDを調査。攻撃者の帰属は断定しない。	他の侵入仮説を残す。公開情報に手掛かりがなくても否定できない。	誘導内容、なりすまされた役割、公開情報、関連する報告。	SOC＋脅威インテリジェンス
A06. 列挙・パスワードスプレー・繰り返す認証試行があるか？	狙われたIDと成功したアクセスを照合し、影響したIDを優先する。	トークン悪用と既存セッションを確認。失敗の連続が不要な攻撃もある。	IdP・VPNの結果、送信元の文脈、標的ID、頻度、成功イベント。	SIEM＋IAM
A07. 利用者・グループ・メールボックス・クラウド資産を列挙したか？	侵入後の探索として扱い、照会先と使用権限を確認する。	監査範囲と平常時の操作を確認してから否定判断をする。	ディレクトリ・アプリ監査、オブジェクトID、API操作、通常の利用傾向。	SIEM＋アプリ担当
A08. 異常な場所や端末について、検証済みの説明があるか？	出張・VPN・プロキシ・端末変更を記録し、アクセス後の操作も確認する。	複数の根拠で不明なアクセスを調査。位置情報だけでは侵害の証明にならない。	信頼できる経路での聞き取り、端末状態、IPの文脈、認証詳細、操作。	SOC＋IAM＋利用者支援

具体的な操作手順

サインインログを開きます。 Entra ID →「Monitoring & health」→「Sign-in logs」。ユーザーで絞り込み、期間を少なくとも30日にします。「User sign-ins (interactive)」と「User sign-ins (non-interactive)」の両方を確認します。盗んだトークンを使う攻撃者は、後者にしか現れないことがよくあります。
それぞれの表示をダウンロードし（CSVまたはJSON）、ほかを変更する前に案件フォルダーに保存します。
失敗のパターンを読みます。 1つのアドレスから多数のユーザーへの失敗はパスワードスプレー、多数のアドレスからこの1アカウントへの失敗は標的型を示します。
侵入後の探索を確認します。 Entra ID →「Monitoring & health」→「Audit logs」でこのユーザーを実行者として絞り込み、統合監査ログ（段階4）でも、本人が普段しない検索、メールボックスの一覧取得、ファイルの閲覧を探します。
場所は判定ではなく手がかりとして扱います。 海外のIPはVPNかもしれず、見慣れたIPは近くのプロキシを使う攻撃者かもしれません。端末、ブラウザー、アプリ、時刻をあわせて見ます。

確認： 最初の不審な成功より前から始まる時系列があり、普段と違う送信元に「説明済み」「未説明」の区別が付いていること（A05〜A08）。

2. 武器化：推測せずに攻撃準備を評価

武器化は攻撃者の準備段階です。被害側に証拠がなければ不明と記録し、ツールや帰属を推測で埋めません。
誘導やファイルを入手できた場合は、権限のある隔離解析向けに保全します。対応端末で実行せず、通常のブラウザーで悪性リンクへ再訪せず、機密検体を公開サービスへ送信しません。
パスワード窃取、トークン・Cookie窃取、不正アプリ同意、回復手順の悪用を区別します。併発する場合もあり、除去すべき対象が異なります。

A09〜A12のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A09. 不審な誘導・類似サイト・認証情報収集の痕跡があるか？	原本と取得経緯を保全し、承認された隔離環境で分析する。	攻撃準備は未観測と記録して対応継続。検体なしでも封じ込めは可能。	メッセージ原本、URL文字列、画面記録、配信の文脈、解析結果。	メールセキュリティ＋DFIR
A10. トークン窃取・情報窃取マルウェア・AiTMの可能性があるか？	IDのセッションと、実際に使った端末を別々の作業として調査する。	他の認証情報窃取や回復手順の悪用も確認。パスワードだけの侵害と決めない。	本人の操作、ブラウザー・EDR証拠、認証の流れ、セッション情報。	EDR＋IAM＋DFIR
A11. 不審なアプリや同意への誘導が攻撃準備に関係するか？	アプリ・テナントID、要求権限、発行元を記録し、付与された権限を調査する。	実際の同意・アプリ変更も確認。誘導文がなくても不正なアプリ権限は否定できない。	同意画面、アプリ所有者、発行元の根拠、権限、作成時刻。	IAM＋クラウド／SaaS担当
A12. IOCを封じ込めや追加調査に使える十分な根拠があるか？	担当と期限・再評価時刻を決めて限定的に制限し、業務影響を確認する。	まず文脈を収集。共有のID基盤やクラウド全体の一括遮断を避ける。	種類、出所、観測期間、確度、観測した活動との関係。	脅威インテリジェンス＋ネットワーク＋SOC

具体的な操作手順

おとりのメールを開かずに保全します。 本人にOutlookの「Report」ボタンで報告してもらうか、Defenderポータルの「Submissions」（security.microsoft.com/reportsubmission）で回収します。メッセージヘッダーを案件にコピーします。
普段のブラウザーでリンクを開きません。 分析が必要なら、承認済みのサンドボックスや委託先を使います。
サインインログから手口を読みます。 不審なサインインを開き、「Authentication Details」と、アプリ、認証プロトコルを確認します。本人のMFAの数分後に、同じアプリへ見慣れないアドレスからサインインしていれば、AiTMによるトークン窃取が疑われます。認証プロトコルが「Device code」なら、デバイスコードフィッシングが疑われます。
Entra ID P2があればリスク検出を確認します。 Entra管理センター →「ID Protection」の、危険なユーザーと危険なサインインのレポートです。
手口ごとに分けて記録します。 パスワードの窃取、トークンの窃取、悪意ある同意、回復手続の悪用は、それぞれ片付け方が違います。

確認： 攻撃者が最も可能性の高い方法でどう侵入したかを、証拠と確度付きで文書にしていること（A09〜A12）。

3. 配信：アクセスが露出した経路を特定

責めずに聞き取ります。何を受け取り、どのIDと端末を使い、何を入力・承認・導入・共有したか、時刻とともに確認します。
配信・支援の原本記録を保全します。クラウドIDだけの侵害では、メールやマルウェアの導入がない場合もあります。
関連する受信者、別端末、ゲストテナント、委託先IDを確認します。誘導が関係する場合はフィッシング手順を併用します。

A13〜A16のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A13. メール・チャット・QR・電話・共有文書が操作を促したか？	原本を保全し、操作・端末・他の受信者を特定。フィッシング手順を併用する。	認証情報再利用、セッション窃取、回復手順、委託先アクセスを調査する。	原本、配信追跡、対象ID、実際の端末、操作時刻。	メールセキュリティ＋SOC
A14. ヘルプデスク・回復手順・電話番号・MFA再設定が悪用されたか？	支援記録を保全し、不正な回復経路を制限。別経路で本来の利用者を確認する。	登録・再設定の履歴を調査。回復経路の侵害が検知より前の場合もある。	問い合わせ記録、認証方式変更、回復イベント、確認済み連絡先履歴。	IAM＋サービスデスク
A15. 過去に露出・再利用した認証情報で、誘導なしの侵入を説明できるか？	正しい管理元で認証情報を変更し、別サービスでの再利用も担当者と評価する。	盗まれたトークンやアプリ認証情報を除外せず、他の侵入分岐を確認する。	信頼できる露出通知、関連する認証記録、認証情報の管理元。	IAM＋利用者＋サービス担当
A16. 他の利用者・ゲストテナント・委託先・共有IDも関係するか？	範囲を拡大し、承認された連絡経路でテナント・委託先の担当と連携する。	確認したIDと境界を記録し、新たな証拠が出たら範囲を見直す。	ゲスト・ホームテナントID、共有アクセス、委託先記録、関連活動。	責任者＋IAM＋サードパーティリスク

誘導が関係する場合はフィッシング対応プレイブックを並行実施します。ID封じ込めだけでは他の配信済みメッセージを除去できません。

具体的な操作手順

責めずに本人の話を聞きます。 何が届いたか（メール、Teams、QRコード、電話）、何をクリック・入力・承認したか、どの端末で、いつか。答えはそのまま引用として書き留めます。
メッセージとほかの受信者を探します。 Exchange管理センター →「Mail flow」→「Message trace」→「Start a trace」で、送信者と時間範囲を指定します。Defender for Office 365 プラン2があれば、Defenderポータル →「Email & collaboration」→「Explorer」ですべての受信者が分かり、コピーを削除できます。
サービスデスクを確認します。 期間中にこのユーザーのパスワードやMFAの再設定依頼があったか、依頼者の本人確認はできていたか。
範囲を広げます。 同じおとりを受け取ったユーザーや、同じ攻撃元アドレスからサインインされたユーザー。メッセージそのものについてはフィッシング対応プレイブックに従います。

確認： 侵入経路が証拠付きで記録され、同じ痕跡を持つほかの受信者やアカウントに担当者がいること（A13〜A16）。

4. 悪用：不正な利用を検証

サインインと資源の操作を照合します。認証成功、権限による許可、実際のデータ操作を分けて記録します。
対話型・非対話型の利用、MFAの文脈、デバイスコード、セッション窃取を確認します。MFA成功の情報だけで本来の利用者の操作と断定しません。
個人・未管理端末を含め、実際に使用した端末を評価します。端末侵害の証拠があれば別の調査を開始しますが、不審な添付だけでは実行の証明になりません。

A17〜A20のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A17. 成功したサインインや資源への操作は不正か？	ID・アプリ・資源を結び付け、アクセスを封じ込めて時系列を保全する。	阻止した認証試行と資源アクセスを分け、既存セッションと監査範囲を確認する。	認証結果、資源の監査、IDオブジェクト、アプリID、本人確認。	IAM＋SIEM
A18. 攻撃者のためにMFA・デバイスコード・回復の確認を完了したか？	不審なセッションを失効し、登録方式を確認して同意やトークン発行を調査する。	認証詳細を確認。過去のMFA情報や盗まれたセッションでは新たな確認がない場合も。	認証の流れ、確認方式、本人申告、端末・アプリID、発行状況。	IAM＋SOC
A19. パスワードなしで盗まれたCookieやトークンが使われた可能性は？	セッションと対象アプリを封じ込め、トークンが露出した原因を調査する。	セッションの証拠が不足するなら仮説を残す。パスワード変更は安全の証明ではない。	取得可能なセッション・相関ID、資源操作、端末・ブラウザー証拠。	IAM＋アプリ担当＋EDR
A20. 侵害IDで端末実行や横展開が起きたか？	権限に基づき対象端末を隔離し、遠隔セッションと到達可能なシステムを調べる。	クラウドとメールの調査を継続。ID侵害にマルウェア実行は必須ではない。	EDR親子関係、VPN・RDP・SSH、クラウド管理操作、到達先の証拠。	EDR＋ネットワーク＋SIEM

Microsoftのトークン窃取調査は、利用者・セッションと端末の調査を区別しています。両方の証拠を保全し、IDログだけの検索で端末が正常と断定しません。

具体的な操作手順

攻撃者のサインインと操作を突き合わせます。 下のハンティングのKQLか、ダウンロードしたログで、不審なサインインのそれぞれと、その後に起きたことを並べます。

統合監査ログを検索します。 ユーザーと期間を指定し、Microsoft Purviewポータル →「Audit」→「Search」（またはDefenderポータルの監査ログ検索）か、Exchange Online PowerShellで検索します。

Connect-ExchangeOnline
Search-UnifiedAuditLog -StartDate "2026-09-06" -EndDate "2026-10-06" -UserIds user@example.com -ResultSize 5000 |
  Select-Object CreationDate,Operations,ClientIP,AuditData | Export-Csv .\ual-user.csv -NoTypeInformation

MFAの状況を確認します。 各不審なサインインの「Authentication Details」に、MFAが満たされたかとその方法が表示されます。見慣れない端末で「トークン内の要求によってMFAが満たされた」（MFA requirement satisfied by claim in the token）とあれば、セッションの窃取を示しています。
端末を確認します。 本人のPCが感染しているおそれがある場合（添付ファイルが実行された、インフォスティーラーが疑われるなど）は、EDRやITの委託先と端末の調査を始めます。

確認： 不審なサインインそれぞれが、その後の操作と結びつけられているか「操作なし」とされ、ログの範囲が記録されていること（A17〜A20）。

5. インストール：IDの永続化を調査

ID侵害のインストール段階は、マルウェア導入ではなくIDやアプリの永続化に相当する場合があります。現在見える設定だけでなく、履歴と有効権限を比較します。
可能な範囲で不正な認証方式、権限、ルール、アクセス変更を除去前に保全します。転送に加え、メール委任と非表示ルールも確認します。
アプリ専用認証情報とSaaS固有アクセスを利用者IDと分けて確認します。連携認証やID管理基盤の変更は、広範な指揮体制と専門的な復旧計画へ引き上げます。

A21〜A24のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A21. MFA方式・回復先・登録端末が追加または変更されたか？	変更を保全し、不正な登録を除去して回復手順を保護する。	現在の設定と履歴を比較。攻撃者が消した変更は現状だけでは分からない。	認証方式の監査、端末登録、回復設定、検証済みの正常基準。	IAM＋サービスデスク
A22. 転送・非表示ルール・委任・メールボックス権限に不正があるか？	設定と監査を保全してから不正アクセスを除去し、対象メールを調査する。	メールボックスと管理側の両方を確認。ルール一覧が空でも調査完了とは限らない。	受信・非表示ルール、転送、委任、SendAs権限、管理操作。	メールセキュリティ＋メール基盤担当
A23. OAuth権限・アプリ認証情報・APIキーなどが残されているか？	利用者とアプリのアクセスを別々に確認。不正権限を取り消し、露出した秘密情報を変更する。	アプリ専用アクセス、個人トークン、連携SaaSを担当者と確認する。	アプリ・サービスプリンシパルID、同意、鍵、PAT、SSH鍵、各サービスの監査。	IAM＋クラウド／SaaS担当
A24. ロール・グループ・アクセスポリシー・連携認証が変更されたか？	広範なID基盤インシデントへ引き上げ、証拠と信頼できる管理経路を保護する。	有効な権限と変更履歴を確認し、資格のあるロールや一時的な特権も含める。	ロール・グループ監査、特権有効化、ポリシー変更、連携認証、管理基準。	IAM＋ディレクトリ＋責任者

アプリが関係する場合は不正・侵害アプリの調査ガイドを参照します。最初の利用者IDを修復しても、アプリ独自の認証情報やアプリケーション権限が残る場合があります。

具体的な操作手順

MFAの方法： Entra ID →「Users」→ ユーザー →「Authentication methods」。各方法を、本人が登録したと言うものと比べます。PowerShellではGet-MgUserAuthenticationMethod -UserId <user-object-id>です。見覚えのない方法は、記録してから削除します。

転送と受信トレイのルール（Exchange Online PowerShell）：

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,Identity
Get-MailboxPermission -Identity user@example.com | Where-Object { -not $_.IsInherited }
Get-RecipientPermission -Identity user@example.com

アプリへの同意： 本人が与えた委任の許可を一覧にし、信頼できないものを削除します。

Connect-MgGraph -Scopes "DelegatedPermissionGrant.ReadWrite.All"
Get-MgOauth2PermissionGrant -Filter "principalId eq '<user-object-id>'" | Format-List Id,ClientId,Scope
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId <grant-id>

ポータルでは、Entra ID →「Enterprise apps」→ アプリ →「Permissions」で確認できます。

端末とロール： ユーザーの「Devices」ページで見覚えのない登録を、監査ログで本人による、または本人に対するロール・グループ・ポリシーの変更を確認します。

確認： すべての方法、ルール、権限、許可、端末が、本人の確認済みか、記録して削除済みであること（A21〜A24）。Microsoft：アプリの権限の確認

6. C2：継続する支配を特定・停止

従来のC2はマルウェアと攻撃者の操作経路です。ここでは正規ポータル・API・セッション・委任関係による支配の継続も追跡しますが、すべてを典型的なマルウェアC2と呼ぶわけではありません。
処置ごとに対象、時刻、結果、検証に使った証拠を記録します。処置後の資源操作を調べ、ログの到着遅延と新たな操作を区別します。
サインイン制限、パスワード変更、IDセッション失効は別の制御です。対象アプリのセッションと別の認証情報を各担当者と検証します。

A25〜A28のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A25. ポータル・API・遠隔操作の不正利用が続いているか？	IDと操作先を追跡し、実際に使われているアクセス経路を遮断する。	非対話型認証と資源ログを確認。典型的なマルウェアC2がないだけでは否定できない。	アプリ操作、API監査、遠隔アクセス、サインイン、起点端末情報。	SIEM＋IAM＋ネットワーク
A26. アプリ独自のセッションや別の認証情報でアクセスが続くか？	アプリ担当がセッションを失効し、ローカル・APIアクセスを制限して停止を検証する。	アプリの認証方式と、独立したアクセスがないことの証拠を記録する。	SaaSセッション制御、ローカルID、アプリパスワード、APIキー、アクセスログ。	アプリ担当＋IAM
A27. サインイン制限と失効で、不審なアクセスは止まったか？	サービスごとの検証時刻を記録し、認証試行と資源操作の再発を監視する。	ID管理元、アプリセッション、別の認証情報を再確認し、処置失敗を引き上げる。	制御結果、処置後の認証、資源操作、既知のログ遅延。	IAM＋SOC＋アプリ担当
A28. 別ID・ワークロード・信頼関係・回復経路で支配が続くか？	関連するIDや信頼関係を封じ込め、最初の利用者だけで案件を閉じない。	確認した経路と監視範囲を記録し、新たな証拠で見直す。	新規ID、アプリ専用アクセス、ゲスト関係、連携認証、回復変更。	IAM＋クラウド＋責任者

Microsoftは、アプリが発行したセッションCookieをEntraから直接失効できないと説明しています。失効の挙動はアプリやトークン方式に依存するため、全サービスでの即時サインアウトを約束しません。処置要求の成功だけでなく資源へのアクセスを検証します。緊急時のアクセス失効。

具体的な操作手順

取り消し後の時刻で確認します。 サインインログを、セッションを取り消した時刻から絞り込みます。不明な送信元からの成功が、対話型・非対話型のどちらかにあれば、アクセスは続いています。
ほかの入口を探します。 アプリパスワード（Entra ID → ユーザー →「Authentication methods」に削除の操作があります）、メールを同期しているモバイル端末（Get-MobileDevice -Mailbox user@example.com）、独自のセッションを持つ他社アプリ。
それらも封じ込めます。 段階5でアプリへの許可を削除し、各アプリの担当者に自社システム側でセッションを終わらせるよう依頼し、悪意あるアプリは遮断します（Enterprise apps → アプリ →「Properties」→「Enabled for users to sign-in?」→「No」）。
操作ごとに記録します。 何を、対象、時刻、結果、どこで確認したか。

確認： 封じ込めの時刻以降、対話型・非対話型・アプリのログのいずれにも、不明な送信元からの成功やアプリの活動がないこと（A25〜A28）。

7. 影響：データ・詐欺・サービス被害を評価

機密性・完全性・可用性・金銭被害を別々に評価し、確定・疑い・観測不能を分けます。
送信メール、文書・リポジトリ閲覧、共有、出力、接続先の秘密情報を調査します。ダウンロード記録なしは閲覧・コピーなしの証明ではありません。
経理は既知の連絡先で支払い確認や回収対応を行います。法務・プライバシーは案件に応じた通知・保全・契約上の義務を判断します。この手順では一律の報告期限を指定しません。

A29〜A32のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A29. 機微なメール・ファイル・データが閲覧・出力・共有されたか？	データ担当と法務・プライバシーを招集し、範囲を絞ってアクセス証拠を保全する。	証拠なしとアクセスなしを区別し、監査不足と保持期間の限界を記録する。	メール・ファイル閲覧、取得、出力、共有変更、データ分類、受信者。	DFIR＋データ担当＋法務／プライバシー
A30. フィッシング送信・支払先変更・なりすましが行われたか？	経理とメール担当を招集。既知の連絡先で支払い・連絡先の変更を検証する。	送信・配信追跡と業務記録を確認し、利用者の記憶だけに依存しない。	配信追跡、送信・削除済みメール、受信者範囲、支払記録、承認。	メールセキュリティ＋経理＋責任者
A31. 他サービス・秘密情報・リポジトリ・別IDへ影響が広がったか？	関連調査を起票し、依存先の担当と露出した秘密情報を変更する。	確認した資源と権限を記録。1つのIDが多くの接続先へ到達する場合がある。	SaaS・クラウド・リポジトリ監査、保管庫アクセス、サービス認証、ID関係。	クラウド／IT＋IAM＋SIEM
A32. 削除・暗号化・停止・脅迫につながったか？	事業継続と必要なランサムウェア対応を開始し、影響の証拠を保全する。	機密性と詐欺の調査を続ける。停止がないだけでは業務被害を否定できない。	削除・変更された資源、稼働状況、脅迫の主張、復元時点、利用者影響。	責任者＋IT＋法務／プライバシー

破壊活動やランサムウェアが関係する場合は、ランサムウェア対応プレイブックを関連作業として開始します。IDを回復しても、損傷したデータや漏えいリスクは自動的に解消しません。

具体的な操作手順

読まれたもの： メールボックスへのアクセス記録を検索します。Bindの記録は個々のメッセージ、Syncの記録はフォルダーごとクライアントにダウンロードされたことを示します。
```
Search-UnifiedAuditLog -StartDate "2026-09-06" -EndDate "2026-10-06" -UserIds user@example.com -Operations MailItemsAccessed -ResultSize 5000 |
  Export-Csv .\mailitemsaccessed.csv -NoTypeInformation
```
送られたもの： Exchange管理センター →「Mail flow」→「Message trace」→ 送信者にこのユーザー → インシデントの期間。受信者を書き出します。注意喚起が必要かもしれません（下のテンプレート）。
ファイルと共有： Purviewの「Audit」で、このユーザーのSharePointとOneDriveでのファイルの閲覧、ダウンロード、共有の操作を検索します。
お金： このアカウントのメール経由で支払いや振込先の変更がなかったか経理に確認し、あれば既知の番号ですぐ銀行に連絡します。

確認： 読まれたデータ、送られたメール、共有されたファイル、影響を受けた支払いを別々の一覧にし、それぞれ「確認済み」「疑い」「確認されず」を付けていること（A29〜A32）。Microsoft：MailItemsAccessedによる調査

8. 復旧：検証してからアクセスを戻す

侵入原因、端末、ID設定、セッション、アプリ権限、露出した秘密情報の対処一覧を作り、各項目に検証担当を割り当てます。
正常な端末と信頼できる経路で回復します。正しいID管理元で再設定し、同期・連携認証は担当者と処理します。対応可能な場合は承認済みのフィッシング耐性MFAへ再登録します。
最小権限で段階的に戻し、依存サービスと資源操作を確認します。責任者と監視期間・終了条件を決め、影響評価と業務承認を得て終結します。

A33〜A36のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
A33. 侵入原因・不正設定・影響端末への対処が完了したか？	通常アクセスを戻す前に、証拠に基づいて対処結果を検証する。	制限を維持し、原因・永続化・端末に残る課題へ担当者を割り当てる。	修正結果、信頼できる端末の評価、設定基準、アクセスレビュー。	DFIR＋IAM＋IT
A34. 本来の利用者と、回復先・端末の信頼性を確認できたか？	正しいID管理元で再設定し、承認済みの強い認証方式へ安全に再登録する。	本人や端末の不確実性を解消してから回復用の認証情報を渡す。	独立した本人確認、正常端末、承認された回復連絡先、管理元。	サービスデスク＋IAM＋EDR
A35. 段階的なアクセス復旧で、セキュリティと業務を検証できたか？	最小権限で段階的に復旧し、アプリ・アラート・切り戻し準備を確認する。	復旧を止めて不合格項目を修正。症状を消すためだけに制御を弱めない。	ログイン試験、MFA強制、アプリ権限、業務試験、監視結果。	IAM＋アプリ担当＋SOC
A36. 残る不確実性を明示して、責任者が終結を承認できるか？	影響、終結承認、監視条件、担当付きの改善期限を記録する。	案件を継続し、未解決の分岐すべてに証拠担当と再確認時刻を割り当てる。	最終時系列、範囲、封じ込め検証、影響判断、復旧承認。	責任者＋業務＋法務／プライバシー

具体的な操作手順

先に端末をきれいにします。 本人は、スキャンまたは再構築した端末からだけ再サインインします。
パスワードとMFAを再設定します。 Entra ID →「Users」→ ユーザー →「Authentication methods」→「Reset password」、続けて「Require re-register multifactor authentication」。ハイブリッドのアカウントはActive Directoryで再設定します。対応していれば、パスキーなどフィッシングに強い方法を選びます。
アカウントを再び有効にし（段階0の停止を解除）、電話で一緒に登録を進めます。
段階的にアクセスを戻し、 2週間は毎日サインインログを確認します。何があれば案件を再開するかを事前に決めておきます。
侵入の原因を直します。 たとえば、条件付きアクセスで準拠した端末やフィッシングに強いMFAを必須にする、アプリへのユーザーの同意を制限する、使っていなければデバイスコードフローを遮断する、などです。

確認： 本人が信頼できる端末で普段どおり働け、監視で不明なサインインがなく、責任者が終結の判断を記録していること（A33〜A36）。

ハンティング：対象IDを限定したKQLとSplunk

実際のIOCは掲載していません。 特定攻撃者や悪性IPの報告ではなく、汎用の対応ガイドです。検証済みのオブジェクトID・利用者名・案件証拠を使用します。4例とも読み取り専用で、文書・スキーマを照合したものです。実環境では実行していません。

KQLの対象はMicrosoft Sentinel／Azure Monitor Log Analyticsであり、Defender XDR Advanced Huntingではありません。記載したテーブルへの取り込み、ワークスペース・テーブルの閲覧権限、保持期間、対応するテーブルプランが必要です。ライセンスやコネクターが存在するだけでは監査収集を証明できません。担当者と取得状況を確認してから解釈します。

明示した置換箇所を変更します。最初の2例は検証済みの変更されないEntra利用者オブジェクトIDを使い、テナントも記録します。信頼できない文字列を構文へ直接貼り付けないでください。対象期間は24時間、表示上限は500件ですが、検索処理全体の負荷を必ず制限するものではありません。過去の案件は明示的なUTC範囲を使い、上限に達したら時間帯を分けて全結果を保存します。先頭・末尾の記録が侵害の開始・終了とは限りません。

1. サインイン時系列： SigninLogsとAADNonInteractiveUserSignInLogsの両方が必要です。欠落を抑制せず、収集上の課題として解決します。両方に共通する項目を出力し、ResultTypeは情報源ごとの意味を確認するため変換していません。成功・失敗・条件付きアクセス・資源操作を併せて確認します。利用者用ログであり、サービスプリンシパル・マネージドID全体は対象外です。既知IP、VPN、正常なトークン更新には文脈が必要で、認証ログだけではデータ閲覧を証明できません。

2. ディレクトリ変更： AuditLogsで利用者が実行者またはTargetResources内の対象になった記録を確認し、全対象情報を保持します。記録があるだけでは不正ではありません。動的項目の構造を実データで確認し、InitiatedBy.user.idとTargetResources[].idが抽出できるか検証します。攻撃者作成アプリや別IDの操作は、それぞれのオブジェクトへ追加調査が必要です。有効権限の完全な一覧を作る検索ではありません。

3. メール操作： OfficeActivityをExchangeに絞り、UPNを操作主体またはメール所有者として検索します。現在と過去の別名も確認してください。管理者操作では対象メールボックスが別項目だけに記録される場合があるため、検証済みのIDへ展開します。監査可用性、ライセンス、保持、イベント集約が可視性に影響します。0件やダウンロード記録なしは露出なしの証明ではなく、SharePoint・OneDrive・他SaaSの全操作も対象外です。

4. Splunk認証： 対象のindex・sourcetypeでCIM形式の_time、user、action、src、dest、app、authentication_method、signatureが必要です。高速化データモデルではなく生イベントを検索します。権限とマッピング、特にuserがUPN・短い名前・別IDのどれかを確認します。共有NATや正規管理操作が悪用に似る場合があります。原記録を保全し、アプリと端末の活動へ調査を広げてください。

KQL：対話型・非対話型サインインの時系列

Download account-signin-timeline.kql

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Requires BOTH user sign-in tables. Replace the Entra object ID.
let TargetUserId = "REPLACE_WITH_ENTRA_USER_OBJECT_ID";
union withsource=LogTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated between (ago(24h) .. now())
| where UserId =~ TargetUserId
| project TimeGenerated, CreatedDateTime, LogTable, UserId, UserPrincipalName,
    IPAddress, AppDisplayName, AppId, ResourceDisplayName, ResultType,
    ResultDescription, ConditionalAccessStatus, CorrelationId
| order by TimeGenerated asc
| take 500

KQL：対象IDが実行者または変更対象の操作

Download account-directory-changes.kql

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Return events initiated by the user OR naming the user as a target.
let TargetUserId = "REPLACE_WITH_ENTRA_USER_OBJECT_ID";
AuditLogs
| where TimeGenerated between (ago(24h) .. now())
| extend ActorId = tostring(InitiatedBy.user.id),
    Targets = iff(coalesce(array_length(TargetResources), 0) == 0, dynamic([{}]), TargetResources)
| mv-expand Target = Targets
| extend TargetId = tostring(Target.id)
| where ActorId =~ TargetUserId or TargetId =~ TargetUserId
| summarize arg_max(TimeGenerated, *) by Id
| project TimeGenerated, Id, OperationName, Result, InitiatedBy,
    TargetResources, CorrelationId
| order by TimeGenerated asc
| take 500

KQL：操作主体・所有者からメールを確認

Download account-mailbox-activity.kql

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Replace the verified UPN; also search historical aliases separately.
let TargetUPN = "REPLACE_WITH_VERIFIED_USER_UPN";
OfficeActivity
| where TimeGenerated between (ago(24h) .. now())
| where OfficeWorkload == "Exchange"
| where UserId =~ TargetUPN or MailboxOwnerUPN =~ TargetUPN
| project TimeGenerated, OfficeId, Operation, ResultStatus, UserId,
    MailboxOwnerUPN, ClientIP, OfficeObjectId, Parameters
| order by TimeGenerated asc
| take 500

Splunk：1つのIDの認証イベント

Download account-authentication-review.spl

index="REPLACE_WITH_AUTH_INDEX" sourcetype="REPLACE_WITH_AUTH_SOURCETYPE" earliest=-24h latest=now
| where lower(user)=lower("REPLACE_WITH_EXACT_USER")
| sort 500 + _time
| table _time user action src dest app authentication_method signature

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

［角かっこ］の部分をすべて置き換えてください。パスワードやコードは書かないでください。社外に出す文面は、法務または個人情報の担当者が確認します。

本人への連絡（電話または別の経路で）

侵害されたメールボックスには送らないでください。

［氏名］さん、［IT／セキュリティ］の［自分の名前］です。
ご本人ではないと考えられるサインインを確認したため、アカウントを一時的に止めています。懲戒の話ではありません。早めに知らせてもらえることが、皆の助けになります。
今お願いしたいこと：
1. こちらから折り返すまで、どの端末でもサインインしないでください。
2. ［日時］ごろに受け取ったもの、クリック・入力・承認したもの、使った端末を教えてください。
3. こちらからお願いした場合は、仕事で使う端末の電源は入れたまま、Wi-Fiから切断してください。
［時刻］にこの番号へお電話し、アカウントを設定し直します。ほかの誰かからコードやパスワードを求める電話やメールがあっても応じず、私たちに知らせてください。

侵害されたアカウントからのメールを受け取った方への注意喚起

段階7のあと、信頼できる別のアカウントから送ります。

件名：［氏名］から［開始］〜［終了］に送られたメールについてのお願い

［受信者名］様

［日付］の［開始時刻］から［終了時刻］の間に、当社の［氏名］のアカウントから、本人の知らないところでメールが送信されました。そのメールは［件名「…」でした／共有ファイルを開くよう求めるものでした／振込先の変更を求めるものでした］。
該当するメールを受け取られた場合は：
・リンクをクリックしたり、添付ファイルを開いたりしないでください。
・開いたあとにパスワードを入力された場合は、そのパスワードを変更し、貴社のIT担当にご相談ください。
・振込先の変更や支払いを求められた場合は対応せず、［既知の電話番号］までお電話ください。
アカウントはすでに保護し、調査を進めております。ご迷惑をおかけし、申し訳ございません。
［氏名・役職・会社名・電話番号］

社内向け状況報告

件名：【インシデント 案件番号】アカウント侵害 第［番号］報（［時刻］時点）

アカウント：［ユーザー、オブジェクトID］　状況：［封じ込め済み／調査中／復旧中］
侵入方法：［例：セッション窃取を伴うフィッシング（可能性が高い／確認済み）］
実施済み：［時刻］にサインインを停止しセッションを取り消し。［MFAの方法／受信トレイのルール／アプリへの許可］を記録したうえで削除。
判明していること：［例：社外へのフィッシングメール612通、閲覧されたメッセージ140件、ファイルのダウンロードなし］
未確認の事項：［例：本人のPCが感染しているか］
次の対応と担当：［対応 － 担当者 － 期限］
次回報告：［時刻］。責任者：［氏名］

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

1. 何が起きたか：［ユーザー・役割］のMicrosoft 365アカウントが、［時刻］から［時刻］まで攻撃者に使われました。原因は［フィッシング／パスワードの使い回し］の可能性が高いです。
2. 現在の状態：攻撃者のアクセスは［除去し確認済み／除去済みで確認中］です。
3. これまでの影響：［例：顧客N社にフィッシングが送信、Xを含むメールボックスの内容が閲覧、支払いの被害なし］
4. 必要な判断：［例：フィッシングを受け取った顧客への連絡、漏れた契約書の法的評価、営業部門へのフィッシングに強いMFAの義務化］
5. 次回報告：［時刻］。責任者：［氏名］

具体例：盗まれたセッションと隠しルール

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

状況： 従業員60人の商社で、営業マネージャーが月曜16:39に「共有ファイル」のリンクをクリックし、サインインしてMFAの要求を承認しました。そのページは中間者型のプロキシでした。

火曜10:05 報告。 顧客2社から、営業マネージャーからの不審な共有ファイルのメールについて問い合わせの電話があります（A01、A13）。
10:12 封じ込め。 インシデント責任者を務めるIT管理者がサインインを止めてセッションを取り消し、マネージャーの席の内線に電話して、何も送っていないことを確認します（A03、A04）。
10:30 侵入方法。 サインインログに、16:41の本人のサインインと、16:42にホスティング事業者から同じアプリへのサインインがあり、MFAは「トークン内の要求によって満たされた」となっていました。セッションの窃取です（A10、A17〜A19）。
10:50 置き土産。 16:50に2つ目のAuthenticatorアプリが登録されていました（A21）。「請求」や「支払」を含むメールを目立たないフォルダーに移して既読にする隠しルールがありました（A22）。「Mail Sync」というアプリにメールへのアクセスが許可されていました（A23）。それぞれ記録してから削除します。
11:20 封じ込めの確認。 攻撃者のアドレスからの対話型・非対話型のサインインは10:14以降止まり、許可を削除したあとはアプリの活動も続いていません（A25〜A27）。
12:00 影響。 メッセージ追跡で、夜間に社外の連絡先へ612通が送られていたと分かります（A30）。メールボックスへのアクセス記録では、顧客との契約書を含む140通が個別に開かれていました（A29）。新しい口座への支払いを求められた顧客1社の経理担当が確認の電話をくれたため、金銭の被害はありませんでした。
14:00 連絡。 同僚のアカウントから受信者に注意喚起のテンプレートを送り、法務が契約書の漏えいを評価し（A29）、フィッシングのドメインを遮断します。
16:00 復旧。 PCをスキャンして問題なしと確認します。パスワードを再設定し、MFAはパスキーで登録し直し、営業部門には準拠した端末を必須とする条件付きアクセスを適用します（A33〜A35）。14日間何もなかったことを確認し、責任者が案件を閉じます（A36）。

分かれ目になったこと： パスワードの変更だけでなく、セッションを取り消したこと。アカウントが安全だと宣言する前に、隠しルールとアプリへの許可を探したこと。確認の電話をくれた顧客の行動が、まさに注意喚起のメールでお願いした内容だったこと。

未解決事項と復旧後の改善

一般的な手順だけでは、最初の侵入時刻、盗まれたトークン、全アプリのログアウト、閲覧された全データ、根絶の完了を証明できません。取得不能なログ、別テナント、未管理端末、未確認アプリ、処置の伝播遅延を未解決事項として明記します。すべての行を埋めても、環境全体を網羅した保証にはなりません。

終結時は、機能した検知と見逃した活動、対応権限、証拠収集、本人確認、アプリ失効、復旧試験を振り返ります。改善には担当と期限を付け、テストIDを使った演習で検証します。利用者を責めず、報告の速さと仕組みの改善を評価してください。

参考資料と更新履歴

以下は2026-10-03に確認した資料です。製品・ライセンス・ログ構成が変わるため、実行前に自環境の仕様を確認してください。

2026-10-03：初版。 EN／日本語の判断IDとクエリを一致させて公開。

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

30秒でわかる要点

最初に見つけた1つのアカウントから、調査を広げる

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

事前準備と判断ルール

この手順で使う言葉

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

0. 初動：対応の主導権を確保

具体的な操作手順

1. 偵察：標的化と侵入後の探索を確認

具体的な操作手順

2. 武器化：推測せずに攻撃準備を評価

具体的な操作手順

3. 配信：アクセスが露出した経路を特定

具体的な操作手順

4. 悪用：不正な利用を検証

具体的な操作手順

5. インストール：IDの永続化を調査

具体的な操作手順

6. C2：継続する支配を特定・停止

具体的な操作手順

7. 影響：データ・詐欺・サービス被害を評価

具体的な操作手順

8. 復旧：検証してからアクセスを戻す

具体的な操作手順

ハンティング：対象IDを限定したKQLとSplunk

KQL：対話型・非対話型サインインの時系列

KQL：対象IDが実行者または変更対象の操作

KQL：操作主体・所有者からメールを確認

Splunk：1つのIDの認証イベント

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

本人への連絡（電話または別の経路で）

侵害されたアカウントからのメールを受け取った方への注意喚起

社内向け状況報告

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

具体例：盗まれたセッションと隠しルール

未解決事項と復旧後の改善

参考資料と更新履歴