MFA疲労攻撃とは？プッシュ通知を承認してしまった時の初動対応と再発防止

この記事の結論：通知は「承認しない・報告する」、承認したら「止めてから失効」

MFA疲労攻撃（MFA Fatigue）は、MFAのプッシュ通知を繰り返し送り、利用者が誤って「承認」を押すのを狙う手口です。通知が届いたこと自体は侵害の確定ではありませんが、自分が操作していない通知は「パスワードがすでに知られている」兆候として扱います。

判断の分かれ目は、次の3つです。

• 承認していない（拒否・無視・報告した）：パスワード変更とサインインログの確認を当日中に行います。
• 承認した、または押したか覚えていない：承認したものとして扱い、管理者が新たなサインインを止めてからセッションを失効させます。
• 高権限アカウント（IdP・メール・クラウド・GitHub・経理）：上の対応に加えて、管理者操作、APIトークン、外部共有まで調査範囲を広げます。

対象は、Microsoft Entra ID、Google Workspace、Okta、各SaaSでMFAを使う組織の利用者と、情シス・CSIRT・SaaS管理者です。具体的な設定画面はMicrosoft Entra IDを例にしますが、考え方は他のIdPでも同じです。

---

MFA疲労攻撃の仕組み：なぜ「承認」が狙われるのか

プッシュ通知型のMFAは、スマートフォンに届いた通知の「承認」を押すだけでサインインを完了できる方式があります。攻撃者がパスワードを入手していれば、サインインを何度も試すだけで利用者のスマートフォンに通知を送り続けられます。夜間や業務中に通知が続くと、利用者は「止めたい」「何かの更新だろう」と考えて承認してしまうことがあります。

ただし、「通知が来た＝攻撃」と短絡しないことも大切です。本人が別の端末でサインインしている、パスワードリセットやMFAの登録手続き中、業務アプリの再認証で通知が出ている、といった正当な場合もあります。判断の基準は、本人の操作、通知の時刻、サインインログの結果・端末・場所が一致しているかです。

---

MFA方式ごとの違い：MFA疲労とフィッシングへの強さ

同じ「MFA」でも、方式によって攻撃への強さは異なります。CISAはMFAに強度の差があることを示し、フィッシング耐性MFAを目指すべき標準としています。

Microsoft Authenticatorの番号一致：適用範囲と例外

Microsoft Learnによると、Microsoft Authenticatorのプッシュ通知では番号一致がすべての通知で有効で、利用者は無効にできません。サインイン画面に表示された数字をAuthenticatorに入力して承認します。対象は次のとおりです。

• MFA、セルフサービスパスワードリセット（SSPR）、Authenticatorの登録時の承認
• AD FSアダプター（Windows Server 2016・2019・2022は、2021年10〜11月の更新プログラム適用後）
• NPS拡張機能は番号一致に対応せず、バージョン1.2.2216.1以降では承認・拒否の代わりにTOTPの入力を求める

一方、Apple WatchやAndroidのウェアラブル端末への通知は番号一致に対応せず、スマートフォンで承認する必要があります。番号一致は誤承認を大きく減らしますが、偽サイトに表示された数字を入力させるフィッシングは防げません。

---

初動対応：通知に気づいてから当日中までの時間割

次の時間割はCyberLens編集部が整理した目安です。報告や封じ込めを、ここに書いた時間まで待つ意味ではありません。

• 直後：承認せず報告

  拒否または報告し、届いた時刻・回数・押した操作を窓口へ伝える。

• 30分以内：止めて失効

  ログを保全し、新たなサインインを止めてからセッションを失効する。

• 当日中：認証を作り直す

  パスワード変更、MFA登録方法・回復情報の確認と再登録を行う。

• 当日中：残ったものを確認

  メール転送、OAuth同意、各SaaSの操作、外部共有を確認する。

1. 本人の操作と時刻を固定する（利用者・窓口）

• 通知が届いた時刻（日本時間）と回数を記録する。
• その時刻に本人がサインイン、パスワード変更、端末の変更、SSPR、MFAの登録をしていたか確認する。
• 承認・拒否・無視・報告のどれを押したかを確認する。覚えていなければ「押した可能性あり」とする。

2. サインインログを保全して読む（管理者）

対象の利用者について、通知の前後数時間のサインインログを保全します。成功・失敗、MFAの要求と結果、アプリ名、端末、場所、IPアドレス、User-Agentを確認し、普段使わない国や地域、管理されていない端末、失敗の連続がないかを見ます。ログの読み方は セキュリティログの読み方 にまとめています。

3. 承認した可能性があれば、止めてから失効する（管理者）

Microsoft Learnの緊急時の手順では、Entra IDで次の順に操作します。

1. アカウントを無効にして、新たなサインインを止める（ユーザーの「アカウントの有効化」をオフにする）
2. セッションを失効する（ユーザーの概要ページの「セッションの取り消し」。リフレッシュトークンが失効する）
3. 必要に応じて、利用者の登録端末を無効にする

オンプレミスのActive Directoryと同期している環境では、ADでもアカウントを無効にし、パスワードをリセットします。手順に沿って操作した後も、すでに発行されたアクセストークンは期限まで使える点に注意が必要です。Entra IDのアクセストークンは既定で1時間有効です。また、アプリが独自に発行したセッション（Cookie）はEntra ID側から直接失効できず、アプリ側の設定や同期のタイミングに依存します。

失効の対象	失効の操作	注意点
Entra IDのリフレッシュトークン	「セッションの取り消し」	新しいアクセストークンの取得が止まる
発行済みのアクセストークン	期限切れを待つ（既定1時間）	継続的アクセス評価（CAE）に対応するアプリはほぼ即時に失効できる
アプリ独自のセッション（Cookie）	各アプリの管理画面で失効・利用停止	Entra ID側からは直接失効できない
「MFAを記憶する」の信頼済み端末	セッションの取り消しで信頼状態も解除される	侵害時は記憶済みの端末も再認証の対象にする

4. 認証を作り直し、残ったものを確認する（管理者）

アカウントの再有効化は、次を確認してからにします。

• パスワードの変更と、MFAの登録方法（認証アプリ、電話番号、回復用メール、パスキー）に追加・変更がないか
• メール転送、受信トレイのルール、代理アクセスの追加
• OAuthアプリの同意、外部共有、GitHubやクラウド・CRMなど高価値サービスでの操作
• 高権限アカウントなら、管理者ロールとAPIトークンの棚卸し

---

判断基準：どの条件ならインシデントとして扱うか

優先度	条件	推奨する対応
高	本人が承認した、または承認した可能性を否定できない	アカウント停止、セッション失効、パスワード変更、MFA再登録、SaaS監査ログの確認
高	管理者、経理、人事、メール、GitHub、クラウド管理者で発生	関連SaaS、APIトークン、外部共有、管理者操作まで確認
高	不審なサインインの成功、未知の端末、見覚えのない地域、OAuth同意がある	漏えいの疑いとしてCSIRT・法務・システムオーナーへ報告
中	本人は拒否したが、短時間に複数回の要求があった	パスワード漏えいの疑いとしてパスワード変更とリスク検知を確認
中	複数の利用者から同様の通知やフィッシングの報告がある	フィッシングの一斉攻撃の疑いとして、メール・IdP・SaaSのログを横断確認
低	本人の操作とログが一致し、追加の不審なイベントがない	記録を残し、次に通知が来たときの報告先を案内

複数の利用者から報告がある場合は、フィッシング確認チェックリスト でメールやチャットの誘導がなかったかもあわせて確認します。

---

再発防止：報告機能、パスキー、条件付きアクセスの順に進める

SSOへの統合やMFA方針を見直すときは、SSOとMFAの適用範囲・既存認証・権限の違いで、対象アプリと利用者、未接続の入口、復旧条件を整理できます。現在の不審な通知・誤承認への対応は、設計の見直しが終わるまで待ちません。

1. 不審なMFA要求を報告できるようにする

Microsoft Entra IDの「不審なアクティビティを報告」を有効にすると、利用者はAuthenticatorや電話（既定の報告コードは0）で不審な要求を報告できます。報告した利用者はユーザーリスクが「高」に設定され、次のように記録されます。

記録される場所	表示
リスク検出レポート	検出の種類「User Reported Suspicious Activity」、リスクレベル「高」
サインインログ（認証の詳細）	「MFA denied（MFA拒否）」
監査ログ	不審なアクティビティとして記録

Entra ID P2を持つテナントは、ユーザーリスクが高の利用者のサインインをブロックする、またはパスワード変更を求めるリスクベースの条件付きアクセスで自動的に対処できます。P1のテナントは、リスク検出のイベントをもとに手動またはMicrosoft Graphの自動化で対処します。従来の「不正アラート」機能は2025年3月1日に廃止され、この報告機能に置き換わっています。

2. 高権限アカウントからパスキー・FIDO2へ移行する

パスキーやFIDO2セキュリティキーは、正規のドメインに結び付いて認証するため、通知の承認操作もコードの入力もありません。全社一斉ではなく、IdP・メール・クラウド・コード管理・経理・人事など高権限のアカウントから進めます。導入時は、端末の紛失や機種変更に備えた復旧の手順まで決めておきます。詳しくは パスキー導入の落とし穴 と パスキーとパスワードの違い を参照してください。

3. 条件付きアクセスと端末の信頼を組み合わせる

MFAの方式だけでなく、端末の状態、場所、リスク、アプリ、管理者権限を条件にします。管理されていない端末からの高権限操作、未知の端末からのMFA登録の変更などは、追加の確認やブロックの対象にします。

---

よくある誤解

「MFAを入れているから乗っ取りは防げる」

MFAは重要ですが、方式によって強度が違います。プッシュ通知の承認だけで完了する方式は、MFA疲労攻撃の影響を受けます。

「承認したが、すぐパスワードを変えたので大丈夫」

承認後にセッションが確立していれば、パスワードの変更だけでは止まりません。アカウントの停止とセッションの失効、MFA登録方法、OAuth同意、メール転送、SaaSの監査ログを確認します。セッションハイジャック と同じ考え方です。

「番号一致を入れたので、フィッシング耐性MFAになった」

番号一致は誤った承認を減らす緩和策ですが、フィッシング耐性MFAとは別物です。高リスクの領域では、FIDO・WebAuthnやパスキーのように、認証が正規のドメインへ結び付く方式を検討します。

---

関連用語・関連ページ

• 用語：MFA Fatigue、多要素認証、パスキー、AiTM、Session Hijacking
• 比較：認証と認可の違い、パスキーとパスワードの違い、SSOとMFAの違い
• 関連する初動：ヘルプデスクを狙うMFAリセット依頼の初動対応、身に覚えのないMFA変更・解除通知の初動対応、身に覚えのないログイン通知の確認方法
• 学習と練習：MFAの基礎、ゼロトラストアーキテクチャ、M365監査ログ演習、用語クイズ

---

公式情報・参考情報

資料確認日：2026年10月25日。製品の仕様や画面の名称は変わることがあるため、操作前に最新の公式資料を確認してください。

• Microsoft Learn: How number matching works in MFA push notifications for Authenticator — 番号一致の適用範囲と例外。
• Microsoft Learn: Configure Microsoft Entra multifactor authentication settings — 不審なアクティビティの報告と、ライセンス別の対処。
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID — 緊急時のアクセス失効の順序とトークンの有効期間。
• CISA: More than a Password — MFAの強度差とフィッシング耐性MFA。
• CISA: Implementing Number Matching in MFA Applications — MFA疲労への緩和策としての番号一致。
• NIST SP 800-63B-4: Digital Identity Guidelines — 認証器の管理とフィッシング耐性認証。