Платформа EvilTokens, работающая по модели «фишинг как услуга» (PhaaS), по данным Cloud Security Alliance, эксплуатирует механизм OAuth device code flow в Microsoft 365 для получения долгоживущих токенов обновления (refresh tokens). Жертвы проходят легитимную аутентификацию с MFA на настоящем домене Microsoft, но при этом неосознанно передают атакующему токен с доступом к почте, файлам, календарю и контактам. Многофакторная аутентификация не способна заблокировать эту атаку, поскольку к моменту выдачи токена она уже пройдена. Организациям, использующим Microsoft 365, необходимо пересмотреть политики управления OAuth-согласиями и токенами.

Механизм атаки: device code flow как вектор

Атака использует штатный механизм аутентификации Microsoft — device code flow, предназначенный для устройств без полноценного браузера. Жертва получает сообщение с просьбой ввести короткий код на странице microsoft.com/devicelogin и пройти стандартную проверку MFA. С точки зрения пользователя, это выглядит как обычная верификация входа.

Однако после завершения аутентификации система выдаёт токен обновления не пользователю, а оператору платформы EvilTokens. Как сообщается в исследовательской записке CSA, этот токен:

• Подписан легитимным провайдером идентификации Microsoft
• Охватывает доступ к почтовому ящику, OneDrive, календарю и контактам
• Имеет срок жизни, определяемый политикой тенанта, а не сессии
• Предположительно, сохраняет валидность даже после сброса пароля пользователя

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

Почему MFA не является защитой

Традиционный фишинг учётных данных требует повторного воспроизведения пароля, и именно на этом этапе MFA создаёт барьер. Даже атаки типа «противник посередине» (AiTM) оставляют в журналах сессионные cookie, которые SIEM-системы могут коррелировать с географией и устройством.

В случае consent-фишинга через OAuth пользователь сам завершает аутентификацию на легитимном провайдере. MFA срабатывает и успешно проходит — до момента выдачи токена. Токен, который получает атакующий, не является результатом компрометации — это результат согласия, данного пользователем. По данным исследователей, для аннулирования такого доступа недостаточно сменить пароль: требуется явный отзыв токена или политика условного доступа, требующая повторного согласия.

Нормализация согласия как фактор риска

Вектор атаки через OAuth consent существует давно, но его эффективность резко возросла из-за изменения пользовательского поведения. Каждый AI-агент, каждая интеграция для повышения продуктивности, каждое расширение браузера, работающее с SaaS-аккаунтами, запрашивает OAuth-согласие. Объём легитимных запросов на согласие, с которыми сталкивается сотрудник за месяц, значительно превышает тот, что закладывался в оригинальные модели угроз OAuth.

Формулировки запрашиваемых разрешений усугубляют проблему. Область доступа «Чтение вашей почты» на практике охватывает все сообщения, вложения и общие ветки переписки. Область «Доступ к файлам, когда вы не в сети» означает выдачу долгоживущего токена, действующего без присутствия пользователя. Разрыв между языком согласия и реальным охватом доступа — именно то пространство, в котором работают атакующие.

Токсичные комбинации разрешений

Отдельный OAuth-грант даёт атакующему ограниченный плацдарм в одном приложении. Системный риск возникает, когда несколько грантов пересекаются через одну пользовательскую идентичность. Например: сотрудник финансового отдела предоставляет AI-ассистенту доступ к календарю и почте, другому инструменту — к корпоративному хранилищу, третьему — к клиентской базе CRM. Каждое согласие выдано отдельно, ни один владелец приложения не санкционировал совокупность. Компрометация одного из этих инструментов потенциально открывает доступ к контрактам и клиентским данным через ту же идентичность.

Этот риск не виден ни в одном отдельном журнале аудита приложения, поскольку мост между ними существует на уровне идентичности, вне периметра каждого приложения. Аналитики отмечают, что серверы Model Context Protocol (MCP) формируют аналогичную поверхность атаки, позволяя AI-агентам получать доступ через тот же механизм однократного согласия.

Практические рекомендации

Для защиты от consent-фишинга через OAuth необходимо перенести контроль с уровня аутентификации на уровень согласия:

1. Ограничить регистрацию приложений в Entra ID: запретить пользователям самостоятельно давать согласие на доступ приложений. Настроить рабочий процесс административного одобрения для всех OAuth-грантов, запрашивающих доступ к почте, файлам и календарю.
2. Настроить политики условного доступа для токенов: сократить срок жизни refresh-токенов, включить требование повторной аутентификации для чувствительных ресурсов, настроить политики оценки непрерывного доступа (Continuous Access Evaluation).
3. Провести аудит существующих OAuth-грантов: в Entra ID проверить раздел «Корпоративные приложения» → «Согласия и разрешения». Выявить приложения с широкими областями доступа (Mail.Read, Files.ReadWrite.All, offline_access) и отозвать неиспользуемые или подозрительные гранты.
4. Отключить device code flow: если этот механизм аутентификации не требуется для бизнес-процессов, заблокировать его через политики условного доступа. Это устраняет конкретный вектор, используемый EvilTokens.
5. Мониторить события согласия: настроить оповещения в SIEM на события выдачи OAuth-грантов, особенно для приложений, зарегистрированных вне тенанта, и для грантов с широкими областями доступа.
6. Инвентаризировать пересечения грантов: выявить пользователей, чьи OAuth-согласия в совокупности создают мосты между критическими системами (почта + хранилище + CRM), и оценить совокупный риск.

Consent-фишинг через OAuth — это не теоретическая угроза, а работающий вектор атаки, для которого существует коммерческая инфраструктура. Самое важное действие сейчас — запретить пользователям самостоятельно выдавать OAuth-согласия в Microsoft 365 и провести ревизию всех существующих грантов с широкими областями доступа. Организации, которые продолжают полагаться исключительно на MFA как на границу защиты идентичности, оставляют открытым именно тот слой, через который проходят современные атаки.