JADEPUFFER: разрушительная активность в Azure с использованием скомпрометированных идентификаторов
Исследователи Microsoft Security выявили вредоносную активность в облачной инфраструктуре, связанную с JADEPUFFER — группировкой, которую Sysdig обнаружила в июле 2026 года и назвала первой документированной операцией с использованием агентского вымогательского ПО. Наше расследование выявило масштабную кампанию по уничтожению ресурсов в Azure с использованием скомпрометированных service principal и сбором облачных учётных данных, которые в дальнейшем могли применяться для кражи данных.Эти результаты расширяют публично документированную информацию о деятельности JADEPUFFER, которую Microsoft отслеживает как Storm-3168, и демонстрируют развитие облачных операций группировки. Мы впервые подробно описали её активность в Azure. В скомпрометированной среде Azure были обнаружены массовые операции по уничтожению ресурсов. Для их проведения злоумышленники скомпрометировали service principal и атаковали Azure Storage Accounts, базы данных SQL, Key Vault, Function Apps, блокировки защиты от удаления и восстановления, виртуальные машины и App Services.
Организации могут снизить риски, защищая workload identities и секреты, применяя принцип наименьших привилегий, защищая ресурсы восстановления и включая соответствующие механизмы защиты Microsoft Defender for Cloud. Опубликованные в открытом доступе учётные данные остаются пригодными для использования до тех пор, пока их не отзовут или не заменят. Простого удаления исходной публикации недостаточно для устранения риска.
Эта активность указывает на более широкий переход к атакам, координируемым с помощью ИИ, при которых злоумышленники могут быстрее и масштабнее выполнять сложные действия после получения доступа к облачной инфраструктуре. По мере развития таких возможностей защитникам также необходимо использовать ИИ для расследования инцидентов и реагирования в крупных средах. Вместо того чтобы заставлять аналитиков вручную отслеживать каждое отдельное действие, такие проекты, как Project Perception и MDASH, предполагают модель, в которой ИИ помогает защитникам расследовать инциденты и реагировать на них в средах, становящихся всё более масштабными и сложными.
Обзор атаки
Microsoft обнаружила два скомпрометированных service principal, принадлежавших одному и тому же tenant. Один из них занимался разведкой и обнаружением ресурсов. Второй выполнял разведку, разрушительные операции и сбор учётных данных.Активность скомпрометированных service principal в Azure
Разведка перед уничтожением
В начале июня 2026 года один из скомпрометированных service principal в течение примерно 15 часов 30 минут перечислял виртуальные машины Azure, подписки, группы ресурсов и другие ресурсы затронутого tenant. За это время было выполнено более 300 успешных операций чтения. Такой объём разведывательной активности позволил бы злоумышленникам получить широкое представление об Azure-инфраструктуре организации.Примерно через 90 минут после начала разведки первым service principal второй скомпрометированный service principal за пять секунд перечислил виртуальные машины и группы ресурсов сразу в двух подписках.
Оба service principal использовали связанную со Storm-3168 инфраструктуру, одинаковый сетевой отпечаток и User-Agent python-requests/2.34.2.
Через 16 часов второй service principal успешно перечислил хранилища конфигурации Azure App Service, вероятно, в поисках открытых учётных данных. Также он безуспешно попытался обнаружить ресурсы Azure OpenSearch.
Через 70 секунд после этой последней операции инвентаризации тот же service principal попытался выполнить операцию ListKey для несуществующей учётной записи хранения.
Семиминутная последовательность разрушительных операций
Менее чем через секунду после неудачной операции ListKey для несуществующей учётной записи хранения второй скомпрометированный service principal приступил к разрушительным действиям.В течение следующих 35 минут он выполнил более 150 операций, связанных с уничтожением ресурсов или сбором учётных данных.
Сама последовательность разрушительных операций заняла около семи минут. За это время было предпринято более 100 попыток удалить учётные записи Azure Storage. Большинство атакованных Storage Accounts были успешно удалены.
Однако для части учётных записей операции удаления заблокировали Azure Resource Locks и встроенная защита от удаления на уровне Storage Account. Это демонстрирует ценность независимых механизмов защиты, которые продолжают работать даже в ситуации, когда скомпрометированная учётная запись обладает широкими административными полномочиями.
Также были удалены Azure Key Vault, Function App и App Service plan. Все они находились в одной группе ресурсов и, судя по всему, обслуживали соответствующее Function App.
Параллельно с удалением Storage Accounts тот же service principal пытался удалить несколько баз данных Azure SQL. Все эти попытки завершились неудачей: для ресурса Azure SQL Database использовалась неподдерживаемая версия API.
Кроме того, было предпринято несколько неудачных попыток удалить блокировки Azure Site Recovery и Azure Backup, защищавшие Storage Accounts.
Сбор учётных данных
Примерно через 30 минут после последней разрушительной операции тот же service principal запросил список Azure Storage Accounts и выполнил более 30 успешных запросов ListKeys, заставляя Azure Resource Manager возвращать ключи доступа соответствующих Storage Accounts.Среди них находились и Storage Accounts, связанные с Azure Site Recovery.
Технический анализ
Возможный первоначальный доступ
- Утечка учётных данных. Неизвестно, каким именно образом service principal был изначально скомпрометирован. Однако его client ID, client secret и tenant ID ранее были опубликованы сотрудником затронутой организации в открытом виде в публичной записи GitHub issue. Позже запись отредактировали и удалили секрет из текста, но он остался доступен через публичную историю изменений issue. Удаление или редактирование опубликованного секрета не делает его недействительным: любые учётные данные, оказавшиеся в открытом доступе в интернете, следует считать скомпрометированными и незамедлительно отзывать или заменять. Мы не смогли подтвердить, использовался ли именно этот секрет в описанной активности.
- Проверка приложений. С начала 2026 года мы также наблюдали регулярное сканирование со связанной со Storm-3168 инфраструктуры нескольких Azure App Services, принадлежащих разным клиентам. Злоумышленники проверяли чувствительные пути, связанные с администрированием WordPress, PHP-CGI, endpoint проверки кода LangFlow (/api/v1/validate/code) и другими путями, характерными для web shell. При этом целевые App Services не пересекались с затронутыми подписками Azure, а пути получения учётных данных App Service → ARM (Azure Resource Manager) для затронутого tenant обнаружены не были.
Скоординированная автоматизация
Временные интервалы между различными операциями, разделение задач между несколькими service principal и использование пересекающихся потоков токенов одним и тем же service principal убедительно указывают на автоматизированное или скриптовое выполнение действий.Мы обнаружили пять уникальных токенов, выданных service principal, использовавшемуся для уничтожения ресурсов и сбора учётных данных. Четыре токена поддерживали операции удаления, а пятый использовался для инвентаризации Storage Accounts и получения ключей.
Два токена, применявшихся для удаления ресурсов, одновременно находились в работе в течение одного 70-секундного периода. Один из них занимался удалением Storage Accounts, другой — одновременно удалением Storage Accounts и баз данных SQL.
Key Vault, Function App и App Service plan, связанные с одним приложением, были удалены. При этом Storage Account с похожим названием в той же группе ресурсов остался нетронутым, а позднее скомпрометированный service principal успешно запросил для него ключи через ListKeys.
Все операции выполнялись в рамках уже существовавших назначений ролей Azure для этого идентификатора.
Роль Storage Account Contributor, назначенная через группу, предоставляла права, необходимые для разрушительных операций со Storage Accounts. Прямой доступ уровня Contributor позволял удалить три ресурса приложения и успешно получить ещё один набор ключей.
Прямой доступ SQL DB Contributor разрешал многочисленные попытки удаления баз данных SQL. Они завершились неудачей из-за использования неподдерживаемой версии API для соответствующего типа ресурса Azure SQL Database.
Разрушительная активность, соответствующая целям вымогательской атаки
Злоумышленники удалили множество ресурсов Azure, одновременно атакуя ресурсы, связанные с резервным копированием и восстановлением. Среди них были блокировки Azure Site Recovery и Storage Accounts с названиями, указывающими на использование Terraform или резервного копирования. Это может свидетельствовать о намерении затруднить восстановление инфраструктуры после разрушительных действий.Параллельная атака на базы данных Azure SQL и Storage Accounts указывает на попытку расширить масштаб разрушения на разные типы сервисов хранения данных, а не ограничиваться одним ресурсом. Хотя удаление баз данных завершилось неудачей, сам факт включения этих операций в ту же последовательность даёт дополнительное представление о предполагаемом масштабе атаки.
Скомпрометированный service principal также неоднократно пытался получить ключи Storage Accounts. Такие ключи потенциально могли предоставить доступ к хранящимся там чувствительным данным.
В совокупности уничтожение ресурсов, попытки нарушить работу механизмов восстановления и сбор учётных данных, потенциально обеспечивающих доступ к данным, соответствуют тактикам, которые могут использоваться в вымогательских операциях.
При этом мы не обнаружили записки с требованием выкупа и не подтвердили успешную эксфильтрацию данных в рамках описанной активности.
Рекомендации по защите и снижению рисков
Microsoft рекомендует следующие меры для снижения вероятности и последствий активности, аналогичной описанной в этой кампании:- Включите соответствующие планы Microsoft Defender for Cloud для критически важных рабочих нагрузок Azure. Рассмотрите возможность включения средств защиты, соответствующих используемым ресурсам, включая Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service и Defender for Databases. Дополнительная информация доступна в обзоре Microsoft Defender for Cloud.
- Защищайте и регулярно проверяйте учётные данные приложений и секреты. Не храните credentials service principal, ключи Storage, строки подключения и другие секреты в исходном коде, конфигурационных файлах, публичных репозиториях, issues или других местах, где они могут оказаться в открытом доступе. Подробнее — в документации Microsoft Entra Workload ID.
- Незамедлительно заменяйте скомпрометированные или раскрытые учётные данные и организуйте полноценное управление их жизненным циклом. Учётные данные, однажды опубликованные в интернете, следует считать скомпрометированными, даже если исходная публикация позднее была отредактирована или удалена. Удаление содержимого не делает credential недействительным и не устраняет копии, которые могли сохраниться в истории изменений, кэшах, архивах, журналах или других системах. Незамедлительно отзывайте или заменяйте такие credentials и анализируйте историю их использования. По возможности следует отдавать предпочтение механизмам, уменьшающим зависимость от долгоживущих учётных данных. Подробнее — в руководстве по защите секретов с помощью Defender for Cloud.
- Применяйте принцип наименьших привилегий к service principal и другим workload identities. Проверьте разрешения Azure RBAC, назначенные service principal, и ограничьте их только теми ресурсами и операциями, которые действительно необходимы соответствующим приложениям. Подробнее — в рекомендациях по Azure RBAC.
- Защищайте инфраструктуру резервного копирования и восстановления как часть стратегии противодействия вымогательским атакам. Ограничивайте доступ к ресурсам резервного копирования и восстановления и внимательно отслеживайте попытки изменить или удалить механизмы их защиты. Подробнее — в рекомендациях по безопасности Azure Backup.
- Масштабируйте расследование и реагирование с помощью агентских средств защиты. Используйте Project Perception, чтобы помогать защитникам разворачивать ИИ-агентов для расследования инцидентов и реагирования в крупных и сложных средах.
- Усиливайте безопасность ИИ-приложений и агентских систем. Microsoft Defender for AI Security (кодовое название MDASH) предназначен для обнаружения ИИ-активов, выявления уязвимостей и ошибочных конфигураций и снижения рисков, связанных с путями атак на ИИ-системы.
Обнаружение в Microsoft Defender XDR
Пользователи Microsoft Defender XDR могут ориентироваться на следующие обнаружения.| Тактика | Название обнаружения | Покрытие Defender for Cloud |
|---|---|---|
| Collection, Exfiltration | Possible data exfiltration detected | Defender for App Services |
| Exfiltration | An abnormally large number of rows were extracted from an SQL server; Unusual volume of data extracted (Azure Cosmos DB); Access from an unusual location | Defender for Databases |
| Persistence, Execution, Command and Control | Communication with suspicious domain identified by threat intelligence | Defender for DNS |
| Exfiltration | Unusual amount of data extracted from a storage blob container; Unusual number of blobs extracted from a storage blob container; Unusual amount of data extracted from a sensitive blob container; Unusual amount of data extracted from a storage file share; Unusual number of files extracted from a storage file share | Defender for Storage |
| Initial Access | Access from a known suspicious IP address to a sensitive blob container; Access from a suspicious IP address; Access from a known suspicious IP address to a sensitive storage file share | Defender for Storage |
| Defense Evasion | Azure Resource Manager operation from suspicious proxy IP address | Defender for Resource Manager |
| Credential Access | Unusual operation pattern in a key vault; High volume of operations in a key vault; Unusual application accessed a key vault | Defender for Key Vaults |
Пользователи, имеющие соответствующий доступ, также могут применять Microsoft Security Copilot в Microsoft Defender для расследования и реагирования на инциденты, поиска угроз и использования актуальной информации о них.
Microsoft Security Copilot
Пользователи Security Copilot могут использовать автономный интерфейс для создания собственных запросов или запускать следующие готовые наборы запросов для автоматизации расследования и реагирования на инциденты, связанные с этой угрозой:- расследование инцидента;
- анализ пользователя Microsoft;
- профиль группировки угроз;
- отчёт Threat Intelligence 360 на основе статьи MDTI.
Отчёты об угрозах
Пользователи Microsoft Defender XDR могут использовать следующие Threat Analytics в портале Defender. Для доступа требуется лицензия как минимум на один продукт Defender XDR.Эти отчёты содержат информацию об угрозе, средствах защиты и рекомендуемых действиях для предотвращения, снижения последствий или расследования соответствующей активности в инфраструктуре клиента.
Пользователи Microsoft Security Copilot также могут воспользоваться интеграцией Microsoft Security Copilot в Microsoft Defender Threat Intelligence — как в автономном портале Security Copilot, так и во встроенном интерфейсе Microsoft Defender — для получения дополнительной информации об этой угрозе.
Техники MITRE ATT&CK
Следующие соответствия MITRE ATT&CK отражают действия, наблюдавшиеся в ходе этой активности.| Техника | Описание |
|---|---|
| T1190 — Exploit Public-Facing Application | Связанная со Storm-3168 инфраструктура неоднократно проверяла чувствительные пути в приложениях, размещённых в Azure App Service, потенциально для их эксплуатации. |
| T1078.004 — Valid Accounts: Cloud Accounts | Скомпрометированные service principal использовались для обнаружения и уничтожения ресурсов Azure. |
| T1526 — Cloud Service Discovery | Идентификаторы перечисляли подписки, виртуальные машины, группы ресурсов, Azure Storage, Web Apps, App Service plans, блокировки и Recovery Services. |
| T1485 — Data Destruction | Были удалены ресурсы Azure Storage, Key Vault, Function App и App Service plan. Также предпринимались попытки удаления Azure SQL, что расширяло разрушительную активность на базы данных. |
| T1490 — Inhibit System Recovery | Атакующие пытались удалить блокировки дисков Site Recovery и блокировку защиты Azure Backup. |
Индикаторы компрометации (IOC)
| Индикатор | Тип | Описание |
|---|---|---|
| 45.131.66[.]106 | IPv4 | Сканирование App Service и вредоносные запросы к ARM |
| 34.153.223[.]102 | IPv4 | Сканирование App Service |
| 64.20.53[.]230 | IPv4 | Сканирование App Service |
источник