Группировка Storm-2949 использовала штатный механизм Self-Service Password Reset, чтобы заходить в Microsoft 365, а затем вытягивать данные уже из production-сред Azure. Для компаний, у которых облако давно стало частью боевого контура, это неприятное напоминание: атаки на Azure теперь все чаще идут не через экзотические эксплойты, а через легитимные админские функции, которыми злоумышленник пользуется почти как ваш собственный инженер.
Об этом сообщает BleepingComputer со ссылкой на Microsoft. По версии компании, цель Storm-2949 была предельно приземленной и оттого опасной: вытащить максимум чувствительных данных из самых ценных активов жертвы. Входной билет в атаку оказался тоже без магии. Злоумышленники выбирали пользователей с привилегированными ролями, прежде всего IT-сотрудников и представителей руководства, и через социальную инженерию добивались доступа к учетным данным Microsoft Entra ID.
Ключевой прием выглядел так. Атакующий запускал для выбранного сотрудника процедуру SSPR, то есть самостоятельного сброса пароля, а затем убеждал жертву подтвердить MFA-запросы. Для правдоподобия он представлялся сотрудником внутренней поддержки и давил на срочность: аккаунт якобы нужно немедленно верифицировать. После одобрения MFA цепочка ломалась в пользу нападавшего: пароль меняли, существующие методы многофакторной аутентификации убирали, а Microsoft Authenticator регистрировали уже на устройстве атакующего. Если коротко, сотрудник думал, что помогает службе поддержки, а на деле передавал контроль над своей учеткой.
Дальше началась вполне методичная эксплуатация полученного доступа. Storm-2949 использовала Microsoft Graph API и собственные Python-скрипты, чтобы перечислить пользователей, роли, приложения и service principals, а заодно понять, где можно закрепиться надолго. После этого злоумышленники пошли в OneDrive и SharePoint, где искали VPN-конфигурации и операционные IT-файлы. Такой интерес к внутренней документации важен сам по себе: это уже не просто кража файлов из облачного офиса, а попытка найти маршруты для движения из облака во внутреннюю сеть. Microsoft приводит показательный эпизод: в одном случае через веб-интерфейс OneDrive были скачаны тысячи файлов одним действием. Причем такой сценарий повторялся на всех скомпрометированных аккаунтах, потому что у разных сотрудников был доступ к разным каталогам и общим папкам.
На этом история не закончилась. Получив нужные учетные записи, злоумышленники расширили операцию на Azure-инфраструктуру жертвы: виртуальные машины, storage accounts, key vaults, app services и SQL-базы. Здесь особенно неприятно то, что речь идет не о случайном блуждании по облаку, а о работе по production-подпискам и ролям с привилегиями. По данным Microsoft, Storm-2949 скомпрометировала несколько идентичностей с кастомными привилегированными Azure RBAC-ролями в нескольких подписках. Этого хватило, чтобы добраться до наиболее чувствительных ресурсов.
Дальше атаки на Azure шли по учебнику злоупотребления штатными возможностями платформы. Используя привилегии в Azure RBAC, атакующие получали учетные данные, которые позволяли развернуть FTP, Web Deploy и консоль Kudu для администрирования Azure App Services. Это уже дает очень практичный набор возможностей: просматривать файловую систему, проверять переменные окружения, выполнять команды в контексте приложения. Затем Storm-2949 переключалась на Azure Key Vault, меняла настройки доступа и вытаскивала десятки секретов, включая учетные данные баз данных и connection strings. Параллельно злоумышленники меняли firewall- и сетевые правила для Azure SQL и Storage accounts, получали storage keys и SAS-токены и выкачивали данные с помощью кастомных Python-скриптов.
Особенно показательно, что и на уровне виртуальных машин злоумышленники не искали экзотику. Microsoft пишет о злоупотреблении функциями VMAccess и Run Command: с их помощью создавались подставные администраторские аккаунты, выполнялись удаленные скрипты и похищались дополнительные учетные данные. На поздних этапах атаки Storm-2949 развернула ScreenConnect на уже скомпрометированных системах, пыталась ослабить защиту Microsoft Defender и зачистить следы. То есть схема была выстроена не вокруг одного удачного входа, а вокруг последовательного расширения контроля, пока облачная компрометация не превращалась в широкую операцию по краже данных.
Для рынка это еще один сигнал, что модель угроз в облаке заметно изменилась. Раньше разговор о защите часто сводился к патчам, уязвимостям сервисов и безопасности периметра. Теперь все чаще проблема в том, что у злоумышленника уже есть легитимная учетная запись, а значит, он действует почти без лишнего шума. Отсюда и рекомендации Microsoft выглядят не как ритуальный чеклист, а как минимум санитарии: принцип наименьших привилегий, conditional access, MFA для всех пользователей и фишинг-устойчивая MFA для администраторов и других привилегированных ролей. Для Azure компания отдельно советует жестче ограничивать RBAC-права, хранить логи Azure Key Vault до года, сокращать доступ к хранилищам секретов, закрывать публичный доступ к Key Vault, использовать механизмы защиты данных в Azure Storage и следить за высокорисковыми управленческими операциями.
Для разработчиков, DevOps-команд и IT-руководителей вывод неприятный, но полезный: атаки на Azure больше не выглядят как отдельная история для SOC и облачных администраторов. Если в production-контуре секреты лежат там, где до них можно дотянуться через избыточные RBAC-права, если служебные веб-приложения открывают путь к основным системам, а helpdesk-сценарий с MFA-подтверждением все еще работает, то компрометация одной учетной записи быстро превращается в компрометацию сервиса. И главный вопрос здесь уже не в том, включена ли у вас многофакторка, а в том, сколько реальной власти получает атакующий после первого успешного входа. Подробности цепочки и рекомендации Microsoft можно посмотреть в разборе .