セキュリティ研究者らは、特権アクセス権を持つ攻撃者が不正な外部MFAプロバイダーを登録し、正規のログイン試行中にユーザーのパスワードを窃取できる攻撃手法を開発しました。
Varonis Threat Labsが「TrustSink」と名付けたこの手法は、この外部認証モデルに依存するプロバイダーであればどれでも通用するとされていますが、研究者たちはMicrosoft Entraを使ってこの攻撃を実証しました。
Microsoft Entraは外部MFAプロバイダーをサポートしており、組織がサードパーティの認証サービスを利用して多要素認証要件を満たせるようになっています。
Microsoftによると、ユーザーがパスワードなどの第1要素でサインインすると、Entraはユーザーを外部MFAプロバイダーにリダイレクトし、必要な第2要素を完了させることができます。
プロバイダーが第2要素の完了を示す有効な署名付きトークンを返せば、Entraはこれをもって多要素認証の要件が満たされたと判断します。
Varonisの調査によると、すでに高権限のEntraアカウントを侵害した攻撃者は、こうした外部MFAプロバイダーの一つとして不正な外部認証方式(External Authentication Method、EAM)を登録し、これを使って正規の認証フローに、いかにも本物らしいMicrosoftのパスワード入力画面を挿入できることが分かりました。
この偽の入力画面は、悪意あるプロバイダーが有効な署名付きトークンをEntraに返す前に、ユーザーのパスワードを平文で捕捉します。そのため、ログインはエラーを表示することなく完了してしまいます。
「私たちのテストテナントでは、すべてのサインインが正常に完了する一方で、私たちのサーバーはタイムスタンプと送信元IPアドレス付きでパスワードを受信していました」とVaronisは説明しています。
「捕捉されたパスワードをリセットしても、不正なプロバイダーは削除されませんでした。それは認証フローに残り続け、ユーザーが次にサインインした際には新しいパスワードを捕捉しました」
重要な点として、TrustSinkは初期アクセス攻撃ではなく、攻撃者がすでに高権限のEntraアカウントを制御していることが前提となります。
外部MFAプロバイダーの悪用
TrustSinkは、Microsoftが設定済みの外部MFAプロバイダーに置いている信頼を悪用します。
Varonisは、Entraからは正規の外部MFAプロバイダーに見えるものの、ユーザーにはMicrosoftのパスワード入力画面のコピーを表示する悪意あるプロバイダーを作成しました。
この概念実証攻撃では、ログインは当初は通常どおりに進み、ユーザーは正規のlogin.microsoftonline.comサイト上でメールアドレスとパスワードを入力します。
MFAが発動すると、Entraはブラウザを攻撃者の外部MFAプロバイダーにリダイレクトし、第2の認証ステップへ進めます。
悪意あるプロバイダーは、正規の第2要素チャレンジを提示する代わりに、Microsoftのパスワード入力画面のコピーを表示します。
認証プロセスの一環としてMicrosoftが要求していると信じた被害者がパスワードを再度入力すると、その認証情報は攻撃者が管理するサーバーに送信されます。
その後、不正なプロバイダーはMFAプロンプトが完了したことを示す署名付きトークンを生成してEntraに返し、ユーザーは元々アクセスしようとしていたアプリケーションへ進むことができます。
被害者の視点からは、サインインは正常に完了したように見えます。
Varonisは、ユーザーがすでに追加の認証ステップを予想しているタイミングで偽のパスワード入力画面が表示されるため、この攻撃は説得力があると述べています。
研究者によれば、このページはMicrosoftの正規ログイン画面と同じフォント、レイアウト、ボタンデザインを使用しており、被害者がMicrosoftのドメイン上で実際のパスワードを入力した直後に表示されます。
Varonisは、TrustSinkがセキュリティ研究者Dirk-Jan Mollema氏によるx33fcon 2025での過去の研究、講演「“Bringing Your Own Identity in Entra ID“」を土台にしていると述べています。
Mollema氏はこの講演で、不正に登録された外部MFAプロバイダーが、実際には想定される認証チェックを実行しないまま、認証が成功したと主張する署名付きJWTを返すことでMFA要件を満たせることを示していました。
TrustSinkは同じ攻撃手法を認証情報の窃取に悪用しています。
Varonisによると、この悪意ある外部認証方式を登録するには、Authentication Methods Policyの変更に加え、アプリケーション、サービスプリンシパル、および同意許可の作成が必要です。
これらの操作にはGlobal AdministratorまたはAuthentication Policy Administratorの権限を持つアカウントが必要であり、TrustSinkは侵害後(post-compromise)の手法という位置付けになります。
しかし、いったん設置されると、不正なプロバイダーは対象ユーザーのその後の複数回のログインにわたって認証経路に残り続けることができます。
不正なMFAプロバイダーはテナントのAuthentication Methods Policyに登録されたままになるため、ユーザーがパスワードを変更しても、次回のログイン試行時に再び捕捉されてしまいます。
そのため、Varonisは管理者に対し、影響を受けた認証情報をローテーションする前に、まず不正なプロバイダーを削除するよう警告しています。
Varonisは、影響を受けたユーザーのパスワードをリセットする前に、疑わしい外部MFAプロバイダーとそれに関連するアプリケーション、キー、リダイレクトURIを削除することを推奨しています。
また、組織はAuthentication Methods Policyへの変更を監視し、Global AdministratorおよびAuthentication Policy Administratorの常設権限を制限するとともに、FIDO2やWindows Hello for Businessといったフィッシング耐性のある認証方式を使用すべきだとしています。
