В течение двух недель, с 12 по 26 июня 2026 года, эксперты компании Huntress фиксировали масштабную кампанию автоматизированного перебора паролей (password spray), направленную на интерфейс командной строки Microsoft Azure (Azure CLI). Атаки исходили из диапазона IPv6-адресов, принадлежащего провайдеру интернет-инфраструктуры LSHIY LLC (AS32167). За этот период злоумышленники совершили более 81 миллиона попыток входа, из которых успешными оказались как минимум 78. Примечательно, что большинство пострадавших организаций использовали механизмы условного доступа (Conditional Access), однако их настройка не учитывала особенности применяемой атакующими техники.
Описание
Хронология инцидента демонстрирует резкий рост числа взломов в последнюю неделю. Если с 12 по 21 июня ежедневно фиксировалось от двух до четырёх скомпрометированных аккаунтов (за исключением 12 учётных записей 19 июня), то 22 июня количество взломов достигло 30 в 23 различных компаниях. Всего за 14 дней пострадали 64 организации. Основной источник атак - автономная система AS32167, зарегистрированная на LSHIY LLC 14 июня 2021 года. Эта же компания управляет AS955 (зарегистрирована 22 июня 2022 года). По данным сторонних сервисов геолокации, диапазон IPv6 2a0a[:]d683::/32, с которого производились атаки, имеет китайское происхождение, хотя часть IP-адресов в сторонних базах определялась как американские (Небраска). Это несоответствие связано с разными методами геолокации.
Предоставленный отчёт Huntress раскрывает детали тактики злоумышленников. Они использовали старые комбинации логин-пароль, которые ранее были скомпрометированы, но не изменены владельцами. Проверка украденных учётных данных выполнялась через протокол ROPC (Resource Owner Password Credentials) - устаревший тип авторизации OAuth 2.0, который в версии OAuth 2.1 уже не поддерживается. ROPC позволяет отправить имя пользователя и пароль напрямую на конечную точку /token в арендаторе Microsoft 365, получая взамен делегированный токен доступа. Ключевая особенность этого потока - отсутствие поддержки современных методов аутентификации, таких как многофакторная аутентификация (MFA) и единый вход (SSO). Именно это стало причиной того, что многие компании, внедрившие MFA через политики условного доступа (CAP), оказались уязвимы.
При анализе всплеска компрометаций 22 июня, затронувшего 23 предприятия, выяснилось, что 15 из них имели настроенную MFA, но она не сработала в ходе атаки. Разрывы в конфигурации оказались разными. В одних случаях MFA была применена только к конкретным приложениям, например к порталам администрирования Microsoft, но не охватывала Azure CLI, используемый злоумышленниками. В других - MFA требовалась лишь для определённых групп пользователей (администраторов), а скомпрометированные учётные записи в эти группы не входили. Некоторые организации полагались на доверенные локации, но IP-адрес атакующих, ошибочно определяемый как американский, проходил эту проверку. В двух случаях MFA была включена в режиме "только отчёт" и фактически не блокировала вход. Восемь пострадавших компаний вообще не имели политики MFA.
Таким образом, атака не свидетельствует о неэффективности MFA как таковой, а указывает на критическую важность правильной настройки условного доступа. Политики CAP оценивают множество факторов - пользователя, местоположение, устройство, тип приложения - и на их основе принимают решение о запросе второго фактора. Однако устаревшие протоколы вроде ROPC не проходят через точку авторизации, где эти политики применяются. Это позволяет обойти блокировки, если MFA настроена только на определённые сценарии.
Для защиты от подобных атак Huntress рекомендует следующее. При создании политик условного доступа необходимо требовать MFA (или блокировать вход) для всех пользователей, всех облачных приложений и всех типов клиентских приложений безусловно. Параметр userStrongAuthClientAuthNRequired принудительно включает строгую аутентификацию на уровне клиента и блокирует потоки ROPC. Также следует ограничить доступ к приложению Azure CLI для неадминистративных пользователей. Важно не полагаться на объём попыток подбора как на индикатор атаки, поскольку наибольшее количество атак часто приходится на наименее скомпрометированные арендаторы; приоритетным сигналом должна быть валидность учётных данных.
Интересен и провайдер LSHIY LLC. Компания зарегистрирована по нескольким адресам, включая два заводских здания в Гонконге и Ухане (Китай), а также офис в Нью-Йорке по адресу 42 Broadway, 12th floor. Последний, как выяснили в Huntress, является коворкингом без конкретной привязки к бизнесу, что затрудняет установление истинных владельцев. Обращения к LSHIY через механизм жалоб на злоупотребления не получили ответа на момент публикации. Это подчёркивает растущую проблему использования арендованной инфраструктуры для атак, которую сложно отследить и заблокировать в реальном времени.
В целом за последние полгода Huntress зафиксировала рост объёма атак с перебором паролей более чем в 155 раз среди своих клиентов. Среднее количество неудачных попыток в месяц на одного защищённого арендатора составляет около 1964, а медианное - 804. Целями становятся любые компании, чьи учётные записи появляются в публичных базах скомпрометированных паролей, без отраслевой привязки. Данная кампания - лишь часть общей волны, и её масштаб демонстрирует, что традиционные меры защиты, включая MFA, требуют тщательной настройки и регулярного аудита конфигураций условного доступа.
Индикаторы компрометации
CIDR
- 2a0a:d683::/32
