Что случилось и почему это важно
Microsoft Security Research опубликовала разбор атаки группировки, которую сама Microsoft отслеживает под именем Storm-3168, а компания Sysdig ранее назвала JadePuffer. Атака интересна не столько масштабом, сколько методом: значительная часть действий выполнялась автономными AI-агентами, а не оператором за клавиатурой в реальном времени. Sysdig описывает JadePuffer как первую документированную операцию вымогательского ПО, управляемую большой языковой моделью.
Что произошло технически, в общих чертах
В начале июня 2026 года атакующие получили доступ к двум service principals (машинным identity-объектам, которые приложения и автоматизированные инструменты используют для аутентификации в Azure) в рамках одного арендатора (tenant). По данным Microsoft, учётные данные одного из этих service principals ранее оказались опубликованы в открытом issue на GitHub.
Дальше атака шла в два этапа:
- Разведка: один из скомпрометированных объектов более 15 часов картировал инфраструктуру, перечисляя виртуальные машины, подписки и группы ресурсов.
- Уничтожение: второй объект за отдельный промежуток времени выполнил более 150 деструктивных операций и операций по сбору учётных данных, включая попытки удаления свыше 100 учётных записей хранилища Azure Storage. Сама фаза уничтожения заняла всего около семи минут.
Атакующие также попытались отключить защиту резервного копирования (блокировки Azure Site Recovery), чтобы затруднить восстановление, и нацеливались на Key Vault, Function Apps, виртуальные машины и App Services. Часть учётных записей хранилища уцелела благодаря заранее настроенным блокировкам ресурсов (resource locks) и защите на уровне самой учётной записи. Попытки удалить базы данных Azure SQL и снять блокировки восстановления не удались из-за использования устаревшей версии API, техническая случайность, а не защитная мера.
Признаков вымогательской записки или подтверждённой утечки данных Microsoft в этом эпизоде не обнаружила, но характер действий соответствует тактикам, типичным для вымогательских и вымогательско-экстортивных операций.
Почему это важно, даже если у вас нет Azure
Это не единичный курьёз, а иллюстрация направления, в котором развиваются атаки: AI-агенты, автономно проходящие всю цепочку от разведки до уничтожения без постоянного участия оператора, резко сокращают время между первичным доступом и максимальным ущербом. Разведка заняла часы, но разрушительная фаза, всего семь минут, у традиционной атаки с оператором за клавиатурой на такой объём действий ушло бы значительно больше времени.
Официальные рекомендации Microsoft
- Наименьшие привилегии (least privilege) для RBAC-ролей: service principals должны иметь только те права, которые реально нужны для их задачи, а не широкие административные полномочия.
- Сканирование на утечки секретов: регулярно проверяйте публичные репозитории и issue-трекеры вашей организации на случайно опубликованные ключи, токены и учётные данные, именно так, по данным Microsoft, атакующие могли получить первоначальный доступ в этом случае.
- Защита рабочих нагрузок в облаке (cloud workload protection): включите и настройте соответствующие инструменты мониторинга и обнаружения аномальной активности в Azure.
- Блокировки ресурсов и защита резервного копирования: как показал этот случай, именно заранее настроенные resource locks спасли часть данных, когда остальные меры защиты не сработали.
Что ещё нужно знать
Это уязвимость в самом Azure?
Нет, судя по имеющимся данным, атака построена на компрометации учётных данных (украденных или случайно раскрытых), а не на эксплуатации уязвимости в платформе Azure как таковой.
Как узнать, публиковались ли когда-либо секреты вашей организации на GitHub случайно?
GitHub и сторонние инструменты secret-сканирования могут ретроспективно проверять историю публичных и приватных репозиториев на предмет случайно закоммиченных ключей и токенов, стоит включить такую проверку, если она ещё не настроена.
Затрагивает ли это другие облачные платформы, не только Azure?
Задокументированный Microsoft случай касается именно Azure, но принцип атаки, компрометация машинных identity-объектов с последующей автономной AI-управляемой разведкой и уничтожением, применим в принципе к любой облачной платформе с похожей моделью service principal.
Есть ли способ полностью защититься от AI-driven атак?
Специфичного «противоядия» именно от AI-агентов нет, базовая гигиена (минимальные привилегии, защита секретов, резервные копии с блокировками) остаётся эффективной защитой независимо от того, автоматизирует атакующий свои действия вручную или через AI-агента.
Что в итоге
JadePuffer показывает, как быстро может развиваться атака, если разведку и разрушение выполняет автономный агент, а не человек в реальном времени, но сама механика (компрометация раскрытых учётных данных, недостаточно ограниченные права доступа) остаётся классической. Резервные блокировки ресурсов и принцип наименьших привилегий сработали как последний рубеж защиты даже в этом случае, стоит убедиться, что они настроены в вашей среде Azure, а не только теоретически задокументированы.
