IT用語集

多要素認証消耗攻撃とは? 10分でわかりやすく解説

水色の背景に六角形が2つあるイラスト 水色の背景に六角形が2つあるイラスト
アイキャッチ
目次

多要素認証消耗攻撃(MFA Fatigue Attack)とは、攻撃者が漏えい済みのID・パスワードなどを使ってログインを繰り返し、利用者の端末へMFA通知を連続送信して誤承認を誘う攻撃です。プッシュ通知を悪用するため、プッシュ爆撃(Push Bombing)やプロンプト爆撃(Prompt Bombing)とも呼ばれます。MFAを導入していても、利用者が身に覚えのない通知を承認すると不正ログインが成立するため、認証方式、通知制御、教育、監視、復旧手順をセットで設計する必要があります。

多要素認証消耗攻撃とは

多要素認証消耗攻撃は、MFAの仕組みそのものを暗号学的に破る攻撃ではありません。多くの場合、攻撃者は先にID・パスワードを入手し、その認証情報でログインを試みます。その後、利用者の認証アプリやスマートフォンにMFA通知を繰り返し送り、利用者が疲れや焦りから承認する状況を作ります。

多要素認証は不正ログイン対策として有効ですが、プッシュ通知で「承認」するだけの方式では、利用者の誤操作や心理的な誘導が攻撃の成立点になります。そのため、MFAを導入するだけでなく、誤承認が起きにくい方式と運用にすることが重要です。

多要素認証(MFA)の基本

多要素認証は、利用者の本人性を確認するために、複数の認証要素を組み合わせる方式です。一般的には、知識要素、所持要素、生体要素の3種類で整理されます。

  • 知識要素:パスワード、PINなど、利用者が知っている情報
  • 所持要素:スマートフォン、認証アプリ、ワンタイムパスワードトークン、セキュリティキーなど、利用者が持っているもの
  • 生体要素:指紋、顔、虹彩など、利用者の身体的特徴

MFAを使うと、パスワードが漏えいしても、攻撃者は追加の認証要素を突破する必要があります。ただし、プッシュ通知型MFAでは、利用者自身が誤って承認してしまうと、その防御が機能しなくなります。

多要素認証消耗攻撃の定義

多要素認証消耗攻撃とは、攻撃者がログイン試行を繰り返し、利用者の端末へMFA通知や確認プロンプトを連続送信して、誤承認を誘う攻撃です。

攻撃者の狙いは、利用者に「自分のログインではない」と冷静に判断させないことです。通知が何度も届く、業務中に邪魔される、深夜に起こされる、IT部門を名乗る連絡で承認を求められるといった状況を作り、承認操作を引き出そうとします。

この攻撃は、技術的な脆弱性だけを突くものではなく、認証情報の漏えい、通知設計の弱さ、利用者教育の不足、ヘルプデスク運用の隙が重なったときに成立しやすくなります。

呼び方の違い

多要素認証消耗攻撃には、複数の呼び方があります。いずれも、プッシュ通知や確認プロンプトを繰り返し送り、利用者の誤承認を狙う点は共通しています。

MFA Fatigue AttackMFA通知の連続送信により、利用者を疲弊させて承認させる攻撃を指す。
Push Bombing認証アプリのプッシュ通知を大量に送り、誤承認を誘う攻撃を指す。
Prompt Bombingログイン確認プロンプトを繰り返し表示させ、利用者の判断ミスを狙う攻撃を指す。

攻撃の目的

攻撃者の目的は、MFAを突破して対象アカウントへログインすることです。対象アカウントがメール、クラウドサービス、管理画面、業務システムに接続している場合、認証成功後の被害は広がります。

  1. 利用者に誤承認させ、不正ログインを成立させる
  2. メール、クラウドストレージ、業務システムへアクセスする
  3. 認証情報、個人情報、機密資料を取得する
  4. 権限を広げ、他アカウントや管理者権限を狙う
  5. ヘルプデスクや管理者をだましてMFA再登録やリセットを悪用する

高権限アカウントが狙われると、被害は単一アカウントにとどまりません。クラウド管理者、システム管理者、経理、人事、開発管理者などは、特に厳格な対策が必要です。

多要素認証消耗攻撃の仕組み

多要素認証消耗攻撃は、認証情報の入手、ログイン試行、MFA通知の連続送信、利用者への心理的圧力、誤承認、不正アクセスという流れで進みます。攻撃の前提を理解すると、対策の優先順位を決めやすくなります。

攻撃が成立する前提

この攻撃は、多くの場合、攻撃者がID・パスワードを入手している状態から始まります。入手経路には、フィッシング詐欺、パスワード使い回し、情報漏えい、マルウェア、ダークウェブ上での認証情報売買などがあります。

  • 有効なID・パスワードが攻撃者の手元にある
  • 外部からログイン画面に到達できる
  • 対象アカウントがプッシュ通知型MFAを利用している
  • MFA通知の回数制限や異常検知が弱い
  • 利用者が身に覚えのない通知の扱いを理解していない

つまり、多要素認証消耗攻撃は「パスワード侵害」と「誤承認の誘導」が組み合わさって起きます。パスワード管理とMFA方式の両方を見直す必要があります。

攻撃者の行動

攻撃者は、入手した認証情報でログインを試みます。パスワードが正しければ、認証システムは登録済み端末へMFA通知を送ります。利用者が拒否しても、攻撃者は時間を空けずに再試行し、通知を繰り返します。

さらに、攻撃者が電話、チャット、メールで利用者へ連絡する場合もあります。「IT部門です」「認証不具合の確認です」「承認しないとアカウントが停止します」といった口実で、承認操作を促します。

認証システム側の弱点

多要素認証消耗攻撃は、MFA製品の脆弱性がなくても成立します。ただし、設定や設計が弱いと成功率が上がります。

承認だけの通知利用者が番号や場所を確認せず、承認ボタンだけで認証を完了できる。
回数制限の不足短時間に多数のMFA要求を発生させられる。
条件付きアクセスの不足通常と異なる国、IP、端末、時間帯からの試行を止められない。
救済フローの弱さ本人確認が弱いヘルプデスク手順を悪用され、MFA再登録やリセットに進まれる。

利用者側で起きる判断ミス

利用者側では、身に覚えのないMFA通知の意味を理解していない場合に誤承認が起きやすくなります。MFA通知は「誰かがログインを試みている」という警告でもあります。

  • 通知を業務上の通常操作だと思い込む
  • 通知が邪魔で、止めるつもりで承認する
  • 深夜や会議中に判断が粗くなる
  • IT部門を名乗る連絡を信じて承認する
  • 拒否後の通報先が分からず放置する

利用者の注意力だけに依存すると、攻撃を防ぎにくくなります。承認前の確認操作、通知回数制限、通報導線、管理者側の検知を組み合わせる必要があります。

多要素認証消耗攻撃による被害

多要素認証消耗攻撃が成功すると、攻撃者は対象アカウントへ正規ログインに近い形でアクセスします。そのため、単なるログイン失敗よりも影響が大きく、メール、クラウド、業務システム、管理画面に被害が広がる可能性があります。

メールやクラウドサービスへの不正アクセス

メールアカウントが侵害されると、過去のやり取り、添付ファイル、取引情報、個人情報が閲覧される可能性があります。さらに、攻撃者はそのメールアカウントを使い、取引先や社内関係者へなりすましメールを送ることもできます。

クラウドストレージやグループウェアにアクセスされると、共有ファイル、会議資料、顧客情報、契約書、設計資料などが閲覧・持ち出しの対象になります。

権限拡大と横展開

侵害されたアカウントに管理権限がある場合、攻撃者は他の利用者、端末、クラウドサービスへアクセスを広げる可能性があります。管理者アカウント、ヘルプデスクアカウント、開発者アカウント、経理・人事アカウントは特に注意が必要です。

横展開を防ぐには、最小権限、管理者アカウントの分離、条件付きアクセス、セッション管理、ログ監視が必要です。MFAだけでなく、ID管理全体の設計が被害範囲を左右します。

ヘルプデスク悪用によるMFA回避

攻撃者は、利用者本人や社内担当者になりすまし、ヘルプデスクへMFA再登録や端末変更を依頼する場合があります。本人確認が弱いと、攻撃者が自分の端末をMFA要素として登録し、不正アクセスを継続できる状態になります。

MFAリセットや再登録は、通常の問い合わせより高リスクな処理です。本人確認、承認経路、記録、事後通知、一定時間の監視を組み合わせて管理します。

多要素認証消耗攻撃への対策

多要素認証消耗攻撃への対策は、誤承認を防ぐMFA方式、通知連打を止める制御、利用者の拒否・通報手順、管理者側の監視、侵害時の復旧を組み合わせます。

数値照合を有効にする

数値照合(Number Matching)は、ログイン画面に表示された番号を認証アプリ側で入力させる方式です。利用者は通知の承認ボタンを押すだけでは認証を完了できず、自分が開始したログイン画面の番号を確認する必要があります。

この方式により、身に覚えのない通知を誤って承認する可能性を下げられます。Microsoft Authenticatorでは、番号照合が従来のプッシュ通知型MFAに対する重要なセキュリティ強化として位置付けられており、ユーザーは表示された番号をアプリへ入力して承認します。

ただし、数値照合はプッシュ通知型MFAの誤承認対策であり、すべてのフィッシングに対する完全な解決策ではありません。高リスク利用者や管理者には、フィッシング耐性の高い方式も検討します。

MFA要求の回数制限を設定する

短時間に何度もMFA通知を送れる状態は危険です。認証基盤側で、連続試行の制限、一定回数での一時ロック、クールダウン、リスクベースの遮断を設定します。

  • 同一アカウントへの短時間のMFA要求回数を制限する
  • 拒否が続いた場合は追加通知を止め、管理者へアラートを送る
  • 通常と異なる国・地域・IP・端末からの試行を制限する
  • 高リスク試行ではプッシュ通知ではなく別方式を要求する

大量通知を発生させない設計にすれば、利用者の心理的負担を減らし、攻撃の成立確率を下げられます。

フィッシング耐性の高い認証方式を採用する

高権限アカウントや重要システムでは、FIDO2/WebAuthn、セキュリティキー、証明書ベース認証、端末バインドなど、攻撃者が遠隔から再現しにくい方式を優先します。

フィッシング耐性の高い認証では、認証応答が正規のサービスや通信チャネルに結び付くため、攻撃者が別サイトや別セッションへ転用しにくくなります。CISAも、フィッシング耐性MFAを高価値標的や管理者へ優先する考え方を示しています。

すべての利用者に一度に適用するのが難しい場合は、管理者、経営層、経理、人事、開発者、ヘルプデスクなど、侵害時の影響が大きい利用者から段階的に導入します。

条件付きアクセスを強化する

条件付きアクセスは、ログイン時の状況に応じて制御を変える仕組みです。国・地域、IPアドレス、端末状態、アプリケーション、利用者リスク、サインインリスクなどをもとに、許可、追加認証、遮断を判断します。

多要素認証消耗攻撃では、MFA通知が届く前に不審なログイン試行を止めることが重要です。通常使わない地域、未知の端末、匿名化サービス、連続失敗などを条件に、プッシュ通知を発生させない制御を設計します。

ヘルプデスクのMFA再登録手順を見直す

攻撃者は、MFA通知の誤承認だけでなく、ヘルプデスクをだましてMFA要素を再登録させようとすることがあります。本人確認が弱い場合、攻撃者の端末を新しい認証要素として登録されるリスクがあります。

MFA再登録やリセットでは、申請経路、本人確認、上長承認、記録、事後通知、一定時間の監視を決めます。電話やチャットだけで完結させず、社内で定めた公式手順に限定します。

利用者の拒否・通報手順を固定する

身に覚えのないMFA通知を受けた利用者が、迷わず拒否し、通報できる状態にします。教育では「承認しないでください」だけでなく、何をどこへ連絡するかまで明確にします。

  • 身に覚えのないMFA通知は拒否する
  • 通知が繰り返される場合は、通報先へ連絡する
  • IT部門を名乗る承認依頼は、公式窓口へ折り返して確認する
  • 通報後はパスワード変更、セッション遮断、ログ確認を行う

利用者の判断に任せる範囲を減らし、行動を手順化することが重要です。

監視とインシデント対応

多要素認証消耗攻撃は、認証ログに兆候が出やすい攻撃です。短時間のMFA要求急増、拒否の連続、通常と異なる地域からの試行、複数アカウントへの同時試行を監視します。

監視すべきログ

監視では、認証基盤、IDaaS、クラウドサービス、EDR、SIEM、ヘルプデスク問い合わせ履歴を組み合わせます。

  • 同一アカウントに対する短時間のMFA要求急増
  • MFA拒否、タイムアウト、失敗の連続
  • 通常と異なる国・地域・IPアドレスからのログイン試行
  • 複数アカウントに対する同様のMFA要求
  • ヘルプデスクへの「通知が止まらない」「MFAが使えない」という問い合わせ
  • MFA再登録、認証要素追加、条件付きアクセス変更の履歴

検知後の対応手順を決めていないと、アラートが出ても被害を止められません。誰がアカウント停止、セッション遮断、利用者確認、ログ保全を行うかを明確にします。

誤承認が疑われる場合の初動

誤承認や不正ログインが疑われる場合は、セキュリティインシデントとして扱います。初動では、アカウント保護と証跡保全を優先します。

  1. 当該アカウントのセッションを遮断する
  2. パスワードを変更し、漏えい済み認証情報を無効化する
  3. MFA要素を確認し、不審な登録があれば削除・再登録する
  4. 認証ログ、操作ログ、メール転送設定、クラウド共有設定を確認する
  5. 同種の試行が他アカウントに広がっていないか確認する

攻撃者がログインに成功していた場合、メール転送ルール、クラウド共有リンク、アプリ連携、APIトークン、管理者権限の変更も確認します。

復旧後の再発防止

復旧後は、誤承認が起きた原因を確認します。パスワードがどこから漏えいしたのか、なぜ通知が連続送信されたのか、利用者が通報できたか、管理者側で検知できたかを見直します。

再発防止策として、数値照合、要求回数制限、条件付きアクセス、フィッシング耐性MFA、ヘルプデスク手順、教育内容、監視ルールを更新します。発生した攻撃を運用改善に反映しなければ、同じ手口を再び受ける可能性があります。

多要素認証消耗攻撃への実務ポイント

多要素認証消耗攻撃への備えは、認証方式の変更だけでは完了しません。利用者、管理者、ヘルプデスク、SOC、システム管理者が同じルールで動けるようにする必要があります。

管理者・高権限アカウントを優先する

すべての利用者に一度に高度な認証方式を展開できない場合は、高権限アカウントから優先します。管理者、ヘルプデスク、経理、人事、開発者、経営層などは、侵害時の影響が大きいためです。

高権限アカウントでは、プッシュ承認に依存せず、フィッシング耐性の高い方式、端末制御、条件付きアクセス、特権ID管理を組み合わせます。

パスワード侵害を前提に設計する

多要素認証消耗攻撃では、ID・パスワードが先に侵害されている場合が多いため、パスワードが漏れても被害が広がらない設計にします。

パスワード使い回しの禁止、漏えいパスワードの検知、パスワードレス化、条件付きアクセス、セッション管理、リスクベース認証を組み合わせます。MFAは重要ですが、パスワード管理を放置してよい理由にはなりません。

教育を手順に変える

教育では、攻撃の名称を覚えさせるだけでは不十分です。利用者が身に覚えのない通知を受けたとき、拒否、通報、パスワード変更、IT部門からの連絡確認をどう行うかを具体化します。

定期的な訓練では、身に覚えのないMFA通知を想定し、通報先、対応時間、管理者側の検知、アカウント保護まで確認します。教育と監視を分けず、実際に対応できる手順として運用します。

まとめ

多要素認証消耗攻撃は、漏えい済みのID・パスワードを使ってログイン試行を繰り返し、利用者の端末へMFA通知を連続送信して誤承認を誘う攻撃です。MFAを導入していても、承認だけで完了するプッシュ通知型MFAでは、利用者の判断ミスを突かれる可能性があります。

対策では、数値照合、MFA要求の回数制限、条件付きアクセス、フィッシング耐性MFA、ヘルプデスク手順の強化、利用者の拒否・通報手順、認証ログ監視を組み合わせます。特に、管理者や高権限利用者には、FIDO2/WebAuthnなどのフィッシング耐性が高い方式を優先します。

MFAは不正ログイン対策の基盤ですが、導入しただけでは十分ではありません。認証情報が漏えいする前提で、誤承認が起きにくい設計と、異常を検知して即時対応できる運用を整えることが、多要素認証消耗攻撃への現実的な備えです。

多要素認証消耗攻撃に関するFAQ

Q.多要素認証消耗攻撃とは何ですか?

A.攻撃者がログイン試行を繰り返し、利用者の端末へMFA通知を連続送信して、誤承認を誘う攻撃です。

Q.どのようなMFAが狙われやすいですか?

A.プッシュ通知で承認するだけの方式は、利用者の誤承認を誘いやすいため狙われやすくなります。

Q.攻撃者は最初からMFAを突破できるのですか?

A.多くの場合、先にID・パスワードを入手し、その状態でログイン要求を繰り返してMFA承認を誘います。

Q.身に覚えのないMFA通知が届いたらどうすべきですか?

A.承認せずに拒否し、社内の通報先へ連絡します。必要に応じてパスワード変更とアカウント確認を行います。

Q.数値照合はなぜ有効ですか?

A.ログイン画面に表示された番号を認証アプリに入力するため、承認ボタンの押し間違いだけで認証が完了しにくくなります。

Q.MFA要求の回数制限は効果がありますか?

A.効果があります。短時間に大量の通知を送れないようにすることで、利用者を疲弊させる手口を成立しにくくできます。

Q.ユーザー教育では何を伝えるべきですか?

A.身に覚えのない通知は拒否すること、通報先、IT部門を名乗る連絡への確認方法、復旧手順を具体的に伝えます。

Q.フィッシング耐性の高いMFAとは何ですか?

A.FIDO2/WebAuthnやセキュリティキーなど、認証応答を正規サービスに結び付け、攻撃者が別のログインへ転用しにくい方式です。

Q.被害が疑われる場合、最初に何をすべきですか?

A.対象アカウントのセッション遮断、パスワード変更、MFA要素の確認、認証ログと操作ログの調査を行います。

Q.MFAを入れていても被害が出るのはなぜですか?

A.MFA通知の誤承認、ヘルプデスク手順の悪用、漏えい済みパスワードの利用など、運用面の弱点が狙われるためです。

記事を書いた人

ソリトンシステムズ・マーケティングチーム