導入：なぜMFAボンビングをテストするのか
MFAボンビング（MFA疲労攻撃、push‑bombing）は、攻撃者が正しいパスワードを入手した後、標的のデバイスに大量のプッシュ承認要求を送り続け、ユーザーを疲弊させて「承認」を誤って押させる手口です。近年、実際の侵害でこの手法が悪用されており、国家的な脅威アクターやランサムグループが利用してアカウントを乗っ取る事例が報告されています。組織は赤チーム演習でこの挙動を再現し、検出・封じ込め・運用上の緩和策が実務で有効かを確認する必要があります。
本ガイドは「実行前の法的・運用的同意」「再現手順」「検出ポイントとログ」「緩和策の検証方法」「報告テンプレート」を含み、現場で即使えるチェックリスト形式でまとめています。なお、実施は必ず明確なスコープと書面による承認の下で行ってください。
重要な参考点（近年の示唆）: MFAボンビングを含むブルートフォースやプッシュスパムを用いた侵害活動は実際に観測されており、関係当局はフィッシング耐性の高い認証や番号照合の導入を推奨しています。
計画と事前準備（必須）
- 承認とスコープ：文書化された承認（実行日、ターゲットアカウント群、許可される手法、停止条件）を必ず用意する。
- 安全なテスト環境：可能な限り本番環境ではなく、ステージング環境か限定的な委任アカウントで実施。やむを得ず本番で行う場合はインシデント対応チームを事前アラートする。
- データ収集要件：認証ログ、IDプロバイダ（IdP）ログ、SIEM／CASBのイベント、EDRイベント、ユーザー通報履歴を保存できるようにする。
- 中断条件：多数のユーザーが承認を誤る、アカウントロックアウト発生、サービス停止などを中断トリガーに設定。
ツールと環境
赤チームは通常のペネトレーションツールに加え、IdPのAPIや認証フローを利用するスクリプトを用います。手口の再現にあたっては、攻撃的な自動化ツールを実際に運用する前にターゲット側の認可を必ず確認してください。
再現シナリオの一覧（代表）
| シナリオ | 要旨 | 検証目的 |
|---|---|---|
| プッシュ承認の連続送信（標準） | IdPのプッシュ承認を大量に送る | ユーザーが誤承認する閾値、SIEMでの検出可否 |
| 番号照合（Number Matching）未実装環境 | 番号照合が無い場合、承認の誤操作が増えるかを確認 | 番号照合導入時の効果推定 |
| SMS／音声系の悪用 | SMS／音声経由のOTPや確認コードを多量発生 | SMS系の脆弱性と回避策の有効性評価 |
| パスキー／FIDO未導入ケース | 物理キーがない状態での耐性評価 | ハードウェアキー導入による改善評価 |
実務的な指針として、CISAやセキュリティ調査で推奨される「フィッシング耐性のある認証（FIDO等）導入」や「番号照合の暫定的実装」はMFA疲労対策として有効です。
注：FIDO2・パスキー等はプッシュ承認型MFAとは攻撃面が異なり、物理的・プロトコル的に疲労攻撃に強いとされています（導入事例やガイダンスも増加中）。
実行手順（安全に再現するためのステップ）
- 対象と範囲の確認：テスト対象のIdP（例：Azure AD、Okta、Ping）、影響を受けるユーザー群を確定し、運用チームへ通知。
- ログ準備：SIEM／IdPの認証ログをリアルタイムで収集し、テスト用に専用のタグを付与する。
- 模擬ログインと初回試験：まずは1名のテストユーザーで低頻度（1回/分程度）から開始し、ユーザーの挙動を観察する。
- 段階的増強：承認が発生しない場合のみ頻度を上げ、最大でも数十〜百回/短時間を超えない範囲で実施（事前合意の上）。
- 中断と復旧：中断条件に該当した場合は即中止し、影響が出たユーザーにはフォローアップ（リセット手順、パスワード変更など）を実施。
検出すべきログ/シグナル
- 同一アカウントに対する短時間の連続認証要求（プッシュ多数） — IdPイベント。
- ユーザー端末からの「承認」アクションの多発（短時間で複数の承認） — アプリ側ログ。
- 異常なIP/地理的なログイン試行とそれに伴うMFAトリガーの増加 — SIEM相関ルール。
- サポート窓口やユーザー報告の急増（アカウント防御を無効化する申請など）。
これらを相関させるルールをSIEMやCASBに実装し、アラートで運用チームに回すことが重要です。実際の脅威インテリジェンスでは、攻撃者がパスワードを入手→プッシュを連続送信→ユーザーの誤承認で侵害、というチェーンが観測されています。
緩和策とその検証方法
- 番号照合（Number Matching）の導入：プッシュに表示される番号をログイン画面側で確認させる方式。暫定的に有効な対処です（実装後、赤チームで番号整合性チェックが有効かテスト）。
- フィッシング耐性の高い認証（FIDO/パスキー・セキュリティキー）の導入：プッシュ承認が不要になり、物理的インタラクションが必要になるため疲労攻撃に本質的に強い。導入効果は段階的ロールアウトで検証する。
- プッシュ回数のレート制限および自動ブロック：一定時間内の承認要求回数で自動ブロックや凍結をかける（テストで誤検知率を評価）。
- 認証ポリシー強化：疑わしいリスクスコア時は追加チャレンジ（端末の信頼性、位置情報、IP評点）を要求する。
- ユーザー教育と運用手順：プッシュ通知を受けた際は常にログイン画面の確認を促す運用（だが教育だけでは限界がある）。
検証チェックリスト（赤チーム→ブルーチーム共有用）
| 検証項目 | 期待される結果 | 証拠（証跡） |
|---|---|---|
| 番号照合を有効化 | プッシュ承認が番号整合しない限り承認されない | IdPログ、ユーザー端末スクリーンショット |
| FIDOキーでのログイン | 物理キーがないとログイン不可、プッシュ不要 | ログイン成功/失敗イベント、EDRのデバイス利用ログ |
| レート制限ルールの動作 | 規定回数超過で自動ブロックが作動 | SIEMアラート、IdPブロックイベント |
現場での実務的優先度：短期的に実装しやすい順に番号照合→レート制限／自動ブロック→フィッシング耐性（FIDO）への移行を推奨します。CISAもフィッシング耐性MFAの導入と番号照合を推奨しています。
報告と改善サイクル
赤チーム演習後は次の点を含む報告書を作成してください：
- 実施日時・対象・承認文書
- 行ったアクションと再現シナリオ
- 観測ログ（時系列）と相関分析結果
- ヒットした検出ルール、誤検知や副次被害の有無
- 短期／中期／長期の推奨改善案（優先度つき）
結論
MFAボンビングは実運用で既に悪用されている現実的な脅威です。赤チームにより安全かつ段階的に再現することで、検出ルールの妥当性、運用手順、緩和策（番号照合、レート制限、FIDO導入など）の実効性を検証できます。短期対応としては番号照合やレート制限を導入し、中長期的にはフィッシング耐性認証（FIDO2/パスキー/ハードウェアキー）への移行を計画してください。最近のガイダンスと実例は、これらの方針を裏付けています。