Компания Huntress, занимающаяся кибербезопасностью, зафиксировала масштабную автоматизированную атаку на Microsoft Azure CLI, которая продолжалась с 12 по 26 июня 2026 года. За две недели злоумышленники совершили более 81 миллиона попыток входа и скомпрометировали как минимум 78 учётных записей в 64 организациях.
С 12 по 21 июня темп взломов держался на уровне 2–4 аккаунтов в сутки. 19 июня был зафиксирован суточный пик: за один день атакующие захватили 12 учётных записей. Переломным стало 22 июня — в этот день скомпрометированы 30 аккаунтов сразу в 23 компаниях. Всплеск активности начался ещё в конце мая 2026 года, и к моменту пика среднее число неудачных попыток входа на одного клиента Huntress составляло около 1964 в месяц — это в 155 раз выше обычного фонового уровня.
Атака шла с IPv6-диапазона 2a0a:d683::/32, принадлежащего компании LSHIY LLC (автономная система AS32167). Часть IP-адресов геолоцируется в США, часть — в Китае. Атака распространялась через несколько автономных систем одновременно. По данным Huntress, выбор жертв не был связан ни с отраслью, ни с размером бизнеса: «Таргетинг в этих атаках, судя по всему, полностью основан на распространённости паролей в скомпрометированных комбо-листах и не привязан к конкретному типу бизнеса или отрасли».
Технической основой атаки послужил протокол ROPC (Resource Owner Password Credentials) — устаревший тип авторизации в рамках OAuth 2.0, исключённый из стандарта OAuth 2.1. Схема работает просто: пользователь передаёт логин и пароль напрямую клиентскому приложению, то отправляет их на сервер авторизации и получает токен доступа. Сам Microsoft официально не рекомендует использовать ROPC и прямо указывает в документации: «В большинстве сценариев доступны более безопасные альтернативы... Используйте этот поток только тогда, когда более защищённые варианты невозможны». Ключевая проблема ROPC в том, что запросы через этот протокол не проходят через стандартный эндпоинт авторизации, а значит — политики условного доступа (CAP) к ним могут попросту не применяться.
Именно это обстоятельство объясняет, почему атака затронула организации, у которых CAP были включены. Исследователи Huntress выявили несколько типовых конфигурационных ошибок. Первая: MFA настроена только для отдельных приложений, но не для «Всех облачных приложений» — Azure CLI при этом оказывается вне зоны защиты. Вторая: MFA применяется лишь к отдельным группам пользователей, например только к администраторам, а рядовые сотрудники остаются незащищёнными. Третья: MFA отключена для «доверенных» сетевых местоположений, и запросы из таких сетей проходят без дополнительной проверки. Наконец, восемь из 64 пострадавших компаний не имели вообще никакой настройки MFA.
Huntress подчёркивает важный нюанс: «То, что злоумышленникам в этой кампании удалось проникнуть внутрь даже при настроенном MFA, не означает, что многофакторная аутентификация вообще не работает. Организации должны убедиться, что их политики MFA настроены правильно». Иными словами, проблема не в самой технологии, а в дырах конфигурации.
Атака эксплуатировала ещё одну хроническую слабость корпоративной безопасности — пароли из старых утечек, которые никто не сменил. Злоумышленники работали именно с такими комбо-листами: скомпрометированные учётные данные, которые годами остаются действующими, превращаются в готовый инструмент для подобных кампаний.
Huntress сформулировала конкретный набор защитных мер. Политики условного доступа необходимо настраивать так, чтобы MFA требовалась для всех пользователей, всех облачных приложений и всех типов клиентских приложений без исключений. Доступ к Azure CLI для непривилегированных пользователей стоит ограничить. Все ранее скомпрометированные пароли подлежат принудительной смене — именно на них и рассчитана атака. Конфигурации CAP нужно явно учитывать потоки авторизации через ROPC и Azure CLI, иначе они останутся слепым пятном в защите.
Этот инцидент наглядно показывает, что устаревшие протоколы, которые формально никто не запрещал использовать, при определённых условиях становятся рабочим вектором атаки даже против организаций с настроенными политиками безопасности. Брешь возникает не там, где её ищут.
Изображение носит иллюстративный характер
С 12 по 21 июня темп взломов держался на уровне 2–4 аккаунтов в сутки. 19 июня был зафиксирован суточный пик: за один день атакующие захватили 12 учётных записей. Переломным стало 22 июня — в этот день скомпрометированы 30 аккаунтов сразу в 23 компаниях. Всплеск активности начался ещё в конце мая 2026 года, и к моменту пика среднее число неудачных попыток входа на одного клиента Huntress составляло около 1964 в месяц — это в 155 раз выше обычного фонового уровня.
Атака шла с IPv6-диапазона 2a0a:d683::/32, принадлежащего компании LSHIY LLC (автономная система AS32167). Часть IP-адресов геолоцируется в США, часть — в Китае. Атака распространялась через несколько автономных систем одновременно. По данным Huntress, выбор жертв не был связан ни с отраслью, ни с размером бизнеса: «Таргетинг в этих атаках, судя по всему, полностью основан на распространённости паролей в скомпрометированных комбо-листах и не привязан к конкретному типу бизнеса или отрасли».
Технической основой атаки послужил протокол ROPC (Resource Owner Password Credentials) — устаревший тип авторизации в рамках OAuth 2.0, исключённый из стандарта OAuth 2.1. Схема работает просто: пользователь передаёт логин и пароль напрямую клиентскому приложению, то отправляет их на сервер авторизации и получает токен доступа. Сам Microsoft официально не рекомендует использовать ROPC и прямо указывает в документации: «В большинстве сценариев доступны более безопасные альтернативы... Используйте этот поток только тогда, когда более защищённые варианты невозможны». Ключевая проблема ROPC в том, что запросы через этот протокол не проходят через стандартный эндпоинт авторизации, а значит — политики условного доступа (CAP) к ним могут попросту не применяться.
Именно это обстоятельство объясняет, почему атака затронула организации, у которых CAP были включены. Исследователи Huntress выявили несколько типовых конфигурационных ошибок. Первая: MFA настроена только для отдельных приложений, но не для «Всех облачных приложений» — Azure CLI при этом оказывается вне зоны защиты. Вторая: MFA применяется лишь к отдельным группам пользователей, например только к администраторам, а рядовые сотрудники остаются незащищёнными. Третья: MFA отключена для «доверенных» сетевых местоположений, и запросы из таких сетей проходят без дополнительной проверки. Наконец, восемь из 64 пострадавших компаний не имели вообще никакой настройки MFA.
Huntress подчёркивает важный нюанс: «То, что злоумышленникам в этой кампании удалось проникнуть внутрь даже при настроенном MFA, не означает, что многофакторная аутентификация вообще не работает. Организации должны убедиться, что их политики MFA настроены правильно». Иными словами, проблема не в самой технологии, а в дырах конфигурации.
Атака эксплуатировала ещё одну хроническую слабость корпоративной безопасности — пароли из старых утечек, которые никто не сменил. Злоумышленники работали именно с такими комбо-листами: скомпрометированные учётные данные, которые годами остаются действующими, превращаются в готовый инструмент для подобных кампаний.
Huntress сформулировала конкретный набор защитных мер. Политики условного доступа необходимо настраивать так, чтобы MFA требовалась для всех пользователей, всех облачных приложений и всех типов клиентских приложений без исключений. Доступ к Azure CLI для непривилегированных пользователей стоит ограничить. Все ранее скомпрометированные пароли подлежат принудительной смене — именно на них и рассчитана атака. Конфигурации CAP нужно явно учитывать потоки авторизации через ROPC и Azure CLI, иначе они останутся слепым пятном в защите.
Этот инцидент наглядно показывает, что устаревшие протоколы, которые формально никто не запрещал использовать, при определённых условиях становятся рабочим вектором атаки даже против организаций с настроенными политиками безопасности. Брешь возникает не там, где её ищут.
