Microsoft Entra「TrustSink」攻撃、不正なMFAプロバイダーでパスワードを窃取

「TrustSink」は、侵害後に用いられる認証情報フィッシング手法です。Microsoft Entraの外部認証方法（EAM：External Authentication Methods）を悪用し、正規のMicrosoftサインインフローの途中に不正なパスワード入力画面を差し込みます。

この攻撃では、テナントで高い権限を持つ攻撃者が平文のパスワードを窃取できます。その一方でEntraには有効な署名付きトークンを返すため、被害者のログインはエラーなく完了します。

EAMは、組織がサードパーティのMFAサービスを統合できるようにする機能です。しかし悪意のある管理者は、攻撃者の管理下にあるプロバイダーを登録し、標的ユーザーに適用範囲を絞り込むことができます。

MFAが呼び出されると、Entraはユーザーのブラウザーを外部プロバイダーにリダイレクトします。認証チェックの実施と署名付きクレームの返却は、このプロバイダーに委ねられています。

TrustSinkの概念実証（PoC）では、被害者がMicrosoftのドメイン上で正規のパスワードを入力し終えた後、不正なプロバイダーがMicrosoftのパスワード画面をピクセル単位で忠実に再現した画面を表示します。

2回目の入力画面は、MFAの手順として想定される流れの中で表示されるため、ユーザーには信頼できるものに見えてしまいます。

攻撃者が用意したページは、パスワード、タイムスタンプ、送信元IPアドレスを記録します。続いて、必要な認証ステップが完了したことを示す署名付きJWTを生成します。

Entraはプロバイダーが公開している鍵で署名を検証し、ログインの続行を許可します。

この手法が特に危険なのは、被害者が認証の失敗も、不審なリダイレクトの警告も、目に見える中断も一切経験しない点です。

ユーザーから見れば、Microsoftのパスワードを入力し、MFA関連のステップを完了して、目的のアプリケーションにアクセスするという、いつもどおりの手順にしか見えません。

ところが攻撃者は、再利用可能な認証情報を手に入れると同時に、テナントの認証基盤に永続的な足場も確保します。

Varonisはデモ用プロバイダーを、軽量なPythonとFastAPIのOIDCサーバーとして構築しました。このサーバーは、OpenID Discoveryドキュメント、JSON Web Key Set（JWKS）エンドポイント、認可エンドポイント、認証情報の取得エンドポイントを公開しています。

Varonis Threat Labsによると、TrustSinkはEntraが外部のOpenID Connect（OIDC）ベース認証プロバイダーに対応していることに伴う、重要な信頼境界を突く攻撃です。

Microsoft Entra TrustSink

Entraは、Discoveryメタデータと公開署名鍵に基づいて外部プロバイダーを信頼します。認証中、被害者はプロバイダーが管理するパスワード収集ページにリダイレクトされます。

このリダイレクトでは、ユーザーを識別するid_token_hint、レスポンスとこのリクエストを結び付けるnonce、結果を返送するコールバックURIが渡されます。

今回の研究は、セキュリティ研究者Dirk-jan Mollema氏の先行研究を踏まえたものです。同氏は2025年のx33fcon講演で、不正なEntra外部認証プロバイダーが署名付きトークンを返してMFAチェックを回避できることを示しました。

Securityflaw reports

この研究は、攻撃者が管理するIDプロバイダーに認証成功を主張させることの広範なリスクを示しました。TrustSinkは同じ信頼モデルを、MFAのバイパスだけでなく、認証情報の窃取にも応用したものです。

TrustSinkは初期侵入の手法ではありません。攻撃者は事前に、グローバル管理者や認証ポリシー管理者といった高い権限を持つEntraロールを入手し、認証方法ポリシーを変更する必要があります。

しかし、こうした権限が手に入れば、不正なプロバイダーは、適用範囲に含まれるユーザーを狙う恒久的な認証情報の罠になり得ます。

Entraは、Discoveryドキュメントと署名鍵をHTTPS経由で取得します。リダイレクト時には被害者のブラウザーも同じ宛先に送られるため、プロバイダーには公開URLが必要です。

パスワードをリセットするだけでは、問題は解決しません。悪意のあるEAMが登録されたままであれば、次回のサインインで新しいパスワードも窃取されてしまいます。

防御側は、認証情報をローテーションする前に、不正なプロバイダーを削除する必要があります。また、テナント全体が侵害された可能性があるものとして対処すべきです。

セキュリティチームは、Entraの監査ログを監視し、externalAuthenticationMethodConfigurationの新規エントリーや、想定外の認証方法ポリシーの変更を確認してください。

Securityflaw reports

外部認証のコールバックURIを使って新規作成されたアプリケーション登録や、外部にホストされた応答URLを持つ見慣れないサービスプリンシパルにも注意が必要です。

サインインログにも、不正なプロバイダーの発行者URLや不審なMFAクレームが残る場合があります。たとえば、acr: possessionorinherenceやamr: ["hwk"]といったハードウェアキーのアサーションが、組織が承認した認証アーキテクチャーと一致しない場合です。

外部MFAプロバイダーを利用する組織は、認証ポリシーを変更できるロールを厳しく制限してください。特権IDの監視を義務付け、承認済みプロバイダーの一覧を維持し、計画外のOIDCメタデータや署名鍵の変更があれば直ちに調査する必要があります。

SOCのアラート調査を1件あたり21分短縮。IOCのコンテキストを即座に得て、迅速な対応を実現します。 SOCにTI Lookupを導入する