始める前に確認する3つの前提
サインインログの確認には、相応の管理者ロールが必要です。閲覧だけなら「レポート閲覧者」か「セキュリティ閲覧者」で足ります。全権を持つグローバル管理者で作業する必要はありません。ただし後半の初動対応では、セッションの取り消しとパスワードのリセットに「ユーザー管理者」相当の権限が要ります。メールボックスの確認には Exchange の管理権限が要ります。調査役と対応役を分ける場合は、事前に担当者を決めておいてください。
ログの保存期間はライセンスで変わります。Microsoft Entra ID Free では7日、P1 以上では30日です。Free のテナントで「先週の月曜に何があったか」を調べると、すでにログが消えていることがあります。保存期間の詳細はMicrosoft の公式ドキュメントで確認してください。
調べ始める前に、ログをエクスポートしておきます。調べている間にも、古いログは保存期間を過ぎて消えていきます。被害が確定した場合、エクスポートしたログは社内報告や外部専門家への相談で証拠になります。
手順1：サインインログを開いてエクスポートする
Microsoft Entra 管理センター（entra.microsoft.com）にサインインします。左メニューの「監視と正常性」から「サインイン ログ」を開きます。メニュー名と配置は執筆時点のもので、変更されることがあります。
画面上部には複数のタブがあります。「ユーザーのサインイン（対話型）」は、人がパスワードや多要素認証（MFA、パスワードに加えてスマートフォンなどで本人確認する仕組み）を入力した記録です。「ユーザーのサインイン（非対話型）」は、アプリがトークン（サインイン済みであることを示す一時的な証明）を自動で更新した記録です。最初は対話型タブから見ます。
期間を保存期間の上限まで広げ、「ダウンロード」から CSV か JSON で保存します。一度にダウンロードできる件数には上限があります。件数が多いテナントでは、期間を区切って複数回に分けて保存してください。継続して保存したい場合は、診断設定で Log Analytics やストレージアカウントへ送る方法があります。この方法のライセンス要件は公式ドキュメントで確認してください。
手順2：条件を絞り込む
「フィルターの追加」で条件を加えます。全件を眺めても異常は見つかりません。次の順で絞ると判断しやすくなります。
- 状態：「失敗」と「成功」を切り替えて見比べます。失敗だけが大量に並ぶ場合は、パスワードを推測する試行が行われている可能性があります。
- 場所（国）：自社に拠点や出張者がいない国を探します。場所は IP アドレスから推定した値です。VPN やクラウドサービス経由の通信では、実際の場所と異なることがあります。
- IP アドレス：気になる IP を見つけたら、その IP で絞ります。同じ IP から多数のユーザーに試行していれば、特定の個人ではなく組織全体が狙われています。
- アプリケーション：Exchange Online や SharePoint Online など、どのサービスへのサインインかを確認します。
- クライアント アプリ：「IMAP4」「POP3」「Authenticated SMTP」「Exchange ActiveSync」などの旧式の方式は、MFA を経由しません。業務で使っていないのに記録があれば注意が必要です。
- 条件付きアクセス：条件付きアクセス（場所や端末を条件にサインインを許可・拒否する仕組み）の結果を「成功」「失敗」「適用されていません」で絞ります。「適用されていません」の成功は、ポリシーの対象外になっている穴を示します。
フィルターがうまく機能しないときは、「リセット」で初期状態に戻してから、条件を一つずつ追加し直してください。
手順3：並び方から不審な成功を読み取る
1件ごとの記録よりも、時系列の並び方を見ます。特に注意すべきなのは、失敗が続いた直後に成功が1件ある並びです。パスワードが当たった可能性があります。失敗の理由は各行の詳細にある「サインイン エラー コード」でわかります。50126 はユーザー名かパスワードの誤り、50053 はアカウントのロック、500121 は MFA の失敗を示します。500121 が短時間に何度も続くなら、MFA の承認要求を繰り返し送って誤承認を誘う手口を疑います。コードの意味は公式のエラーコード一覧で確認できます。
もう一つの注意点は、見慣れない場所からの成功です。同じユーザーが東京からサインインした1時間後に、別の大陸から成功していれば、移動では説明できません。行の詳細で「認証の詳細」を開くと、MFA を通過したかどうかを確認できます。MFA を通過していても安全とは限りません。トークンが盗まれた場合は、MFA を通らずにアクセスが続くことがあります。疑わしいユーザーを見つけたら、非対話型タブも同じ条件で確認します。
手順4：不審なサインインを見つけたときの初動
最初にセッションを取り消します。管理センターで対象ユーザーを開き、「セッションの取り消し」を実行します。PowerShell では Microsoft Graph PowerShell の Revoke-MgUserSignInSession を使います。すでに発行済みのアクセストークンは、最大で1時間程度有効なまま残ることがあります。
次にパスワードをリセットします。あわせて、本人の知らない MFA 認証方法が登録されていないかを確認し、あれば削除します。
最後にメールボックスの転送ルールを確認します。攻撃者は外部アドレスへの転送や、特定のメールを削除する受信トレイルールを仕掛けることがあります。Exchange 管理センターで対象メールボックスの転送設定を確認します。受信トレイルールは Exchange Online PowerShell の Get-InboxRule -Mailbox で一覧にします。削除する前に、出力を保存してください。
業務が止まったときの戻し方
セッションを取り消すと、ユーザーはすべての端末で再サインインが必要になります。取り消しの操作自体は元に戻せません。復旧の方法は再サインインです。Outlook やスマートフォンのメールアプリが同期しない場合は、本人に再サインインを案内してください。
パスワードをリセットすると、古いパスワードを保存して使っていた複合機の SMTP 送信や、業務スクリプトが止まります。古いパスワードには戻さず、新しい認証情報に設定し直してください。本人が新しいパスワードを受け取れない場合は、一時アクセスパス（期限付きの一時的なサインイン手段）を発行する方法があります。
転送ルールは、すぐに削除せず Disable-InboxRule で無効化しておきます。正当な業務ルールだと判明した場合は、Enable-InboxRule で戻せます。
次にやること
不審な成功が1件でも確認できたら、同じ IP アドレスでテナント全体を絞り込み、ほかに被害ユーザーがいないかを調べます。不審な記録がなかった場合でも、旧式の認証方式による成功や、条件付きアクセスが「適用されていません」の成功が多く残っていれば、それが次に塞ぐべき穴です。週に一度、同じフィルター条件で確認する運用から始めてください。