コンテンツへスキップ

この投稿は2022年に掲載されたものです。. 

一方、 最近のMFA即席爆撃成功の報告, RSAは、プッシュボミング攻撃やMFAファティーグ攻撃とも呼ばれるこの攻撃について、リスクを軽減するための実践的なガイダンスを求める多くの要望を受けています。私たちは以前、攻撃者が承認プロンプトを繰り返し表示することで、ユーザーに圧力をかけ、不正なサインインを受け入れさせる方法について概説しました。この投稿では、その基礎の上に立って、具体的な次のような点に焦点を当てます。 RSA ID Plus 不審なパターンを検出し、リスクが高まった場合にプッシュ承認を制限し、MFAプロンプト爆撃に対する防御を強化するために使用できる構成。.

MFAのプロンプト爆撃とは?

MFAプロンプトボミングは、プッシュボミングとも呼ばれる。 MFA疲労攻撃, これは、攻撃者がユーザーのデバイスに対してMFA承認要求を繰り返し発動することである。その目的は、ユーザーが1つの要求を承認するまでユーザーを圧倒することであり、多くの場合、攻撃者はすでにユーザーのパスワードを取得した後である。.

これは、プッシュ・ベースだからである。 多要素認証 は、ユーザが不審なプロンプトをその場で拒否することに依存する。ワンタイムパスコードの入力やフィッシングに強い認証機能の使用など、ユーザーの意図的な入力を必要とする要素は、攻撃者が単純にスパム承認を行うことができないため、一般的に影響を受けにくい。.

MFAのプロンプト爆撃はどのように機能するのか?

MFA プロンプトボミング、プッシュボミング、MFA 疲労攻撃は、通常、攻撃者が有効なユーザ名とパス ワードを取得した後に始まります。攻撃者はログインを試み、ユーザの登録デバイスにプッシュベースの MFA リクエストを繰り返しトリガーします。各リクエストは、ユーザにサインイン試行の承認または拒否を求めます。.

プッシュ認証は利便性を重視して設計されているため、ユーザーはワンタップでアクセスを承認できる。十分な数のプロンプトが連続して送信されると、注意散漫なユーザーや疲労したユーザーが最終的に1つのリクエストを承認し、攻撃者が認証プロセスを完了できるようになる可能性がある。.

プッシュ・ベースの認証は、物理的な認証装置を必要とせず、ハードウェア・トークン や手動で入力するワンタイム・パスコードに比べて摩擦が少ないため、正当なシナリオで はうまく機能する。しかし、この承認または拒否モデルは、ユーザが不審な試みを認識し、拒否することに依存するため、プロンプト・ボミング攻撃の機会を生み出す。.

MFAプロンプト爆撃攻撃の種類

ほとんどのMFA爆弾攻撃はプッシュ通知を標的にしているが、セキュリティ・チームが理解すべきバリエーションもある:

  • プッシュ・ボミング(古典的MFA疲労): ユーザーがリクエストを承認するまで、繰り返しプッシュ通知が送信される。.
  • ハイブリッドソーシャルエンジニアリング攻撃: プッシュボミングを開始すると、攻撃者はITサポートになりすましてユーザーに連絡し、リクエストを承認するよう指示する。.
  • OTP フラッディングの試み: 場合によっては、攻撃者はSMSやその他の配信チャネルを通じてワンタイムパスコードを繰り返し発動し、ユーザーを混乱させたり、フィッシングと組み合わせた攻撃を試みたりする。.

このようなバリエーションを理解することは、組織がユーザーの警戒心だけに頼るのではなく、重層的な防御を設計するのに役立つ。.

なぜ即席爆撃が有効なのか

プロンプト・ボミング攻撃が成功するのは、技術と同様に人間の行動を標的にするからである。ユーザが繰り返し認証プロンプト、電話、またはメッセージを受け取るとき、攻撃者は混乱、緊急性、および日常的な承認行動を作り出すことを目的としている。そのため、MFA疲れに対する防御は、ユーザーに明確な期待、シンプルな報告経路、疑わしいリクエストを確認する信頼できる方法を与えることから始まります。.

意識を維持するための継続的なトレーニングが必要

ユーザは、自分が開始したのではない認証リクエストは、疑わしいものとして扱われる べきであることを知るべきである。年 1 回のセキュリティ意識向上トレーニングは、コンプライアンスをサポートすることはでき るが、そのようなトレーニングで次のような準備ができることはほとんどない。 ソーシャル・エンジニアリングは、急速に進行している。短いガイダンスを繰り返し行うことは、実際の状況において疑わしい行動がどのように見えるかを強化するため、より効果的である。.

ユーザーには明確な対応方法が必要 

ユーザーが予期しないプッシュ通知やフォローアップメッセージを受け取った場合、次に何をすべきかを正確に知る必要があります。つまり、問題を報告し、サービスデスクやセキュリティチームに連絡するための、シンプルでよく知られた方法を提供することです。このプロセスが簡単であればあるほど、ユーザーは迅速に行動する可能性が高くなります。.

検証によりソーシャル・エンジニアリングのリスクを低減

攻撃者は多くの場合、プッシュボミングを電話、テキスト、電子メール、またはチャットメッセージと組み合わせて、ユーザーにリクエストを承認するよう圧力をかけます。組織は、サポートチームがユーザーに合法的に連絡する方法を定義し、行動を起こす前にコミュニケーションを確認する信頼できる方法を従業員に提供する必要があります。.

質問すべきこと

セキュリティチームは、MFAプロンプト爆弾攻撃から防御するために、以下の質問を考慮する必要がある:

  • 予期せぬプッシュ・リクエストにどう対応すべきか、ユーザーは知っているだろうか?
  • 不審な認証イベントをユーザーが迅速に報告できるか?
  • 従業員はサービスデスクやセキュリティチームへの連絡方法を知っていますか?
  • ユーザーは、正当な支援活動がどのように行われるべきかを理解しているだろうか?
  • メッセージ、電話、プロンプトが本物かどうかを確認するための明確なプロセスがあるか。
MFAプロンプト爆撃攻撃を検知する方法

プロンプト爆撃シナリオでは、攻撃者は短時間にプッシュ承認を繰り返し生成する。ユーザーは初期のプロンプトを拒否したり無視したりすることが多いが、誤って1回承認してしまうとサインインが完了してしまう。そのため、パターン・ベースの検知が不可欠となる。.

などの指標を探す:

  • 度重なるプッシュ拒否またはタイムアウト 短いウィンドウの中で同じユーザーに対して
  • 複数のMFAプロンプトが連続して表示される, 特に通常のログイン動作以外
  • 見知らぬデバイス、IPアドレス、または場所からのログイン試行 同じ口座に紐づく
  • 複数のユーザーにおけるプッシュ活動の急増, より広範なキャンペーンを示す可能性がある

プッシュが1回拒否されただけでは攻撃とは言えない。複数の拒否やタイムアウトがまとまって発生した場合、特に他のリスクシグナルと組み合わされた場合は、調査の引き金となるべきである。.

RSA ID Plusにおけるプロンプト爆撃の検出

RSA ID Plus の各認証イベントは、詳細なイベントデータとともにログに記録される。セキュリティ・チームは、以下のようなイベントが繰り返し発生したり、異常発生したりしないか監視する必要がある:

  • 702 - 認証の承認に失敗しました:ユーザー応答がタイムアウトしました
  • 703 - 認証の承認に失敗しました:ユーザーが承認を拒否しました
  • 802 - デバイスの生体認証に失敗しました:タイムアウト
  • 803 - デバイスの生体認証に失敗しました

これらのイベントが同じユーザについて連続して表示される場合、アクティブな MFA 爆破の試みを示している可能性がある。これらのログパターンをデバイス、場所、および信頼性のシグナルと組み合わせることで、精度が向上し、承認が成功する前にチームが対応できるようになります。.

MFAによるプロンプト爆撃攻撃を防御する方法

効果的な防御には、不明なプロンプトを承認しないようユーザーに指示するだけでは不十分である。組織は、悪用の機会を減らすために、ユーザー教育、より強力な要因オプション、および監視を組み合わせるべきである。.

プッシュ型 MFA は、ユーザがその瞬間に適切な判断を下すかどうかに依存するため、脆弱である。ワンタイムパスコードやフィッシングに耐性のある認証機能など、ユーザーの意図的な行動を必要とする要素は、一般的に繰り返し承認要求の影響を受けにくい。.

主な防御策は以下の通り:

  • 予期せぬプロンプトを拒否し、即座に報告し、適切な場合は認証情報をリセットするようにユーザーを教育する。.
  • よりリスクの高いアプリケーション、ユーザー、アクセスシナリオに対しては、より強力な要因を優先する。.
  • プロンプトが何度も拒否されたり、タイムアウトしたりするのを監視し、疑わしいパターンがあれば警告する。.
  • 攻撃者がアクセス後に新しいデバイスを登録できないように、MFAの登録と回復を安全に行う。.
  • 認証者が追加、削除、変更されたときにユーザーに通知する。.
  • 漏洩した認証情報の兆候を調査し、MFA ポリシーが限定的な検証で過剰なアクセスを許可していないか見直す。.

これらのコントロールが連動することで、組織は即席爆弾攻撃への露出を抑えることができる。. 

RSA ID PlusがMFAプロンプト爆撃を防御する方法

RSA ID Plus, 認証方法は保証レベルにマッピングされ、管理者はコンテキストに基づいてどの保証レベルが必要かを決定するポリシーを作成できる。リスクが高い場合、ポリシーはプッシュ承認を許可する代わりに、より強力な認証方法を要求することができる。.

RSA ID Plusは、以下のようなダイナミックなアプローチもサポートしている。 アイデンティティ 自信. .確信度エンジンは、認証試行をリアルタイムで評価し、確信度の高低を返す。この信号は、信頼度が高い場合にはプッシュ承認を許可し、信頼度が低い場合にはステップアップ認証を要求する、といったポリシー決定に使用することができる。.

高リスクと判定されたユーザーについては、高リスク・ユーザー・リストにより、より厳格な管理が可能になる。セキュリティ・ツールは、アラートまたは不審なアクティビティに基づいてユーザを高リスクとしてマークすることができ、ポリシーはアクセスを拒否したり、より高い保証要素を要求したりして、MFA疲労戦術にさらされる機会を減らすことができる。.

MFAプロンプト爆撃に関するFAQ
即席爆弾テロの被害に遭った場合、どうすればいいのか?

自分が開始したのではない MFA リクエストを承認した場合は、アカウント侵害の可能性があるものとして扱います。直ちにセキュリティ・チームに報告し、パスワードを変更し、不審なセッションやデバイスがないか最近のサインイン・アクティビティを確認する。セキュリティ・チームは、アクティブなセッションを失効させ、新しい認証者が登録されていないことを確認し、アクセスを回復する前にステップアップ認証を要求する必要があります。.

リクエストしていないMFAプロンプトを受け取った場合はどうすればいいのか?

承認しないでください。可能であれば要求を拒否し、セキュリティチームに報告してください。繰り返しプロンプトが表示される場合は、誰かがアカウントにサインインしようとしているかどうかを確認してください。予防措置として、パスワードをリセットし、デバイスとアカウントのセキュリティを検証するための組織のガイダンスに従ってください。.

MFAのプロンプト爆撃とは?

MFA プロンプト爆撃(プッシュ爆撃または MFA 疲労攻撃とも呼ばれる)とは、攻撃者がユー ザのデバイスに対して MFA の承認要求を繰り返し実行することである。その目的は、ユーザーが1つの要求を承認するまでユーザーを圧倒することであり、多くの場合、攻撃者がユーザーのパスワードを取得した後に行われる。.

セキュリティ・チームは、どのようにしてMFAプロンプト・ボミング攻撃を検知できるのか?

検知は通常、パターン・ベースで行われる。セキュリティ・チームは、同じユーザが短期間に何度もプッシュ拒否やタイムアウトを繰り返したり、通常のログイン動作とは異なるMFAプロンプトが何度も表示されたり、見慣れないデバイスや場所からサインインが試みられたりすることを確認する必要があります。これらのシグナルは、他のリスク・インジケータと相関関係があるとより強力になります。.

MFAのプロンプト爆撃攻撃を止めるには?

組織は、プッシュ認証が許可されるタイミングを制限し、リスクが高まった場合にステップアップ認証を要求し、拒否またはタイムアウトが繰り返されるリクエストを監視することで、リスクを低減することができる。MFA の登録とリカバリのプロセスを保護することは、攻撃者がアクセス権を得た後に新しいデバイスを登録するのを防ぐのにも役立ちます。.

プッシュ型MFAはまだ安全か?

プッシュ MFA は効果的であるが、ユーザが要求を承認するかどうかに依存するため、疲労に基 づく戦術の影響を受けやすい。組織は、プッシュ認証をリスク・ベースのコントロールと組み合わせたり、よりリスクの高いアクセスに対してより強力な認証オプションを用意したり、異常なプロンプト・パターンにアラートを出したりすることで、リスクを低減することができる。.

ワンタイムパスコードはプッシュ通知より安全か?

ワンタイムパスコードは、攻撃者が承認要求をスパムできないため、一般的にプロンプト爆弾の影響を受けにくい。しかし、配信方法によっては、OTP 方式もフィッシングや傍受の標的になる可能性がある。多くの組織では、リスクが高まった場合のステップアップ・オプションとして、OTP およびフィッシング耐性のある認証機能を使用している。.

攻撃者は、プロンプト爆撃に成功した後、新しい MFA デバイスを登録できるか?

はい。アクセス権を獲得した後、攻撃者は、永続性を維持するために新しい認証子を登録しようとする可能性がある。防御策としては、登録ワークフローの保護、デバイスの変更に高い保証を要求すること、認証子が追加または削除されたときにユーザに通知することなどがある。.

デモをリクエスト

デモのお問い合わせ