Взлом учетной записи Microsoft через Azure AD
Компрометация учетной записи Microsoft нередко описывается словами «взлом через Azure AD», хотя под этой формулировкой могут скрываться разные события: ошибка в коде службы, неверная настройка арендатора, похищенный пароль или уже выданный токен. Azure AD, переименованный в Microsoft Entra ID, управляет корпоративными удостоверениями, приложениями и политиками доступа.
Поэтому технический разбор должен разделять продуктовую уязвимость, нарушение конфигурации и компрометацию самого пользователя. Ниже рассматривается реалистичная цепочка от первичного доступа до расширения полномочий, а также способы обнаружить её по журналам и остановить без потери доказательств.
Что скрывается за формулировкой об уязвимости
Настоящая уязвимость в Azure AD обычно означает дефект, позволяющий обойти установленную границу доверия: получить токен, изменить разрешения, выполнить привилегированное действие или закрепиться в арендаторе. Для анализа важны затрагиваемый компонент, требуемые условия и последствия, а не сам факт нового входа.
Область атаки охватывает OAuth 2.0, OpenID Connect, федерацию с внешним поставщиком удостоверений, регистрацию приложений и создание сервисных принципалов. Ошибка в любом из этих путей может затронуть несколько пользователей, если администратор заранее разрешил опасные сочетания прав.
Важно отличать корпоративный Entra ID от личного аккаунта Microsoft. В первом случае атака часто связана с арендатором, приложениями, ролями и корпоративными данными; во втором на первый план выходят восстановление доступа, проверка личных данных и защита устройства.
Реалистичная цепочка компрометации
Первичный вход может выглядеть как фишинг, подделка экрана согласия OAuth, заражение браузера инфостилером, распределённый подбор паролей или перехват уже активной сессии. Эти варианты не требуют неисправности Azure AD: злоумышленник получает учётные данные, код подтверждения либо токен и продолжает работу с разрешениями жертвы.
Далее проверяются границы OAuth-приложения. Пользовательское разрешение ограничивает действия контекстом пользователя, а разрешение приложения с согласия администратора может действовать от имени сервисного принципала. Если регистрация, доверие и согласие настроены небрежно, полученный токен превращается в путь к почте, файлам, календарю или другим API через Microsoft Graph.
Закрепление часто выглядит иначе, чем первоначальный вход: добавляется учётная запись приложения, меняется роль, создаётся правило пересылки почты, редактируется конфигурация федерации или обновляется секрет сервисного принципала. Поэтому цепочка нередко складывается из нескольких слабых мест, а не из одного «волшебного» эксплойта.
Роль протоколов OAuth и OpenID Connect
Фишинг согласия особенно опасен, поскольку пользователь видит подлинную страницу авторизации Microsoft и не подозревает, что разрешает стороннему приложению доступ к своей учётной записи. Схема device code усиливает эффект: ввод кода на официальной странице завершает авторизацию на стороне инициировавшего устройства, если проверки источника и адресата недостаточны.
OpenID Connect определяет, как приложение получает утверждение о пользователе, а OAuth — как выдаются токены доступа. Эти токены обычно являются bearer-объектами: их можно использовать из украденного хранилища браузера, пока действует срок или не выполнена отзывная процедура. Политики условного доступа помогают, если оценивают риск в реальном времени.
Устаревшая проверка пароля, слабая федерация и недоверенный поставщик расширяют поверхность атаки. Отдельный риск создают долгоживущие обновляющие токены, широкие разрешения Graph и сервисные принципалы с общими секретами. Даже без ошибки в продукте такая конфигурация позволяет злоупотреблять уже выданными полномочиями.
Признаки атаки в журналах
В журналах следует искать не один признак, а последовательность событий. Полезный источник — входы и аудит Microsoft Entra, единый журнал аудита Microsoft 365, а также оповещения о рискованных действиях.
- Незнакомые IP-адреса, новое устройство или резкая смена географии.
- Новые согласия OAuth, приложения и сервисные принципалы с необычными параметрами.
- Изменение ролей, секретов, методов проверки и правил обработки почты.
- Повторное применение токена, устаревшие клиенты и нетипичный объём запросов Graph.
Сопоставление входов с событиями аудита помогает восстановить хронологию: где появился новый токен, какое приложение его использовало и какие изменения были сделаны после первого доступа. Полезным признаком служит сочетание факторов, а не отдельно взятый фактор.
Продуктовая уязвимость или ошибка настройки
Если событие воспроизводится в разных арендаторах, затрагивает конкретный обработчик и приводит к нарушению заявленной границы доверия, говорят о продуктовой уязвимости. Обычно у неё есть техническое описание, условия эксплуатации, номер CVE или подтверждение исправления поставщиком.
Ошибка настройки проявляется иначе: разрешено свободное согласие пользователей, включены устаревшие протоколы, ослаблены условный доступ или федерация, а приложению выданы лишние роли. В журнале виден корректный процесс с опасными настройками, а не сбой реализации.
Компрометация учётной записи подтверждается захватом пароля, сессии или токена при отсутствии сбоя платформы. Здесь ключевы признаки вредоносного ПО, фишинга и повторного использования токена. До публичного заявления о дефекте Azure AD следует опираться на временные метки, идентификаторы клиента, корпоративный журнал и ответ вендора.
Защитные меры для арендатора
Защита строится вокруг сокращения числа допустимых цепочек, а не вокруг одного средства блокировки. Согласия, роли, секреты, многофакторная аутентификация и журналирование должны быть согласованы между собой; иначе безопасный шаг в одном слое компенсируется опасным решением в другом.
- Ограничение пользовательского согласия и регулярный пересмотр выданных разрешений.
- Отключение устаревшей проверки пароля и контроль параметров федерации.
- Переход на сертификаты и рабочие удостоверения вместо долгоживущих секретов.
- Применение ключей FIDO2 и passkeys, регулярный отзыв токенов и мониторинг Graph.
Наиболее опасный сценарий сочетает фишинг согласия, приложение с административными правами и сохранённый обновляющий токен. Даже если вход выглядит законным, отзыв сессий, запрет приложения и блокировка связанных токенов разрывают цепочку быстрее, чем простая смена пароля.
Полезная политика условного доступа оценивает устройство, сеть, риск пользователя и тип клиента. Она не должна становиться единственным рубежом: пароль, токен и согласие образуют разные пути, каждый из которых требует собственного контроля и возможности быстро отозвать выданные полномочия.
Реагирование на компрометацию
При подтверждённой компрометации сначала локализуют доступ и сохраняют данные: временно блокируют пользователя, отзывают сессии и обновляющие токены, отключают связанное приложение или сервисный принципал. Изменения проводят после сохранения журналов, иначе можно потерять последовательность действий и следы злоупотребления.
Затем удаляют посторонние согласия и назначения ролей, проверяют правила пересылки и автоответов, восстанавливают доверенные параметры федерации и ротируют секреты. Пользователю задают новый пароль, заново привязывают методы проверки и изучают недавние изменения безопасности.
Проверка завершается охотой на следы по всему арендатору, анализом доступа к данным и наблюдением за повторными атаками. Критерий восстановления требует доказанного отсутствия сохранившихся токенов, приложений и полномочий, с помощью которых прежний доступ мог возобновиться; возвращённый контроль над учётной записью сам по себе такого подтверждения не даёт.