Новая волна целевых фишинговых атак, известная как ConsentFix v3, активно распространяется на хакерских форумах. Злоумышленники автоматизировали захват учётных записей Microsoft, используя легитимные механизмы OAuth 2.0, что позволяет обходить многофакторную аутентификацию и оставаться незамеченными для стандартных средств защиты. В статье разбираем техническую суть угрозы, её эволюцию от первых версий до современного автоматизированного инструмента, а также даём практические рекомендации по защите корпоративных сред.
Что такое ConsentFix v3 и почему это опасно
ConsentFix v3 — это третья, наиболее совершенная на сегодняшний день итерация техники фишинга, нацеленной на пользователей Microsoft Entra ID (бывший Azure AD). В отличие от классических атак, нацеленных на кражу паролей, ConsentFix v3 заставляет жертву самостоятельно инициировать легитимный OAuth-поток, а затем перехватывает авторизационный код. Этот код обменивается на токены доступа, давая атакующему практически неограниченный доступ к облачным ресурсам предприятия.
Опасность метода заключается в его «невидимости» для многих традиционных систем защиты:
- Аутентификация происходит на подлинных страницах Microsoft, поэтому системы, отслеживающие поддельные формы ввода паролей, не срабатывают.
- Многофакторная аутентификация (MFA) не является препятствием, так как атакующий не взаимодействует с этапом проверки, а получает уже готовый авторизационный код уже после того, как пользователь успешно прошёл MFA.
- В ходе атаки используются доверенные приложения Microsoft (Azure CLI, Azure PowerShell), которые по умолчанию имеют высокий уровень доверия в Entra ID и не требуют явного согласия администратора.
Эволюция атаки: от ClickFix до ConsentFix v3
Первое поколение (ConsentFix v1)
Техника была впервые задокументирована специалистами Push Security в декабре 2025 года. Исследователи назвали её «ConsentFix», объединив два подхода: социальную инженерию в стиле ClickFix и фишинг согласия OAuth. В ходе атаки жертва перенаправлялась на подлинную страницу входа Microsoft, а после аутентификации — на локальный адрес (http://localhost), где в URL-адресе содержался авторизационный код. Злоумышленник с помощью социальной инженерии убеждал жертву скопировать и вставить этот URL в форму на вредоносной странице, тем самым передавая ему код.
Второе поколение (ConsentFix v2)
Исследователь Джон Хаммонд усовершенствовал метод, заменив ручное копирование на перетаскивание (drag-and-drop) локального URL. Это сделало процесс фишинга более плавным и естественным для жертвы.
Третье поколение (ConsentFix v3): автоматизация и масштабирование
ConsentFix v3 сохранила ключевую идею эксплуатации потока кода авторизации OAuth 2.0 и фокусировку на доверенных приложениях Microsoft, но привнесла два критически важных улучшения:
- Автоматизация всех этапов — от разведки и фишинга до перехвата кода и получения токенов.
- Масштабируемость — атака может быть развёрнута на множество организаций одновременно с минимальным ручным вмешательством.
Детальный разбор техники атаки
Этап 1: Разведка и подготовка
Атака начинается с проверки наличия Azure в целевой среде путём проверки валидных идентификаторов тенантов. Затем собираются данные о сотрудниках: имена, должности, адреса электронной почты — всё, что необходимо для последующей персонализации фишинговых писем.
Далее злоумышленники создают учётные записи на различных сервисах, каждый из которых выполняет свою роль в цепочке атаки:
- Outlook и Tutanota — для рассылки фишинговых писем.
- Cloudflare Pages — для хостинга фишинговых страниц.
- DocSend — для размещения PDF-документов с вредоносными ссылками (повышает доверие и помогает обходить спам-фильтры).
- Hunter.io — для сбора и верификации корпоративных email-адресов.
- Pipedream — бесплатная serverless-платформа, играющая центральную роль в автоматизации.
Этап 2: Развёртывание фишинговой страницы
На Cloudflare Pages разворачивается страница, имитирующая легитимный интерфейс Microsoft или Azure. Эта страница не запрашивает пароль — вместо этого она инициирует реальный OAuth-поток через конечную точку авторизации Microsoft. Жертва видит подлинную страницу входа и, если у неё уже есть активная сессия, ей достаточно просто выбрать свою учётную запись из списка. В случае отсутствия сессии пользователь вводит логин и пароль, а затем проходит MFA на настоящих страницах Microsoft.
Ключевой момент уязвимости: для нативных (публичных) клиентских приложений, таких как Azure CLI, авторизационный код сам по себе достаточен для получения токенов доступа — не требуется секрет приложения, который обычно защищает веб-приложения. Именно это и эксплуатирует ConsentFix.
Этап 3: Перехват авторизационного кода
После успешной аутентификации браузер пользователя перенаправляется на адрес вида:
http://localhost:<random-port>/?code=<AUTHORIZATION_CODE>&...Поскольку на локальной машине жертвы не запущено приложение, способное принять этот запрос, браузер отображает ошибку подключения. На этом этапе фишинговая страница инструктирует пользователя скопировать URL из адресной строки и вставить его обратно в форму «для восстановления сеанса». Этот, казалось бы, безобидный шаг передаёт авторизационный код в руки злоумышленника.
Этап 4: Автоматический обмен кода на токены
Центральным элементом автоматизации в ConsentFix v3 выступает платформа Pipedream. Она выполняет три ключевые функции:
- Webhook-эндпоинт — принимает скопированный жертвой URL с авторизационным кодом.
- Модуль автоматизации — немедленно обменивает полученный код на токен обновления (refresh token) через Microsoft API.
- Панель сбора — агрегирует все захваченные токены в реальном времени и предоставляет к ним доступ атакующему.
Временное окно для обмена кода составляет около 10 минут, поэтому автоматизация критически важна для успеха атаки.
Этап 5: Пост-эксплуатация
| Уровень защиты | Причина неэффективности против ConsentFix v3 |
| Многофакторная аутентификация | Атакующий получает уже готовый авторизационный код, полученный уже после того, как жертва успешно прошла MFA на реальных страницах Microsoft. |
| Парольная защита | Пароль не перехватывается; атака происходит на уровне токенов, а не учётных данных. |
| Антифишинговые системы | Фишинговая страница не имитирует форму входа, а лишь перенаправляет на реальный сайт Microsoft и инструктирует пользователя. |
| Защита конечных точек (EDR) | Вредоносная активность сосредоточена на уровне API (Microsoft Graph) и не оставляет следов на рабочей станции жертвы. |
| Обучение пользователей | Пользователи обучены не вводить пароли на подозрительных сайтах, но здесь все страницы — подлинные, а инструкция «скопировать и вставить URL» кажется безобидной. |
Стоит отметить, что Azure CLI является доверенным приложением Microsoft первой стороны, которое не подлежит блокировке или отключению администраторами тенантов, и освобождено от стандартных ограничений согласия, применяемых к сторонним приложениям. Это архитектурное ограничение делает защиту от ConsentFix особенно сложной задачей.
Практические меры защиты
1. Управление согласием пользователей
Наиболее эффективная мера — ограничить возможность самостоятельного предоставления согласия пользователями. В портале Entra ID необходимо перейти в раздел Enterprise applications > Consent and permissions и установить значение «Do not allow user consent». В этом случае все запросы на предоставление разрешений будут требовать одобрения администратором.
2. Предварительное создание Service Principal для уязвимых приложений
Для приложений, которые не могут быть заблокированы стандартными политиками согласия, рекомендуется предварительно создать объекты Service Principal и требовать назначения пользователей перед использованием. Ниже приведён пример скрипта PowerShell для Microsoft Graph:
# Подключение к Microsoft Graph с правами администратора
Connect-MgGraph -Scopes "Application.ReadWrite.All", "AppRoleAssignment.ReadWrite.All"
# Список уязвимых приложений Microsoft (App ID)
$apps = @(
"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # Azure CLI
"1950a258-227b-4e31-a9cf-717495945fc2" # Azure PowerShell
)
foreach ($appId in $apps) {
# Создание Service Principal
$sp = New-MgServicePrincipal -AppId $appId
# Включение требования назначения пользователей
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AppRoleAssignmentRequired:$true
Write-Host "Service Principal $appId настроен с обязательным назначением."
}Этот подход предотвращает автоматическое предоставление согласия пользователями при попытке инициирования OAuth-потока атакующим.
3. Мониторинг и корреляция событий входа
Атака оставляет характерный цифровой след. При анализе логов AADNonInteractiveUserSignInLogs следует обращать внимание на аномалии. Например, одна и та же сессия (Session ID) может демонстрировать активность из двух географически удалённых точек: сначала из локации жертвы, а затем — из локации атакующего.
Признаки атаки:
- Использование устаревших разрешений (legacy Graph scopes), которые злоумышленники намеренно применяют для уклонения от обнаружения.
- Необычная активность Azure CLI с новых IP-адресов.
- Подозрительные OAuth-согласия, предоставленные доверенным приложениям Microsoft.
Готовые правила детектирования уже доступны для SIEM-систем. Например, для Elastic Security существует правило Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource.
4. Настройка Continuous Access Evaluation (CAE)
Технология Continuous Access Evaluation позволяет Entra ID в реальном времени аннулировать токены доступа при изменении критических условий (например, отключение учётной записи пользователя или смена пароля). Хотя это не предотвращает первоначальную компрометацию, данная мера существенно ограничивает возможности злоумышленника по закреплению в среде.
5. Использование решений класса Identity Threat Detection and Response (ITDR)
Специализированные решения, такие как SecureAuth, внедряют модель непрерывной авторизации, проверяя контекст каждого запроса на доступ в реальном времени. Даже если атакующий получит токен, он не сможет пройти политики, привязанные к устройству, местоположению и уровню риска.
Заключение
ConsentFix v3 — это тщательно продуманная методология, нацеленная на эксплуатацию архитектурных особенностей OAuth 2.0 в экосистеме Microsoft. Она демонстрирует, что современные угрозы всё чаще смещаются с уровня учётных данных на уровень токенов, и традиционных мер защиты уже недостаточно. Организациям необходимо срочно пересмотреть политики управления согласием, внедрить принудительное одобрение администратором для всех OAuth-приложений и настроить мониторинг аномальной активности, связанной с доверенными приложениями Microsoft. Без этих упреждающих мер любое предприятие, использующее Azure, остаётся уязвимым для атаки, которая маскируется под легитимный рабочий процесс.
