MFA疲労攻撃の初動対応：プッシュ通知を承認したかもしれない時に確認すること

冒頭要約

MFA疲労攻撃は、利用者にMFAプッシュ通知が繰り返し届き、誤って承認してしまうリスクがある状況を指します。通知が届いただけで侵害確定とは言えませんが、本人が操作していないMFA通知は「パスワードが知られている可能性がある」サインとして扱います。

最初にやることは、通知を承認しない、本人が何を押したかを時刻付きで確認する、IdPやSaaSのサインインログを保全することです。もし承認した可能性がある場合は、パスワード変更だけで終わらせず、セッション失効、MFA再登録、端末・アプリ同意・メール転送の確認まで進めます。

この記事では、攻撃手順ではなく、防御側が実務で使える初動確認、判断基準、エスカレーション条件を整理します。番号一致やパスキーなど、再発防止へつなげる設定も扱います。

---

MFA疲労攻撃とは：MFAを破るのではなく、誤承認を狙う

MFAは、パスワードだけに頼らないための重要な防御です。ただし、プッシュ通知型MFAは「承認」ボタンだけでログインを完了できる場合があり、利用者が自分の操作かどうかを見誤るとリスクになります。

CISAはMFAについて、フィッシング耐性MFAが目指すべき標準であり、すぐに導入できない場合は番号一致MFAを検討するよう案内しています。Microsoft Entra IDでも、Authenticatorのプッシュ通知に番号一致が適用され、単純な承認/拒否よりも利用者の確認意図を強める設計になっています。

ここで重要なのは、「MFA通知が来たから危険」と短絡しないことです。本人が別端末でログインしている、SSPRやMFA登録の流れで通知が出ている、業務アプリの再認証が発生している場合もあります。判断すべきなのは、本人の操作、通知の時刻、サインインログ、端末、場所、MFA結果が一致しているかです。

---

読者別の影響：誰が何を確認するか

MFA疲労攻撃の初動は、利用者教育だけで終わりません。本人、情シス、SaaS管理者、開発者で確認する範囲が異なります。

読者	まず見ること	放置したときのリスク
個人・社員	自分がログイン中だったか、通知を承認したか、同じ時刻に別通知があったか	誤承認後のセッションや端末登録を見落とす
情シス・CSIRT	IdPサインインログ、MFA結果、ユーザーリスク、端末、IP、地理情報	パスワード変更だけで終わり、攻撃者セッションが残る
SaaS管理者	対象SaaS、OAuthアプリ、メール転送、管理者操作、外部共有	MFA後のSaaS権限悪用やデータ持ち出し兆候を見落とす
開発者・DevOps	GitHub、CI/CD、クラウド管理画面、APIトークン、監査ログ	コード、シークレット、クラウド権限への波及を見落とす

高権限アカウントでは、MFA承認の有無だけでなく、承認後に何ができるアカウントだったかを見ます。IdP管理者、メール管理者、GitHub Organization owner、クラウド管理者、経理・人事SaaSの管理者は、通常ユーザーより広めに調査します。

---

まず確認すること：MFA通知を受けた直後のチェックリスト

本人から「身に覚えのないMFA通知が来た」と報告があったら、次の順番で確認します。

1. 本人の操作と時刻を固定する

• 通知が届いた時刻をJSTで記録する。
• 本人がその時刻にログイン操作、パスワード変更、端末変更、SSPR、MFA再登録をしていたか確認する。
• 承認、拒否、無視、報告ボタンのどれを押したか確認する。
• 「覚えていない」場合は、押した可能性ありとして扱う。

2. IdPのサインインログを見る

• 対象ユーザーの前後30分から数時間のサインインログを確認する。
• 成功/失敗、MFA要求、MFA結果、アプリ名、端末、場所、IP、User-Agentを確認する。
• 普段使わない国・地域、未管理端末、未知のブラウザ、レガシー認証、失敗連続がないか見る。
• Microsoft Entra IDの場合、ユーザーが不審なMFA要求として報告したイベントは、サインインログやリスク検知に現れる場合があります。

3. 承認後に残るものを確認する

• すべてのセッションを失効したか。
• MFA登録方法が追加・変更されていないか。
• メール転送、受信トレイルール、代理アクセスが追加されていないか。
• OAuthアプリやSaaS連携アプリに見覚えのない同意がないか。
• GitHub、クラウド、CRM、請求SaaSなど高価値サービスで操作ログがないか。

4. 似た報告が複数ないか確認する

• 同じ部署、同じSaaS、同じ時間帯にMFA通知やパスワードリセット通知の報告がないか。
• フィッシング確認チェックリスト でメールやチャット起点の誘導がなかったか確認する。
• セキュリティログの読み方 を参考に、サインインログ、SaaS監査ログ、メールゲートウェイログを同じ時系列に並べる。

---

初動対応：やること、やらないこと、記録すること

MFA疲労攻撃の疑いでは、ユーザーを責めるより、証跡の保全とセッションの無効化を優先します。本人が申告しやすい運用ほど、初動が早くなります。

やること

• 本人に、以後のMFA通知を承認しないよう伝える。
• 対象ユーザーのサインインログ、MFAログ、監査ログを保全する。
• 承認した可能性がある場合は、パスワード変更と全セッション失効を実施する。
• MFA登録方法、バックアップメール、電話番号、認証アプリ、FIDO/パスキー登録を確認する。
• 不審なOAuth同意、メール転送、外部共有、SaaS管理者操作を確認する。
• 高権限アカウントなら、関連する管理者権限とAPIトークンも棚卸しする。

やらないこと

• 「MFAがあるから大丈夫」と判断しない。
• パスワード変更だけで完了扱いにしない。
• 本人の記憶だけで承認有無を断定しない。
• 不審な通知を再現しようとして、ログイン試行や検証操作を増やさない。
• ユーザーに「なぜ押したのか」を責める聞き方をしない。報告抑制につながります。

記録すること

対象ユーザー:
通知が届いた時刻:
本人の操作:
対象アプリ:
サインイン結果:
MFA結果:
端末・ブラウザ:
IP・地域:
セッション失効の実施時刻:
MFA登録方法の確認結果:
SaaS側の確認対象:
未確認事項:
次の担当者:

この記録は、漏えい疑い初動テンプレート や フィッシング報告テンプレート に接続できます。MFA通知だけでなく、メール、チャット、電話、パスワードリセット通知が絡む場合は、同じタイムラインにまとめます。

---

判断基準：いつ重大インシデントとして扱うか

MFA通知が1回届いただけなら、誤操作や正規の再認証で説明できる場合もあります。ただし、次の条件に当てはまる場合は、通常の問い合わせではなくインシデント初動として扱います。

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

判断を迷う場合は、影響が大きい資産から見るのが実務的です。メール、IdP、クラウド、コードリポジトリ、経理・人事SaaSは、1つの承認が広い被害につながる可能性があります。

---

再発防止：番号一致、報告機能、パスキーへ段階的に進める

初動対応が終わったら、再発防止は「教育」だけに寄せない方がよいです。CISAは、フィッシング耐性MFAが目指すべき標準であり、すぐに実装できない場合の緩和策として番号一致MFAを挙げています。

1. 番号一致を有効にする

番号一致では、ログイン画面に表示された数字を認証アプリに入力して承認します。Microsoft Learnでは、Authenticatorのプッシュ通知における番号一致が、従来の通知よりユーザーのサインイン安全性を高める機能として説明されています。

ただし、番号一致はフィッシング耐性MFAそのものではありません。ユーザーが偽サイトで表示された数字を入力してしまう可能性は残ります。高権限アカウントでは、最終的にパスキーやFIDO2へ進める計画を持ちます。

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

Microsoft Entra IDでは、ユーザーが不審なMFA要求を報告する設定が用意されています。報告イベントはリスク検知やサインインログで扱えるため、利用者教育だけでなく、検知と初動へつなげやすくなります。

組織で重要なのは、「押さないでください」だけではありません。押していない通知を見たら、どこへ、何を、どの形式で報告するかを決めることです。報告先が分からない組織では、利用者は通知を無視するか、後から曖昧に相談するしかありません。

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

パスキー導入の落とし穴 でも整理した通り、パスキーやFIDO2は復旧導線まで含めて設計する必要があります。全社一斉ではなく、まずはIdP、メール、クラウド、コード管理、経理・人事など高価値アカウントから進めると現実的です。

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

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

---

よくある誤解

「MFAを入れているからアカウント乗っ取りは防げる」

MFAは重要ですが、方式によって強度が違います。SMS、TOTP、プッシュ通知、番号一致、パスキーは同じ「MFA」でもリスクが異なります。CISAのMFAページでも、MFAには強度差があり、フィッシング耐性MFAを目指すべきだと整理されています。

「拒否したなら何もしなくてよい」

拒否したこと自体はよい対応です。ただし、通知が本人の操作ではないなら、パスワードが知られている、または不審なログイン試行が進行している可能性があります。少なくともパスワード変更、サインインログ確認、類似報告の有無は見ます。

「承認したが、すぐパスワード変更したから大丈夫」

承認後にセッションが確立していた場合、パスワード変更だけでは不十分なことがあります。全セッション失効、MFA登録方法、OAuth同意、メール転送、SaaS監査ログを確認します。これは セッションハイジャック や Pass-the-Cookie の考え方とも関係します。

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

番号一致はプッシュ通知の誤承認を減らす緩和策ですが、CISAが推奨するフィッシング耐性MFAとは別物です。高リスク領域では、FIDO/WebAuthnやパスキーなど、認証プロトコル自体が正規ドメインへ結びつく方式を検討します。

---

関連用語・関連ページ

• MFA Fatigue: プッシュ通知を繰り返して誤承認を誘う攻撃。
• 多要素認証: パスワード以外の要素を組み合わせる認証。
• パスキー: フィッシング耐性を高めやすい公開鍵ベースの認証方式。
• AiTM: 正規サービスと利用者の間に入り、認証やセッションを中継する攻撃。
• Session Hijacking: ログイン後のセッションを悪用する攻撃。
• 認証と認可の違い: 本人確認と権限判断を切り分ける基礎。
• フィッシング確認チェックリスト: MFA通知の前後にメールやチャット誘導がなかったか確認する。
• 漏えい疑い初動テンプレート: 承認後の影響確認と記録に使う。
• フィッシング報告テンプレート: 社員からの報告を標準化する。
• MFAの基礎: MFA方式の違いと限界を学ぶ。
• ゼロトラストアーキテクチャ: 認証、端末、権限、ログを継続的に確認する考え方。
• ログイン失敗ログの読み取りミニCTF: 架空ログで安全に初動判断を練習する。
• 用語クイズ: MFA、パスキー、フィッシング関連用語を復習する。

---

公式情報・参考情報

• CISA: More than a Password - MFAの強度差、フィッシング耐性MFA、番号一致MFAの位置づけを確認した。
• CISA: Implementing Number Matching in MFA Applications - プッシュ通知型MFAに対するMFA fatigueと番号一致の考え方を確認した。
• Microsoft Learn: How number matching works in MFA push notifications for Authenticator - Microsoft Authenticatorの番号一致と対応シナリオを確認した。
• Microsoft Learn: Configure Microsoft Entra multifactor authentication settings - 不審なMFA要求をユーザーが報告する機能、リスク検知、ログ上の扱いを確認した。
• NIST SP 800-63B-4: Digital Identity Guidelines - 認証器管理、フィッシング耐性認証、AALの考え方を確認した。
• CISA: Cybersecurity Performance Goals - フィッシング耐性MFAを優先的に導入する実務上の位置づけを確認した。