Hackers ligados ao JadePuffer apagam recursos de ambiente Microsoft Azure

Hackers associados ao JadePuffer comprometeram identidades de aplicativos no Microsoft Azure para realizar reconhecimento, coletar credenciais e apagar recursos de uma organização. A atividade, rastreada pela Microsoft como Storm-3168, ocorreu no início de junho de 2026 e representa uma evolução das operações do grupo em ambientes de nuvem.

Segundo a Microsoft Security Research, os invasores utilizaram dois service principals comprometidos — identidades usadas por aplicações e serviços para acessar recursos do Azure. Um deles foi empregado principalmente para reconhecimento, enquanto o segundo executou descoberta, coleta de credenciais e operações destrutivas.

Durante aproximadamente 15 horas e 30 minutos, o primeiro service principal realizou mais de 300 operações de leitura para enumerar máquinas virtuais, assinaturas, grupos de recursos e outros ativos do ambiente. Cerca de 90 minutos depois do início dessa atividade, a segunda identidade comprometida enumerou máquinas virtuais e grupos de recursos em duas assinaturas em apenas cinco segundos.

Após cerca de 16 horas, os invasores começaram a consultar configurações do Azure App Service, possivelmente em busca de credenciais expostas. Pouco depois, o segundo service principal realizou mais de 150 operações relacionadas a destruição de recursos ou coleta de credenciais em um intervalo de 35 minutos.

A etapa destrutiva mais intensa durou aproximadamente sete minutos e incluiu mais de 100 tentativas de exclusão de contas do Azure Storage. A maioria dos recursos de armazenamento visados foi apagada. Controles como Azure resource locks e mecanismos de proteção contra exclusão impediram, porém, a remoção de algumas contas.

Os responsáveis também conseguiram excluir um Azure Key Vault, uma Function App e um plano do App Service. Várias bases do Azure SQL foram alvo simultaneamente, mas as tentativas falharam porque os atacantes utilizaram uma versão de API incompatível com esse tipo de recurso. Bloqueios relacionados ao Azure Site Recovery e ao Azure Backup também foram alvo de tentativas de remoção.

Cerca de 30 minutos após a última atividade destrutiva, a mesma identidade realizou mais de 30 solicitações bem-sucedidas de ListKeys, recurso que permite obter chaves de acesso de contas do Azure Storage. Algumas delas estavam relacionadas ao Azure Site Recovery. Segundo a Microsoft, essas credenciais poderiam permitir acesso posterior a dados sensíveis.

A forma exata como o service principal foi comprometido não foi confirmada. A investigação identificou, entretanto, que seu client ID, client secret e tenant ID haviam sido publicados anteriormente em texto simples em uma issue pública do GitHub por um funcionário da organização afetada. O segredo foi posteriormente removido, mas permaneceu disponível no histórico público de edições. A Microsoft não conseguiu confirmar se essa credencial específica foi utilizada no ataque.

A análise também identificou sinais de automação. As operações foram divididas entre diferentes service principals e múltiplos tokens, alguns utilizados simultaneamente para apagar contas de armazenamento e bancos SQL. Para a Microsoft, o padrão e o intervalo entre as ações indicam execução automatizada ou baseada em scripts.

O JadePuffer havia sido documentado anteriormente pela Sysdig em uma operação de ransomware na qual um agente baseado em modelo de linguagem coordenou diferentes etapas do ataque. Na campanha analisada agora pela Microsoft, os pesquisadores associam a atividade ao mesmo agente, acompanhado internamente como Storm-3168.

A Microsoft considera a operação observada no Azure compatível com um objetivo relacionado a ransomware ou extorsão, principalmente pela exclusão de recursos e pelas tentativas de atingir mecanismos de backup e recuperação. Apesar disso, nenhuma nota de resgate foi identificada e a empresa não confirmou exfiltração bem-sucedida de dados.

Para reduzir o risco de ataques semelhantes, a Microsoft recomenda evitar o armazenamento de credenciais de service principals, chaves e connection strings em códigos, arquivos de configuração ou repositórios públicos. Credenciais expostas devem ser imediatamente revogadas ou rotacionadas, mesmo depois que o conteúdo original tiver sido removido. A empresa também orienta aplicar privilégio mínimo às identidades de workload e proteger de forma independente os recursos de backup e recuperação.