За две недели злоумышленники устроили 81 миллион попыток входа в корпоративные аккаунты Microsoft 365. Для русскоязычной IT-аудитории здесь неприятен не сам масштаб, а механика: атаки на Microsoft 365 шли не через экзотику нулевого дня, а через старые утечки паролей и дыры в настройке MFA, которые в компаниях часто считают уже «закрытым вопросом».
По данным BleepingComputer, кампания продолжалась с 12 по 26 июня 2026 года и затронула клиентов Huntress. Исследователи зафиксировали компрометацию 78 учетных записей в 64 организациях. Схема была довольно приземленной: атакующие брали все еще рабочие пары логин-пароль из прошлых утечек и массово проверяли их через Azure CLI. Когда связка оказывалась валидной, они проходили аутентификацию через OAuth-механизм ROPC (Resource Owner Password Credentials). Именно этот момент оказался для многих компаний ловушкой: формально MFA включена, а по факту конкретный сценарий входа ее не задевал.
Azure CLI сам по себе не уязвимость и не «черный ход». Это штатный инструмент администрирования Azure: через него управляют виртуальными машинами, деплоем приложений, базами данных и автоматизацией облачной инфраструктуры. Проблема в другом: если корпоративная защита завязана на неполные правила Conditional Access, атакующий получает вполне легальный путь проверки украденных учетных данных. Huntress отдельно отмечает, что ROPC давно считается спорным механизмом именно потому, что плохо дружит с современными сценариями аутентификации вроде MFA и SSO. Проще говоря, пароль уходит сразу на endpoint выдачи токена, без интерактивного запроса второго фактора. Для атакующего это почти идеальный формат: минимум шума для пользователя и максимум шансов, что защита не сработает там, где администратор был уверен в обратном.
Самое интересное в этой истории — не 81 миллион попыток как красивое число для заголовка, а типовые ошибки на стороне жертв. Huntress перечисляет несколько сценариев, которые снова выглядят слишком знакомо. Во многих компаниях MFA применялась только к отдельным приложениям, а не ко всем облачным сервисам. Где-то второй фактор требовали только для избранных групп, например администраторов, словно обычный сотрудник с доступом к почте, файлам, календарям и внутренним сервисам не представляет ценности. Еще один распространенный перекос: MFA включена только для «недоверенных» локаций, а трафик из IP-адресов, которые система считает доверенными, проходит мягче. Наконец, часть политик работала в режиме report-only, то есть аккуратно собирала телеметрию и никому не мешала. В некоторых пострадавших организациях политики MFA не было вовсе.
Отдельный маркер тренда — рост интенсивности самих атак. Huntress говорит о скачке password spraying более чем в 155 раз. Теперь средняя организация наблюдает 1964 неуспешные попытки входа на один tenant в месяц. Это важная цифра для тех, кто до сих пор смотрит на множественные неудачные логины как на фоновый шум, а не как на материал для расследования. Password spraying отличается от грубого перебора тем, что атакующий не ломится в одну учетку тысячей вариантов. Он берет небольшой набор популярных или утекших паролей и прогоняет их по большому числу пользователей. Такой трафик дольше остается незаметным, меньше цепляет стандартные блокировки и выглядит для части систем почти как неловкая активность самих сотрудников. В корпоративной среде, где десятки подрядчиков, гибридный доступ и исторически неровная IAM-конфигурация, это работает слишком хорошо.
Кто стоит за кампанией, пока неясно. Huntress связывает активность с IPv6-диапазоном, принадлежащим LSHIY LLC (AS32167), и сообщает, что направила уведомление через abuse-портал компании, но ответа на момент публикации отчета не получила. Это не означает, что владелец диапазона обязательно организовал атаку: инфраструктуру часто арендуют, перепродают или компрометируют. Но для защитных команд здесь есть практический вывод. Если в логах есть необычная аутентификация через Azure CLI, запросы к ROPC-потоку и всплески неудачных логинов, привязанных к редким сетевым диапазонам, это уже не повод отложить задачу в «посмотрим позже». Это повод быстро проверять Conditional Access, охват MFA по всем облачным приложениям и саму необходимость разрешать такие legacy-friendly потоки входа.
Для разработчиков и платформенных команд история тоже прикладная. Атаки на Microsoft 365 редко заканчиваются только входом в почту. Если учетная запись участвует в DevOps-процессах, имеет доступ к Azure-ресурсам, CI/CD, секретам, служебным почтовым ящикам или внутренней документации, один «обычный» пользователь быстро превращается в стартовую точку для движения глубже в инфраструктуру. Для бизнеса это означает старую, но неприятную истину: формальная галочка «MFA включена» больше ничего не гарантирует. Вопрос уже не в наличии контроля, а в том, покрывает ли он все реальные сценарии аутентификации, которые используются в экосистеме Microsoft. Если политика написана выборочно, атакующий найдет тот самый угол, куда никто давно не заглядывал.
На рынке это выглядит как очередное напоминание, что IAM в 2026 году остается не «базовой гигиеной», а полем для очень дорогих ошибок. Компании постепенно научились жить с фишингом, EDR и сегментацией, но по-прежнему регулярно проигрывают на стыке legacy-протоколов, исключений в Conditional Access и переоценки собственной зрелости. Главный вопрос теперь не в том, продолжатся ли такие кампании, а в том, сколько организаций еще считают свои политики MFA надежными, хотя они защищают лишь красивую часть схемы, а не реальный периметр входа.