JadePuffer превратил атаки на Azure в почти конвейерную операцию: за семь минут злоумышленники попытались снести более 100 storage-аккаунтов и зацепили Key Vault, Function Apps, виртуальные машины и App Services. По данным Microsoft Security Research, группа использовала скомпрометированные service principals и автоматизировала разведку, сбор учетных данных и разрушительные действия с помощью AI-агентов, сообщает BleepingComputer. Для команд, которые держат продакшен в Azure, это неприятное напоминание: секрет в публичном репозитории теперь может стоить не одного сервиса, а целого облачного контура.
Инциденты, которые описала Microsoft, произошли в июне 2026 года. Компания отслеживает оператора JadePuffer под именем Storm-3168. В двух наблюдавшихся атаках злоумышленник сначала картировал облачные ресурсы, затем получал ключи storage-аккаунтов и переходил к удалению базовых компонентов инфраструктуры. Microsoft пишет, что атакующий использовал два service principals из одного tenant: один применялся для разведки и инвентаризации, второй — для discovery, удаления ресурсов и сбора учетных данных.
Service principal в Azure — это машинная идентичность для приложений, hosted-сервисов и автоматизации. В нормальной жизни она нужна, чтобы пайплайн, скрипт или сервис могли обращаться к ресурсам без участия человека. В плохой жизни она становится идеальным пропуском: если права выданы широко, а секрет утек, атакующий получает не просто пароль, а API-доступ к инфраструктуре. Microsoft не смогла точно установить, как именно Storm-3168 получил первоначальный доступ, но отметила важную деталь: учетные данные одного service principal до атак появлялись в публичном GitHub issue.
Разрушительная стадия длилась около семи минут. За это время Storm-3168 удалял Azure Storage accounts и пытался добраться до других сервисов, включая Key Vaults, Function Apps, Virtual Machines и App Services. Часть storage-аккаунтов удалось удалить, часть выжила благодаря resource locks и защитным настройкам на уровне самих аккаунтов. Это редкий случай, когда скучная галочка в облачной конфигурации оказывается заметно интереснее презентации про «AI-ready security».
Атакующий также пытался убрать защиту резервного копирования и восстановления, включая locks Azure Site Recovery. Эти попытки, по данным Microsoft, не сработали. Не удались и попытки удалить Azure SQL databases: злоумышленник использовал неподдерживаемую версию API. Но сам набор целей показателен. Storm-3168 бил не по одному типу ресурса, а пытался расширить ущерб сразу на несколько слоев данных и приложений. Примерно через полчаса после wipe-попыток оператор вернулся и отправил более 30 запросов на получение ключей storage-аккаунтов; большинство запросов завершилось успешно.
JadePuffer появился в публичном поле летом 2026 года. В июле исследователи Sysdig описали вредоносную активность, где AI-агенты автоматизировали почти всю цепочку атаки: от разведки и кражи credential-ов до lateral movement, закрепления и шифрования данных. Позже Sysdig сообщила, что JadePuffer расширил интерес на AI-активы, обучающие датасеты и векторные базы, используя инструмент EncForge. На этом фоне атаки на Azure выглядят не отдельной экзотикой, а продолжением тренда: злоумышленники всё чаще автоматизируют рутинные этапы компрометации и двигаются быстрее, чем команды успевают открыть нужный дашборд.
Важно, что Microsoft не подтвердила финансовые требования и не заявила о доказанной краже данных в этих конкретных случаях. Но поведение похоже на подготовку к вымогательству: удалить хранилища, ослабить восстановление, собрать ключи, расширить удар по разным сервисам. Для бизнеса риск здесь не только в шифровании файлов. В облаке больнее может оказаться удаление managed-ресурсов, потеря ключей доступа и разрушение зависимостей между сервисами, особенно если инфраструктура росла годами и документировалась по принципу «потом разберемся».
Практический вывод для разработчиков, DevOps и CISO довольно приземленный. Нужно искать секреты в публичных репозиториях и issue-трекерах, проверять права Azure RBAC по принципу минимально необходимого доступа, включать cloud workload protection и не лениться с resource locks для критичных ресурсов. Отдельно стоит пересмотреть service principals: кто их создал, где лежат credential-ы, когда они ротировались, какие роли назначены и можно ли заменить долгоживущие секреты более безопасными механизмами.
AI в этой истории не делает атаку магической, зато сокращает паузы между шагами. Там, где раньше оператор вручную осматривался, копировал команды и ошибался медленнее, агентная автоматизация может за минуты пройти разведку, выбрать цели и начать ломать восстановление. Следующий спор в облачной безопасности, похоже, будет не о том, используют ли атакующие AI, а о том, какие защитные контуры выдержат скорость машины без героизма ночной смены.
