Фишинг через OAuth-редиректы Entra ID: схема атак

Введение: почему это важно

OAuth-ссылки на известные провайдеры идентификации (IdP), такие как Microsoft Entra ID, часто вызывают доверие у пользователей и в некоторых случаях обрабатываются средствами безопасности более «мягко». Последнее исследование Microsoft показывает, что злоумышленники используют «заложенное в дизайн» поведение редиректа в OAuth, чтобы отправлять пользователей с легитимных доменов входа на инфраструктуру атакующих — обеспечивая фишинг и доставку вредоносного ПО, при этом это выглядит как обычный процесс входа.

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

Что нового / ключевые выводы

Команда Microsoft Defender Security Research Team наблюдала эксплуатацию механики OAuth-редиректа, инициируемую фишингом, по сигналам из email, identity и endpoint:

• Злоупотребление «тихими» OAuth-потоками: злоумышленники формируют URL авторизации OAuth с параметрами вроде prompt=none, чтобы попытаться выполнить silent проверку аутентификации (без UI).
• Намеренно некорректные scope для принудительного ухода в ошибку: запросы включают scope=<invalid_scope> (или другие триггеры отказа), чтобы предсказуемо получить OAuth-ошибку.
• Редирект по ошибке на URI под контролем атакующего: когда IdP возвращает ошибку (например, interaction_required), браузер перенаправляется на зарегистрированный redirect URI приложения, который атакующий настраивает на фишинговые страницы или сайты скачивания вредоносного ПО.
• Для редиректа не требуется кража токенов: злоумышленник не обязательно стремится успешно завершить OAuth; основная цель — именно редирект.
• Злоупотребление параметром state для персонализации: параметр state, предназначенный для корреляции запроса/ответа, переиспользовался для передачи email жертвы (в открытом виде, hex, Base64 или в собственной кодировке), чтобы фишинговые страницы могли автоматически подставлять идентификаторы.
• Шаблоны доставки кампаний: фишинговые приманки включали запросы на e-signature, темы финансов/социального обеспечения, обмен документами, контент Teams/встреч и запросы на сброс пароля. В некоторых случаях использовались PDF-вложения со встроенными ссылками и даже .ics приглашения календаря.
• Инструментарий «по цепочке»: страницы после редиректа часто использовали фишинговые фреймворки вроде EvilProxy (attacker-in-the-middle), предназначенные для перехвата учётных данных и cookies сессий, иногда с добавлением CAPTCHA/промежуточных экранов.

Влияние на IT-администраторов и конечных пользователей

• Более высокий риск перехода по ссылке: ссылки начинаются на доверенных доменах IdP (например, login.microsoftonline.com), повышая уверенность пользователя.
• Давление на обход защит: традиционные проверки репутации URL могут фокусироваться на исходном домене и упускать конечный адрес назначения.
• Нужна видимость на разных уровнях: Microsoft отмечает, что Defender коррелировал сигналы по email, identity и endpoint, подчёркивая, что одного средства контроля может быть недостаточно.
• Продолжающаяся угроза: Microsoft Entra отключила выявленные вредоносные OAuth-приложения, но связанная активность сохраняется — мониторинг по-прежнему необходим.

Рекомендации / следующие шаги

1. Проводите охоту (hunting) на подозрительные паттерны OAuth authorize в логах и телеметрии прокси, особенно:
   • prompt=none в сочетании с необычными/некорректными значениями scope
   • частые сбои OAuth, за которыми следуют редиректы на не корпоративные домены
   • использование /common/ в неожиданных контекстах фишинга с большим объёмом
2. Проверьте и ограничьте consent для приложений и регистрации приложений:
   • аудит недавно созданных приложений и redirect URI на предмет недоверенных доменов
   • ужесточите, кто может регистрировать приложения/изменять redirect URI в Entra ID
3. Усилите защиту от фишинга сверх проверок «доверенного домена»:
   • убедитесь, что инструменты детонации URL/Safe Links отслеживают редиректы
   • обучайте пользователей, что «начинается со страницы входа Microsoft» не гарантирует безопасность
4. Проверьте Conditional Access и session controls:
   • мониторьте телеметрию входов и OAuth-ошибок на предмет аномалий и целевых групп пользователей
5. Используйте корреляцию Defender:
   • задействуйте Microsoft Defender for Office 365 + Defender for Identity/Endpoint для корреляции email-приманки, поведения при входе и активности полезной нагрузки на endpoint.