Хакеры атаковали Microsoft 365, совершив 81 млн попыток входа
изображение: grok
Специалисты зафиксировали одну из крупнейших за последнее время кампаний по подбору учётных данных против Microsoft 365. За 14 дней атакующие совершили свыше 81 миллиона попыток входа в корпоративные аккаунты, а минимум 78 учётных записей в 64 компаниях были скомпрометированы. Основой операции стал устаревший механизм авторизации Azure CLI и ошибки настройки многофакторной защиты.
Расследование провели специалисты компании Huntress. Активная фаза кампании длилась с 12 по 26 июня. Никакого сложного вредоносного ПО злоумышленники не создавали и не применяли — они пошли по проверенному пути и использовали ранее украденные логины с паролями, которые владельцы аккаунтов так и не удосужились сменить после предыдущих утечек.
22 июня превратился для атакующих в наиболее продуктивный день. За одни сутки они получили доступ сразу к 30 пользовательским аккаунтам, принадлежащим 23 разным организациям. До этого успешные взломы фиксировались тоже, но в куда меньшем масштабе.
Львиная доля подозрительной активности, по данным Huntress, шла из автономной системы AS32167, принадлежащей провайдеру интернет-инфраструктуры LSHIY LLC. Анализ IP-адресов не дал однозначного ответа о географии атакующих. Одни сервисы геолокации привязывали адреса к США, другие указывали на Китай, и потому исследователи воздержались от выводов о происхождении операции.
Стоит обратить внимание, что за последние полгода количество кампаний с использованием ранее украденных учётных данных клиентов Huntress выросло более чем в 155 раз.
Центральным элементом операции стал Azure CLI — интерфейс командной строки Microsoft для работы с облачной инфраструктурой Azure. Атакующие обошли стандартную процедуру авторизации и задействовали устаревший поток OAuth Resource Owner Password Credentials, известный под аббревиатурой ROPC.
Этот механизм давно признан морально устаревшим. Работает он просто и потому опасно — принимает связку логин-пароль напрямую, без современных элементов проверки личности. От актуальных способов авторизации ROPC отличается тем, что не поддерживает нормальную работу с многофакторной аутентификацией и рядом смежных защитных механизмов.
Такая архитектура и открыла преступникам возможность применять украденные данные для получения токенов доступа, минуя привычные запросы на подтверждение через второй фактор.
Многие пострадавшие организации, как выяснили в Huntress, пребывали в уверенности, что защищены полностью, ведь MFA у них была включена. Реальность оказалась куда хуже ожиданий.
Корень проблемы прячется не в самой технологии MFA, а в её настройке. Политики условного доступа во многих случаях просто не распространялись на поток авторизации Azure CLI через ROPC. Формально защита была, но конкретный маршрут входа оказался за её периметром.
При разборе наиболее активной волны атак специалисты изучили 23 пострадавшие компании. В пятнадцати из них многофакторная аутентификация формально работала, но разного рода огрехи конфигурации позволили атакующим её обойти:
- дополнительные проверки распространялись лишь на отдельные приложения Microsoft, тогда как остальные облачные сервисы оставались без должной защиты;
- политика касалась только административных аккаунтов и не затрагивала обычных пользователей;
- правила срабатывали лишь при подключении из заранее заданных географических зон;
- часть настроек MFA существовала только в режиме отчётности и никогда не применялась на практике;
- поток авторизации через Azure CLI полностью выпадал из-под действия политик условного доступа.
Как отмечается в отчёте Huntress, произошедшее не стоит воспринимать как доказательство бесполезности многофакторной аутентификации — напротив, случай показывает, насколько критична корректная настройка политик безопасности.
Для снижения риска компрометации исследователи рекомендуют комплекс мер:
- распространять требования MFA на всех пользователей без исключений;
- применять эти же требования ко всем облачным приложениям, а не к выборочным;
- закрывать многофакторной защитой любые клиентские способы входа, включая устаревшие;
- ограничивать использование Azure CLI сотрудниками, которым инструмент не нужен по работе;
- регулярно проверять, что политики условного доступа реально работают, а не висят в режиме отчёта.
Мониторинг инцидентов заслуживает отдельного разговора. В Huntress советуют смотреть не на гигантское количество неудачных попыток входа, а на каждый успешный вход с подозрительных или ранее засвеченных учётных данных. Именно такие события чаще всего сигнализируют, что атака уже дошла до цели.
Ранее сообщалось, что исследователи Varonis обнаружили критическую уязвимость в корпоративной версии Microsoft Copilot, которая позволяла злоумышленникам получать доступ к конфиденциальным данным компаний. Для эксплуатации пользователю было достаточно перейти по специально подготовленной ссылке, после чего Copilot мог самостоятельно собрать внутреннюю информацию, включая данные сотрудников и коды двухфакторной аутентификации, и передать их атакующим. После получения отчёта Microsoft устранила уязвимость и присвоила ей максимальный уровень опасности.
По словам специалистов редакции CISOCLUB, описанный инцидент показателен своей простотой — атакующие не изобретали новых техник, а грамотно воспользовались чужой невнимательностью к настройкам. Многофакторная аутентификация давно перестала быть галочкой в отчёте о соответствии, и относиться к ней как к волшебной таблетке нельзя. Каждая политика условного доступа требует регулярного пересмотра, тестирования на живых сценариях входа и последовательного закрытия всех устаревших маршрутов авторизации.
Компаниям стоит провести аудит именно тех сервисов, которые традиционно остаются в тени — командные интерфейсы, старые OAuth-потоки, служебные аккаунты. Опыт клиентов Huntress подсказывает, что рост подобных кампаний в 155 раз за полгода — это только начало более масштабной волны.
