Компания Proofpoint зафиксировала минимум два независимых злоумышленника, которые используют новую технику обхода защиты под названием OAuth client ID spoofing для атак на среды Microsoft Entra ID. Метод позволяет перебирать учетные записи пользователей и проверять украденные пароли в промышленных масштабах, при этом система не фиксирует успешный вход, который бы насторожил защитников.
Суть проблемы объяснила исследователь Proofpoint Рэйчел Рабин: Entra ID возвращает разные коды ошибок в зависимости от того, действителен ли переданный идентификатор клиента OAuth или нет. Client ID это глобально уникальный идентификатор (GUID), который присваивается приложениям при запросе доступа к данным пользователя и передается в параметре client_id при аутентификации. Злоумышленники подставляют фиктивные идентификаторы и получают возможность перечислять аккаунты без регистрации собственного приложения в OAuth. Ответ сервера при этом раскрывает сразу две вещи: существует ли учетная запись и верен ли пароль к ней.
Технически атака выглядит так: злоумышленник отправляет HTTP POST запрос к токен-эндпоинту OAuth 2.0 у Microsoft, используя поток Resource Owner Password Credentials, он же ROPC. Клиентский ID при этом синтаксически корректен, но не соответствует ни одному реальному приложению. Интересная деталь — если подделанный ID не является правильным UUIDv4, Entra не отбрасывает запрос сразу. В итоге в логах входа сохраняется только сам ID приложения, а вот название приложения там отсутствует. В ответе приходит код ошибки AADSTS (Azure Active Directory Security Token Service), который и выдает всю нужную информацию — существует ли учетная запись, правильный ли пароль.
Здесь и возникает слепая зона для детектирования. Логи входа Entra являются основным источником телеметрии для выявления перебора пользователей, парольного спрея и попыток первичного доступа. Но поскольку поддельные client ID не оставляют имени приложения в логах, детекции, настроенные на всплеск активности против конкретного named-приложения, могут пропустить происходящее целиком — просто потому что поле остается пустым.
Технику не назвали абсолютно новой с чистого листа. У нее есть предшественник — кластер, известный как UNK_CustomCloak. Ранее эта группа проводила брутфорс-кампании против Entra ID, подделывая строки User-Agent и эксплуатируя устаревшее, уже снятое с поддержки приложение первой стороны под названием Windows Live Custom Domains. Цель была та же — обойти стандартные ограничения на вход и прощупать пароли. Масштаб кампании охватывал более 4000 тенантов. Новая техника со спуфингом client ID это, по сути, эволюция того же подхода, только более изящная.
Proofpoint выделила две крупные кампании, каждая из которых пришла к этой технике самостоятельно в конце декабря 2025 года.
Первая — UNK_pyreq2323, действовавшая с января по март 2026 года через инфраструктуру Amazon Web Services. Масштаб впечатляет: было использовано более 700 тысяч поддельных client ID против более чем 1 миллиона аккаунтов почти в 4000 тенантах. Побочный эффект атаки — блокировка примерно 28% целевых пользователей из-за превышения числа неудачных попыток входа. Метод генерации ID здесь довольно ленивый — злоумышленники брали известный ID приложения и меняли только последние цифры. Один и тот же поддельный ID при этом использовался повторно, до 12 разных пользователей на один ID. Что любопытно, перебор пользователей шел не по алфавиту.
Вторая кампания — UNK_OutFlareAZ, стартовавшая в декабре 2025 года и работавшая через инфраструктуру Cloudflare. Масштаб здесь еще выше: 3,7 миллиона рандомизированных ID приложений против более чем 2 миллионов пользователей. В отличие от первой группы, здесь генерировался уникальный client ID под каждый отдельный запрос, никакого повторного использования. И, в отличие от первой кампании, перебор шел строго по алфавиту.
При всех различиях у обеих кампаний нашлось общее — оба злоумышленника использовали корректные UUID, а не малформированные идентификаторы, и оба демонстрируют паттерны, характерные для использования заранее скомпилированных словарей имен пользователей. Это не случайность и не изолированный инцидент — техника явно начинает встраиваться в арсенал атакующих на регулярной основе.
Различия между кампаниями удобно свести в одну таблицу:
Изображение носит иллюстративный характер
Суть проблемы объяснила исследователь Proofpoint Рэйчел Рабин: Entra ID возвращает разные коды ошибок в зависимости от того, действителен ли переданный идентификатор клиента OAuth или нет. Client ID это глобально уникальный идентификатор (GUID), который присваивается приложениям при запросе доступа к данным пользователя и передается в параметре client_id при аутентификации. Злоумышленники подставляют фиктивные идентификаторы и получают возможность перечислять аккаунты без регистрации собственного приложения в OAuth. Ответ сервера при этом раскрывает сразу две вещи: существует ли учетная запись и верен ли пароль к ней.
Технически атака выглядит так: злоумышленник отправляет HTTP POST запрос к токен-эндпоинту OAuth 2.0 у Microsoft, используя поток Resource Owner Password Credentials, он же ROPC. Клиентский ID при этом синтаксически корректен, но не соответствует ни одному реальному приложению. Интересная деталь — если подделанный ID не является правильным UUIDv4, Entra не отбрасывает запрос сразу. В итоге в логах входа сохраняется только сам ID приложения, а вот название приложения там отсутствует. В ответе приходит код ошибки AADSTS (Azure Active Directory Security Token Service), который и выдает всю нужную информацию — существует ли учетная запись, правильный ли пароль.
Здесь и возникает слепая зона для детектирования. Логи входа Entra являются основным источником телеметрии для выявления перебора пользователей, парольного спрея и попыток первичного доступа. Но поскольку поддельные client ID не оставляют имени приложения в логах, детекции, настроенные на всплеск активности против конкретного named-приложения, могут пропустить происходящее целиком — просто потому что поле остается пустым.
Технику не назвали абсолютно новой с чистого листа. У нее есть предшественник — кластер, известный как UNK_CustomCloak. Ранее эта группа проводила брутфорс-кампании против Entra ID, подделывая строки User-Agent и эксплуатируя устаревшее, уже снятое с поддержки приложение первой стороны под названием Windows Live Custom Domains. Цель была та же — обойти стандартные ограничения на вход и прощупать пароли. Масштаб кампании охватывал более 4000 тенантов. Новая техника со спуфингом client ID это, по сути, эволюция того же подхода, только более изящная.
Proofpoint выделила две крупные кампании, каждая из которых пришла к этой технике самостоятельно в конце декабря 2025 года.
Первая — UNK_pyreq2323, действовавшая с января по март 2026 года через инфраструктуру Amazon Web Services. Масштаб впечатляет: было использовано более 700 тысяч поддельных client ID против более чем 1 миллиона аккаунтов почти в 4000 тенантах. Побочный эффект атаки — блокировка примерно 28% целевых пользователей из-за превышения числа неудачных попыток входа. Метод генерации ID здесь довольно ленивый — злоумышленники брали известный ID приложения и меняли только последние цифры. Один и тот же поддельный ID при этом использовался повторно, до 12 разных пользователей на один ID. Что любопытно, перебор пользователей шел не по алфавиту.
Вторая кампания — UNK_OutFlareAZ, стартовавшая в декабре 2025 года и работавшая через инфраструктуру Cloudflare. Масштаб здесь еще выше: 3,7 миллиона рандомизированных ID приложений против более чем 2 миллионов пользователей. В отличие от первой группы, здесь генерировался уникальный client ID под каждый отдельный запрос, никакого повторного использования. И, в отличие от первой кампании, перебор шел строго по алфавиту.
При всех различиях у обеих кампаний нашлось общее — оба злоумышленника использовали корректные UUID, а не малформированные идентификаторы, и оба демонстрируют паттерны, характерные для использования заранее скомпилированных словарей имен пользователей. Это не случайность и не изолированный инцидент — техника явно начинает встраиваться в арсенал атакующих на регулярной основе.
Различия между кампаниями удобно свести в одну таблицу:
- []Инфраструктура: AWS у UNK_pyreq2323, против Cloudflare у UNK_OutFlareAZ
[]Генерация client ID: модификация последних цифр известного ID против уникального ID на каждый запрос
[]Повторное использование ID: до 12 пользователей на один ID против полного отсутствия повторов
[]Порядок перебора: не алфавитный против строго алфавитного
