Varonis Threat Labs выявила технику фишинга учетных данных, которую мы назвали TrustSink. Она превращает доверенный внешний провайдер аутентификации в перманентную ловушку для учетных данных в рамках легитимного процесса входа.

Хотя эта техника применима к любому провайдеру, мы продемонстрировали работу TrustSink от начала до конца с использованием Microsoft Entra. Злоумышленник с высоким уровнем привилегий может зарегистрировать фиктивный метод внешней аутентификации (EAM) и встроить убедительную страницу ввода пароля в легитимный процесс входа. Эта страница перехватывает пароль в виде открытого текста, в то время как провайдер возвращает действительный подписанный токен, завершая вход без ошибок.

В нашем тестовом клиенте каждый вход завершался нормально, в то время как наш сервер получал пароли с метками времени и исходными IP-адресами. Сброс перехваченного пароля не удалял фиктивный провайдер. Он оставался в процессе аутентификации и перехватывал новый пароль при следующем входе пользователя.

Мы делимся этим исследованием в качестве предупреждения для специалистов по защите, а также чтобы помочь ИТ-командам и командам безопасности обнаруживать несанкционированные изменения в инфраструктуре аутентификации и удалять фиктивные провайдеры до сброса затронутых учетных данных.

TrustSink опирается на границу доверия, которую отметил Дирк-ян Моллем (Dirk-jan Mollema) в своем выступлении на конференции x33fcon 2025 «Bringing Your Own Identity in Entra ID». Его исследование показало, как фиктивный зарегистрированный провайдер EAM может использоваться для обхода MFA путем возврата подписанного JWT без выполнения реальной проверки подлинности.

Наше исследование использует ту же границу доверия для другой цели: перехват паролей в открытом виде. Мы сосредоточились на управляемой провайдером странице, которую видит пользователь. Она может напоминать запрос пароля Microsoft и использоваться для сбора пароля до того, как провайдер завершит вход с помощью подписанного токена.

TrustSink — это хитроумный обходной путь для аутентификации. Если мы не можем доверять приложениям-аутентификаторам, то чему вообще можно доверять?

Создание фиктивного провайдера

Сначала мы создали провайдер вручную: минималистичный сервер OpenID Connect (OIDC), написанный на Python с использованием FastAPI. У него две задачи, которые направлены в противоположные стороны.

Для пользователя он должен выглядеть точно так же, как официальная страница Microsoft.
Для Entra он должен выглядеть точно так же, как совместимый провайдер EAM.

Обе эти задачи разворачиваются в рамках одного входа.

Пользователь вводит свой настоящий пароль Microsoft. Срабатывает MFA, и Entra перенаправляет его браузер к нашему провайдеру для второй проверки. С этого момента обе аудитории видят разные вещи. Пользователь видит копию страницы паролей Microsoft, и все, что он вводит, сохраняется нашим сервером. Entra видит подписанный токен, утверждающий, что проверка прошла успешно, и подпись проходит валидацию, поэтому вход завершается.

Цикл поддерживают в общей сложности четыре конечные точки (по две для каждой аудитории).

1. Документ обнаружения

Именно так Entra узнает о существовании провайдера. Его URL-адрес /.well-known/openid-configuration зарегистрирован в политике методов аутентификации и запрашивается до перенаправления любого пользователя. Наша реализация возвращает минимум метаданных, необходимых Entra: издателя, конечную точку авторизации, URI JWKS и поддерживаемый алгоритм подписи (RS256). Если документ недоступен или недействителен, Entra отклоняет провайдер, и пользователь видит страницу ошибки.

2. Публичный ключ

Именно так Entra доверяет провайдеру. Конечная точка /jwks предоставляет публичный ключ RSA из самоподписанной пары, которую мы генерируем при первом запуске. Entra извлекает этот ключ для проверки возвращаемых провайдером токенов и кэширует его, поэтому запросы следуют циклу обновления метаданных Microsoft, а не выполняются при каждом входе. Microsoft проверяет только то, что идентификатор ключа совпадает, а подпись действительна. Она не проверяет цепочку сертификатов или происхождение ключа.

3. Страница, которую видит пользователь

Здесь находится ловушка. Когда срабатывает MFA, Entra перенаправляет браузер на адрес /eam/authorize и передает все необходимое для ответа: id_token_hint для идентификации пользователя, nonce для привязки ответа к этому запросу и URI обратного вызова для отправки данных. Наш сервер отвечает точной попиксельной копией собственного запроса пароля Microsoft.

4. Перехват

Здесь оседает пароль. Когда пользователь отправляет форму, по адресу /eam/complete он записывается в локальный файл учетных данных с меткой времени и исходным IP-адресом. Затем сервер формирует ответ для Microsoft. Он берет идентификатор пользователя из id_token_hint (Microsoft намеренно отправляет этот токен с истекшим сроком действия. Тем не менее, наш провайдер проверяет его подпись, издателя, аудиторию и соответствующие утверждения перед использованием) и добавляет два утверждения, которые сообщают Entra об успешной проверке аппаратного ключа: acr: "possessionorinherence" и amr: ["hwk"]. Он подписывает токен закрытым ключом провайдера, и автоматически отправляемая форма передает его в обратный вызов Microsoft.

Что видит пользователь

Атака добавляет один лишний шаг в привычный сценарий, который пользователь выполнял сотни раз. Со стороны его экрана процесс входа выглядит следующим образом.

Он вводит свой адрес электронной почты на login.microsoftonline.com.
Он вводит свой пароль. Этот пароль уходит в Microsoft.
Срабатывает MFA.
Браузер попадает на страницу, которая выглядит как еще одна страница ввода пароля Microsoft.
Он снова вводит свой пароль. Этот пароль достается нам.
Страница автоматически переходит дальше.
Пользователь попадает в свое приложение. Вход завершен, ошибок нет.

Страница на четвертом шаге является попиксельной копией оригинала. Те же шрифты, та же разметка, та же синяя кнопка.

Она также появляется в тот самый момент, когда запрос пароля кажется логичным: пользователь только что ввел свой настоящий пароль в домене Microsoft, поэтому второй запрос в рамках того же потока не вызывает подозрений, в отличие от ссылки в полученном по почте письме.

С точки зрения пользователя, он вошел в систему как обычно.

От концепции до повторяемой ловушки

Отказ от ответственности: Данный концепт (PoC) предоставляется исключительно в образовательных и санкционированных целях исследования безопасности, чтобы помочь защитникам понять и обнаружить этот вектор атаки. Не используйте этот инструмент против какой-либо среды без явно выраженного письменного разрешения.

На данный момент все успешно отработало в нашем собственном тенанте. Злоумышленнику в реальном мире потребовалось бы, чтобы это работало при каждом входе для каждого целевого пользователя до тех пор, пока провайдер остается зарегистрированным. Для этого нужны две вещи: привилегии для его регистрации и публичный адрес.

Привилегии — это самая сложная часть. Регистрация внешнего метода означает изменение политики методов аутентификации, создание приложения, субъекта-службы и предоставление согласия. Эти действия требуют учетной записи глобального администратора или администратора политик аутентификации. Следовательно, TrustSink — это постинструментальная техника (post-compromise). Она начинается после того, как злоумышленник захватил привилегированную учетную запись и решил превратить ее в постоянную ловушку для учетных данных.

С адресом все проще. Entra извлекает документ обнаружения и ключи подписи по HTTPS, а браузер жертвы перенаправляется туда же во время редиректа, поэтому провайдеру необходим публичный URL-адрес. В нашей лаборатории это был ngrok — служба туннелирования, которая выводит локальный сервер в публичное пространство по протоколу HTTPS.

Настоящий злоумышленник выбрал бы что-то более изощренное, чем ngrok, например, облачную ВМ за прокси вроде auth-verify.microsoft-sso.com или VPS с бесплатным сертификатом. Домен появляется в адресной строке на секунду во время перенаправления, и большинство пользователей никогда на это не смотрят. Правильно выбранный домен — это грань между слиянием с фоном и обнаружением аналитиком незнакомого издателя в логах прокси.

Ручная настройка

Чтобы проверить эту настройку, мы выполнили развертывание через портал Entra вручную, так как медленный запуск наглядно показывает, какие именно артефакты создает атака.

Сначала мы запустили сервер FastAPI локально и открыли к нему доступ через ngrok, получив публичный адрес HTTPS (https://trident-sip-filter.ngrok-free.dev), который будут использовать как Entra, так и браузер жертвы.
В разделе «Регистрация приложений» мы создали приложение с безобидным названием (например, « Security Verification »), ограниченное учетными записями только в этом каталоге организации, установили его URI перенаправления Web на внешний сертификат обратного вызова Microsoft (https://login.microsoftonline.com/common/federation/externalauthprovider) и включили выдачу ID-токенов в рамках неявного предоставления (Implicit grant).
Мы создали субъект-службу (Service Principal) для приложения. Это происходит автоматически, когда приложение регистрируется в том же клиенте (тенант). Мы убедились, что оно существует в разделе «Корпоративные приложения».
Мы добавили делегированные разрешения OpenID и profile, а также предоставили согласие администратора (admin consent), чтобы во время перенаправления не появлялось окно запроса разрешений.
В политике методов аутентификации мы добавили поставщика под отображаемым именем, выбранным так, чтобы не привлекать внимания (у нас было «User's Password»), ввели идентификатор приложения (клиента), зарегистрированного на шаге 2, указали URL-адрес обнаружения (Discovery URL) https://trident-sip-filter.ngrok-free.dev/eam/.well-known/openid-configuration и ограничили его группой безопасности, содержащей одну тестовую учетную запись.
Мы подтвердили, что политика условного доступа (Conditional Access) требует MFA для этой группы во всех облачных приложениях. Ловушка была активирована.
Мы вошли в систему как целевой пользователь. После ввода настоящего пароля Entra перенаправила нас на наш сервер, где фальшивый запрос пароля перехватил второй ввод. Мы подписали JWT и отправили его обратно, после чего вход в систему завершился нормально.

Вы можете посмотреть процесс ручного развертывания здесь.

Автоматизированное развертывание

После ручного этапа стало очевидно, что методология работает, но она требовала нескольких минут кликов и оставляла слишком много места для ошибок. В результате мы упаковали ту же последовательность шагов в скрипт на Python (deploy.py), который выполняет ее через Microsoft Graph всего одной командой:

Для аутентификации скрипт сначала пробует использовать Azure CLI, что позволяет избежать создания нового события входа в систему, а в качестве резервного варианта использует поток кода устройства с идентификатором клиента Azure PowerShell, на использование которого уже получено согласие в большинстве тенантов.
Он создает приложение с помощью POST /v1.0/applications с правильным URI перенаправления и необходимыми разрешениями openid/profile, а затем создает субъект-службу с помощью POST /v1.0/servicePrincipals, делая приложение пригодным для использования в тенанте.
Он предоставляет согласие на уровне тенанта с помощью POST /v1.0/oauth2PermissionGrants, привязанное к AllPrincipals для openid и profile, чтобы жертвы никогда не видели запрос на согласие.
Он регистрирует внешний метод с помощью POST /beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations, добавляя провайдера в политику методов аутентификации с ограничением по целевой группе.
Он сохраняет все созданные данные в deploy_state.json и выполняет автоматический откат, если какой-либо шаг завершается ошибкой. Вспомогательный скрипт cleanup_eam.py последовательно отменяет полное развертывание: удаляет конфигурацию EAM, отзывает согласие администратора, удаляет субъект-службу, затем регистрацию приложения и очищает файл состояния только после полного успешного завершения очистки.

Вы можете watch the automated deployment here.

Как обнаружить TrustSink и снизить риски

Большинство этапов развертывания TrustSink оставляют след в логах. Регистрация провайдера записывает конфигурацию метода в политику методов аутентификации, а автоматический запуск оставляет собственный след, создавая приложение, субъект-службу и грант согласия последовательно с помощью скриптовых вызовов Graph.

Стоит обратить внимание на пять областей:

1. Изменения политики методов аутентификации

Регистрация вредоносного провайдера записала три события аудита подряд: добавлен внешний метод, обновлен объект пользователя и подтверждена регистрация метода. Это также добавило ключ FIDO в свойство SearchableDeviceKey тестового пользователя — побочный эффект, который мы не вызывали намеренно. Любая новая запись externalAuthenticationMethodConfiguration вне запланированного развертывания является самым явным ранним предупреждением.

2. Регистрация приложений

Созданное нами приложение использовало внешний обратный вызов аутентификации Microsoft, login.microsoftonline.com/common/federation/externalauthprovider, в качестве URI перенаправления, запрашивало разрешения openid и profile, имело незаметное отображаемое имя, а аудитория входа была ограничена организацией. Любое приложение без четкой бизнес-цели, регистрирующееся в пути аутентификации, заслуживает проверки.

3. Субъекты-службы

Регистрация приложения также создала субъект-службу, и событие ее создания содержит конкретные детали: ID приложения, аудиторию входа, URL-адреса ответов, указывающие на инфраструктуру под управлением злоумышленника (в нашем тесте — домен ngrok, а не Microsoft), и ключевой материал, зарегистрированный для подписания токенов. Субъект-служба, хранящая учетные данные для приложения, которое вам незнакомо, является частью той же цепочки и появляется в том же окне аудита.

4. Журналы входа

Каждый вход в систему, обработанный нашим провайдером, фиксировал URL его издателя, а выдачу выдают утверждения (claims). Запрос подлинного аппаратного ключа генерирует их после реальной процедуры. Наши же были жестко заданы как acr: "possessionorinherence" и amr: ["hwk"]. Запись показывает, что первый фактор удовлетворен утверждениями токена, а требование MFA удовлетворено внешним провайдером. Незнакомый издатель с флагом hwk — самый надежный сигнал, поскольку провайдер не может избежать его появления.

5. Автоматизированные инструменты

Наш инструмент развертывания помечал каждый вызов Graph как python-requests/2.33.1, а события добавления приложения, добавления субъекта-службы и добавления делегированных разрешений происходили с разницей в секунды. Настоящая административная работа выполняется через портал Azure или PowerShell в человеческом темпе. Заголовок тривиально изменить, поэтому воспринимайте его как зацепку, а не как цифровую подпись.

Смягчение последствий

Сброс пароля не работает с TrustSink. Старые учетные данные уничтожаются, но провайдер все еще активен, поэтому он перехватит новые при следующем входе. Необходимо удалить провайдера, а не только сменить учетные данные.

Область

Действие

Провайдер

Отключите внешний метод в политике методов аутентификации и удалите его групповые назначения перед любым сбросом пароля

Артефакты приложения

Удалите регистрацию приложения, субъект-службу, ключи подписи, грант согласия openid и profile, а также URI перенаправления обратного вызова

Учетные записи

Используйте журналы входа, чтобы определить каждого пользователя, прошедшего аутентификацию через провайдера, сбросьте их учетные данные и проверьте, что эти учетные записи делали после этого

Условный доступ

Настройте оповещения об изменениях в политиках, направленных на новые группы, и проверяйте любые политики, отредактированные после подозрительной регистрации

Методы аутентификации

Переведите пользователей на FIDO2 или Windows Hello for Business, чтобы запрос пароля во время MFA выглядел подозрительно

Привилегированный доступ

Ограничьте постоянные роли глобального администратора (Global Administrator) и администратора политик аутентификации (Authentication Policy Administrator) — две роли, которые могут изменить этот путь

Итог

Техника TrustSink существует потому, что Entra доверяет подписанному токену от зарегистрированного EAM, не проверяя, что именно провайдер показывает пользователю.

Microsoft доверяет стороннему сервису единственный экран, которому доверяет каждый пользователь, и никогда не проверяет, что этот сервис показывает или возвращает. Контроль над тем, что видит пользователь, в сочетании с автоматической проверкой всего, что возвращается обратно, — это все, что было нужно. Результатом стал механизм перехвата учетных данных, который работал в рамках обычных входов в систему.

У этого механизма есть цена для обеих сторон. Порог входа высок, поскольку злоумышленнику требуется привилегированная учетная запись, прежде чем все это заработает. Взамен они получают постоянную ловушку, которая перехватывает пароли в открытом виде в режиме реального времени и остается активной даже после сброса этих паролей.

Для red team это уровень закрепления, которым стоит воспользоваться. Для blue team это еще одна причина следить за изменениями в инфраструктуре идентификации так же внимательно, как и за самими входами в систему.