Атака на Azure с участием группировки JadePuffer показала неприятную вещь: для разрушительного инцидента в облаке злоумышленнику может хватить двух скомпрометированных service principal и нескольких часов разведки. По данным Dark Reading, атакующий пытался удалить облачные хранилища, приложения и базы данных, а сама активность выглядела как подготовка к вымогательству или ransomware-сценарию.
Microsoft связывает инцидент с JadePuffer, которую компания также отслеживает как Storm-3168. Ранее Sysdig называла эту группу первой задокументированной ransomware-операцией, управляемой большой языковой моделью. В новом эпизоде речь идет уже не о теоретическом риске агентного ИИ, а о практичной и довольно приземленной схеме: получить доступ к легитимной облачной идентичности, изучить окружение, а затем быстро сломать то, что можно сломать.
Инцидент произошел в начале июня. По данным Microsoft Security Research, атакующие скомпрометировали два service principal в одном Azure tenant. Первый около 15,5 часа занимался разведкой: изучал виртуальные машины, подписки, resource groups и другие ресурсы, выполнив более 300 успешных операций чтения. Второй service principal подключился к делу примерно через полтора часа после начала разведки и за пять секунд перечислил виртуальные машины и группы ресурсов в двух подписках.
Через 16 часов после старта активности второй service principal успешно перечислил хранилища конфигураций Azure App Service, вероятно, в поиске секретов и учетных данных. Были и неудачные попытки найти Azure OpenSearch, а также операция ListKey против несуществующего storage account. Затем началась разрушительная фаза: более 100 попыток удалить storage accounts, большинство из них успешные. В той же resource group злоумышленник удалил Azure Key Vault, Function App и App Service plan.
С базами данных вышло менее эффектно: атакующий параллельно пытался удалить несколько Azure SQL databases, но операции не прошли из-за неподдерживаемой версии API. Это хороший, почти комичный штрих к плохой новости: автоматизация уже опасна, но пока еще спотыкается о детали платформы. Правда, рассчитывать на такие случайные спасательные круги бизнесу не стоит. Следующая версия сценария может быть аккуратнее.
Примерно через 30 минут после разрушительных действий тот же service principal запросил инвентаризацию Azure Storage accounts, включая учетные записи, связанные с Site Recovery, а затем выполнил более 30 успешных ListKeys-запросов для получения ключей доступа. Microsoft описывает эту активность как совместимую с тактиками ransomware и вымогательства, но подчеркивает: записку с требованием выкупа исследователи не наблюдали, успешную эксфильтрацию данных тоже не подтвердили.
Откуда взялся первоначальный доступ, Microsoft не утверждает наверняка. Но исследователи нашли важную зацепку: client ID, client secret и tenant ID одного из service principal раньше оказались опубликованы открытым текстом в публичном GitHub issue сотрудником пострадавшей организации. Позже issue отредактировали и секрет убрали, но данные остались доступны через публичную историю изменений. Microsoft не подтверждает, что именно эти учетные данные использовались в атаке, однако для команд разработки вывод неприятно знакомый: удалить секрет из видимого текста недостаточно, если платформа хранит историю.
Для русскоязычных команд, которые активно переносят сервисы в Azure или поддерживают гибридную инфраструктуру, эта атака на Azure полезна не громким словом AI, а набором скучных, но рабочих уроков. Service principal часто живут дольше, чем помнят их владельцы. Права у них нередко шире, чем нужно. Секреты попадают в issue, логи, CI-конфиги и временные инструкции. А потом обычная учетная запись приложения начинает выглядеть для облака как законный администратор, просто очень быстрый и очень вредный.
Эксперты, опрошенные Dark Reading, расходятся в оценке роли ИИ. Ник Таусек из Swimlane согласен с предупреждением Microsoft об AI-orchestrated attacks, но считает, что в опубликованных данных видна скорее скоординированная автоматизация, чем доказательство того, что ИИ управлял каждым шагом. Это важное уточнение: маркетинговый страх перед агентами легко раздувается, а вот реальный риск лежит ближе к земле — в скорости, масштабе и способности автоматических сценариев пройти по облаку быстрее, чем человек успеет открыть дашборд.
Microsoft пишет, что с начала года инфраструктура, связанная с JadePuffer, проверяла разные Azure App services у нескольких клиентов. Среди путей, которые изучал атакующий, называются администрирование WordPress, PHP-CGI, endpoint LangFlow для проверки кода /api/v1/validate/code и другие web-shell-подобные маршруты. То есть интерес группы не ограничивается одним tenant: она явно ищет повторяемые способы входа в облачные окружения.
Практический минимум защиты здесь без сюрпризов, но именно его чаще всего и откладывают. Нужно включать релевантные планы Microsoft Defender for Cloud для критичных workloads, постоянно проверять application credentials и secrets, сразу ротировать скомпрометированные или засвеченные учетные данные, вводить жизненный цикл для секретов и урезать права service principal по принципу least privilege. Для разработчиков это означает еще и дисциплину вокруг GitHub issues, CI/CD, логов и внутренних инструкций: секрет, попавший в историю, уже нельзя считать секретом.
Главный вопрос после этой истории не в том, был ли JadePuffer полностью автономным AI-актером. Важнее другое: готовы ли компании к ситуации, где разрушительная атака на Azure развивается не днями, а минутами, и где легитимная облачная идентичность становится самым удобным инструментом саботажа.