TrustSink: Как вредоносный внешний провайдер MFA похищает пароли

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

Хотя эта техника может работать с любым провайдером, мы продемонстрировали работу TrustSink от начала до конца с использованием Microsoft Entra. Злоумышленник с высокими привилегиями может зарегистрировать вредоносный метод внешней аутентификации (External Authentication Method, 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. Документ обнаружения (Discovery document)

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

2. Открытый ключ

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

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

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

4. Перехват

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

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

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

• Он вводит свой адрес электронной почты на login.microsoftonline.com.

• Он вводит свой пароль. Он отправляется в Microsoft.

• Срабатывает MFA.

• Браузер попадает на то, что выглядит как еще одна страница ввода пароля Microsoft.

• Он снова вводит свой пароль. Этот отправляется нам.

• Страница продолжает работу самостоятельно.

• Пользователь попадает в свое приложение. Вход завершен, ошибок нет.

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

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

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

От концепт-карты до повторяющейся ловушки

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

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

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

С адресом все проще. 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 перенаправления веб-приложения на внешний обратный вызов аутентификации Microsoft (https://login.microsoftonline.com/common/federation/externalauthprovider) и включили выдачу ID-токенов в рамках неявного предоставления (Implicit grant).

• Мы создали субъект-службу (Service Principal) для приложения. Это происходит автоматически при регистрации приложения в том же клиенте (tenant). Мы убедились, что он существует в разделе «Корпоративные приложения».

• Мы добавили делегированные разрешения OpenID и профиля и предоставили согласие администратора, чтобы во время перенаправления не появлялся запрос на согласие.

• В политике методов аутентификации мы добавили провайдера с отображаемым именем, выбранным так, чтобы не вызывать подозрений (у нас это было «User's Password»), ввели идентификатор приложения (клиента), зарегистрированного на шаге 2, указали URL обнаружения https://trident-sip-filter.ngrok-free.dev/eam/.well-known/openid-configuration и ограничили его группой безопасности, содержащей одну тестовую учетную запись.

• Мы подтвердили, что политика условного доступа требует 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, отзывает согласие администратора, удаляет субъект-службу, затем регистрацию приложения, и очищает файл состояния только после полного завершения удаления.

Вы можете посмотреть автоматизированное развертывание здесь.

Как обнаружить и нейтрализовать TrustSink

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

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

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

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

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

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

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

Регистрация приложения также создала субъект-службу, и событие его создания содержит детали: идентификатор приложения, аудиторию входа, 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) это еще одна причина следить за изменениями в инфраструктуре идентификации так же внимательно, как и за самими входами в систему.