2要素認証(2FA)でユーザーアカウントを保護している企業は、さらにリアルタイムフィッシングプロキシへの対策を講じる必要があります。こうしたプロキシを利用すると、犯罪者は多要素認証(MFA)を回避してアカウントを乗っ取ることができます。F5 BIG-IP Access Policy Manager (APM)をご利用のお客さまは、F5 Distributed Cloud Bot Defenseを追加するだけで、こうしたプロキシを効果的に遮断できます。
“Distributed Cloud Bot Defenseを導入することで、ユーザーは自動化を利用してMFAによる保護を回避するリアルタイムフィッシングプロキシ攻撃から自身を保護できます。”
リアルタイムフィッシングプロキシとは
リアルタイムフィッシングプロキシ攻撃は、テキストメッセージ、メール、またはWebページを介してフィッシングメッセージが送られることから始まります。このフィッシングメッセージには、攻撃者が管理するドメインへユーザーを誘導するリンクが含まれています。このドメインは、すべてのリクエストを標的のアプリケーションにプロキシするよう設計されています。ユーザーから見ると、通常は正規のドメイン名によく似せて選ばれたドメイン名を除き、すべてが正規のものに見えます。
フィッシングプロキシにだまされたユーザーは、認証情報を入力します。単要素認証の場合、攻撃者はこの認証情報だけでアカウントにアクセスできます。2要素認証(2FA)の場合、リアルタイムフィッシングプロキシが認証情報を正規のアプリケーションに送信し、2FAリクエストを発生させます。残念ながら、ユーザーは正規のアプリケーションを利用していると信じたまま、要求された内容を受け入れて2FAを完了してしまう可能性が高くなります。
リバースフィッシングプロキシは、ほぼすべての形式の2FAを侵害する可能性があります。
- ショートメッセージサービス(SMS)を使用する2FA。SMSを使用する2FAでは、認証システムがワンタイムパスコード(OTP)を記載したテキストメッセージをユーザーに送信し、ユーザーはそのコードをアプリに入力します。フィッシングプロキシ攻撃では、ユーザーが悪意のあるアプリにパスコードを直接入力すると、そのアプリが正規のアプリにパスコードを中継するため、攻撃者によるアクセスが可能になります。OTPがメールで送信される2FAにも同じ仕組みが当てはまります。ユーザーがOTPをアプリに入力する方式では、リアルタイムのフィッシングプロキシ攻撃によって、そのOTPが取得される可能性があります。
- ハードウェアトークンを使用する2FA。 ハードウェアトークンは、暗号アルゴリズムに従って一定の時間間隔でキーを生成する物理デバイスであり、SMSベースの2FAにおけるOTPと同じ役割を果たします。ユーザーはデバイスを見ながら、キーをアプリケーションに入力します。リアルタイムフィッシングプロキシにだまされ、そのキーを悪意のあるアプリケーションに入力すると、攻撃者にアカウントへのアクセスを許してしまいます。ある意味、リアルタイムフィッシングプロキシにとって、トークンがSMS、メール、ハードウェアのいずれで提供されるかに違いはありません。(一方、FIDO2/U2Fハードウェアキーは、ブラウザとハードウェアキーが連携してオリジンバインディングを行うため、フィッシングの影響を受けません。)
- アプリベースの2FA。 Google AuthenticatorやDuo Mobileなどのモバイル認証アプリは、ハードウェアデバイスとほぼ同じ方法でトークンを生成します。この場合も、ユーザーはトークンをアプリに入力する必要があります。ユーザーがだまされて悪意のあるアプリにトークンを入力すると、攻撃者は正規のアプリケーションにアクセスできるようになります。
- プッシュ通知ベースの2FA。ユーザーがOTPをアプリケーションに入力する2FAメカニズムは、悪意のあるアプリケーションにOTPを入力するようユーザーを誘導することで、突破される可能性があります。では、ユーザーがアプリケーションにOTPを入力する必要のない、プッシュ通知ベースの2FAはどうでしょうか。プッシュ通知ベースのシステムでは、アプリケーションがログイン要求を受信すると、プッシュ通知システムへの要求がトリガーされ、ユーザーのモバイルデバイスに通知が届きます。ユーザーは1回クリックするだけで要求を承認できます。承認されると、プッシュ通知システムは、プッシュ認証が成功したことを示すAPI呼び出しをアプリケーションに返します。アプリケーションは認証プロセスを完了し、ユーザーにアクセスを許可します。このシナリオでは、トークンがアプリケーションに直接渡されるため、フィッシングプロキシがトークンを受信することはありません。それでも、最終的にアプリケーションが認証済みセッショントークンをプロキシ経由でアプリケーションに送信するため、犯罪者はアカウントにアクセスできます。攻撃者はこのトークンを取得し、被害者になりすましてアプリケーションにアクセスできます。
サービスとして提供されるリアルタイムフィッシングプロキシ
リアルタイムフィッシングプロキシ攻撃は今後増加すると予想されます。EvilGinx、Muraena、Modlishkaなどのサービスとしてのフィッシングプロキシ(PhaaS)が、攻撃の実行に必要なものをすべて提供することで、犯罪者にとって攻撃の実行を驚くほど容易にしているためです。
- ユーザーをだまして悪意のあるサイトに誘導するフィッシングメールのテンプレート
- 標的アプリを模倣するホスト型Webサーバー
- 盗んだ認証情報を保存するデータベース
- リアルタイム監視
- セキュリティ研究者による解析を阻止する防御メカニズム
- ドキュメントとカスタマーサービス
Distributed Cloud Bot Defenseがリアルタイムフィッシングプロキシを緩和する仕組み
フィッシングプロキシを通過するトラフィックには、特有の特徴があります。ドメイン名が正規サイトのものと一致せず、ドメイン名の変更に対応するためにHTMLやJavaScriptが改変される場合があるほか、タイミングやTLSシグネチャも変化する可能性があります。Distributed Cloud Bot Defenseは、ボットと人間を識別する際に使用するものと同じクライアント側およびネットワークのシグナルを数多く活用し、リアルタイムフィッシングプロキシに特有の異常を検出できます。これにより、MFAに対する最も一般的な脅威の1つに対処できます。
リアルタイムフィッシング対策にBIG-IP APMとDistributed Cloud Bot Defenseを組み合わせるべき理由
BIG-IP APMは、アプリとAPI向けの柔軟で高性能なアクセス管理ソリューションです。企業のアイデンティティサービスを接続し、Active Directory、LDAPプロバイダー、RADIUSなどを、SSO、アクセスフェデレーション、OAuth 2.0、SAML、OIDCなどの最新の認証プロトコルと連携させることで、アプリケーションに認証サービスを提供します。
BIG-IP APMは、ステップアップ認証をサポートし、SMSベースのOTPによる2要素認証(2FA)を標準で提供します。さらに、BIG-IP APMは、Cisco Duo、Okta、Azure ADなど、主要なMFAソリューションの多くと連携します。
多くの企業の認証プロセスでBIG-IP APMが中核的な役割を担っているため、MFAによる保護を自動化によって回避するリアルタイムフィッシングプロキシ攻撃からユーザーを保護するには、BIG-IP APMにDistributed Cloud Bot Defenseを実装することが最適です。
次のステップ
技術的な詳細については、BIG-IP APM内でのDistributed Cloud Bot Defenseの設定に関するF5 DevCentralの記事をご覧ください
関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。