はじめに
「MFA(多要素認証)は有効にしているから、うちは大丈夫」そう思っていないでしょうか。実は今、MFAを有効にしているだけでは、Microsoft 365のアカウント乗っ取りを防ぎきれません。Microsoft自身も、MFA通過後のセッショントークンを盗む攻撃では、MFAを突破されなくてもMicrosoft 365のリソースにアクセスされ得ると説明しています。
Microsoft 365 / Exchange Online管理者向けに、「予防」と「乗っ取られた際の初動対応」の2本立てで整理してみました。そのまま使えるPowerShellコマンドとチェックリストは元記事にまとめています。
元記事: [【Microsoft365参考書】「MFAだけでは守れない」Microsoft 365アカウント乗っ取り対策と被害発生時の初動対応]
なぜ「MFAを入れた」だけでは不十分なのか
近年増えているのがAiTM(Adversary-in-the-Middle)型フィッシングです。攻撃者は本物そっくりの偽ログインサイトを用意し、ユーザーとMicrosoftの間に入り込んで認証のやり取りを中継します。
ユーザー → 偽サイト → 攻撃者 → Microsoftのログイン
↓
認証済みセッショントークンを窃取
ユーザーが正規にMFAを通過した結果として発行されたトークンを盗まれるため、攻撃者は「MFA済みのユーザー」としてアクセスできてしまいます。Microsoftは2026年にも、こうしたセッショントークン窃取につながるフィッシング基盤(Tycoon 2FAなど)への対応を公表しており、もはや他人事ではないテーマです。
対策は「レイヤーで重ねる」のが基本
管理者目線での優先度を整理すると、以下のようになります。
| レイヤー | 主な対策 | 優先度 |
|---|---|---|
| 認証 | MFA、パスワードレス、フィッシング耐性のある認証 | ★★★★★ |
| アクセス制御 | 条件付きアクセス | ★★★★★ |
| トークン | トークン保護、CAEなど | ★★★★☆ |
| IDリスク検知 | Entra ID Protection | ★★★★☆ |
| 端末 | Intune / 準拠デバイス / Defender | ★★★★☆ |
| メール | フィッシング・不正URL対策 | ★★★★★ |
| 権限 | 管理者権限の最小化 | ★★★★★ |
| 監視 | サインインログ、監査ログ、Defender / Sentinel | ★★★★☆ |
| 侵害後対応 | セッション無効化、資格情報変更、影響調査 | ★★★★★ |
特に大切なのは、認証・条件付きアクセス・トークンを一つのセットとして設計することです。元記事では、この9レイヤーそれぞれについて具体的な実装ポイント(トークン保護の段階的展開手順や、管理者アカウントへの追加防御など)を10項目に分けて解説しています。
乗っ取り発生時の鉄則:「調査」より先に「封じ込め」
ここが実務で一番大事なポイントです。いきなりログ調査から始めず、まず封じ込める。Microsoftの公開手順でも、侵害を確認したらできるだけ早く攻撃者のアクセスを遮断し、その後に永続化設定と影響範囲を調査する流れになっています。
乗っ取り疑いを検知
↓ ① アカウントを一時停止
↓ ② セッション・トークンを失効
↓ ③ パスワードをリセット
↓ ④ MFA・認証方法を確認
↓ ⑤ OAuthアプリ・権限を確認
↓ ⑥ メール転送・Inbox Ruleを確認
↓ ⑦ サインインログ・監査ログを調査
↓ ⑧ 不正メールの送信範囲を特定
↓ ⑨ 影響範囲・横展開を調査
↓ ⑩ 安全確認後にアカウント復旧
初動は**「サインインブロック」+「セッション失効」+「パスワードリセット」の3点セット**で考えるのがポイントです。パスワード変更だけでは、攻撃者がすでに持っている認証済みセッションには対抗できません。
見落としがちな「永続化の裏口」
パスワードを変えて終わり、にしていないでしょうか。攻撃者はログイン後、再侵入用の裏口を仕込んでいることがあります。特に見落とされやすいのが次の2点です。
- 不審なOAuthアプリケーション: ユーザーが同意したアプリの権限は、パスワード変更後も残り続ける
-
非表示のInbox Rule: 通常表示されるルールだけでは不十分で、
-IncludeHiddenオプションを付けて確認しないと見つからないルールが存在する(RedirectTo/ForwardTo/ForwardAsAttachmentToが要注意)
この2つを確認せずに「パスワードを変えたから大丈夫」と復旧させてしまうと、攻撃者に再侵入を許してしまう可能性があります。
おわりに
MFAは乗っ取り対策の出発点であって、ゴールではありません。「突破されない」前提ではなく「突破・窃取されても被害を抑える」前提で、認証・条件付きアクセス・トークン保護・監視をセットで設計しておくことが重要です。元記事には、PowerShellでの封じ込めコマンド例や、そのまま社内手順書に転用できる初動対応チートシート(チェックリスト)も掲載されていますので、インシデント対応フローを整備したい方はぜひご覧ください。
- 元記事: 社畜の所業「『MFAだけでは守れない』Microsoft 365アカウント乗っ取り対策と被害発生時の初動対応」
- ブログ全体: 社畜の所業(Microsoft365解説ブログ) — セキュリティインシデント対応の実務記事も充実しています