O Microsoft Security Research revelou, em 25 de setembro, uma campanha do grupo Storm-3168 que usou credenciais de principais de serviço comprometidas para mapear, destruir e saquear um ambiente Azure em pouco mais de meia hora. Quem mantém segredos de identidade de carga de trabalho em repositórios, issues ou arquivos de configuração expostos precisa agir como se já tivesse sido invadido: revogar e rotacionar essas credenciais e reduzir as permissões dos principais de serviço é a prioridade imediata, porque apagar a publicação original não resolve nada.
O caso marca uma mudança de alvo nos ataques à nuvem: em vez de enganar um funcionário na tela de login, o atacante reutiliza identidades de máquina com permissões administrativas, herdadas com frequência de concessões genéricas, e automatiza descoberta, destruição e coleta de chaves numa velocidade que ultrapassa a resposta humana. O grupo está associado à operação JADEPUFFER, documentada pela Sysdig como a primeira operação de extorsão conduzida de ponta a ponta por um agente de inteligência artificial, e a Microsoft classifica a atividade observada como consistente com objetivos de ransomware e extorsão.
Como o ataque funcionou
A Microsoft observou dois principais de serviço comprometidos no mesmo tenant, com divisão clara de trabalho. O primeiro executou reconhecimento: enumerou máquinas virtuais, assinaturas, grupos de recursos e recursos por cerca de 15 horas e 30 minutos, com mais de 300 operações de leitura bem-sucedidas — amplitude suficiente para dar ao atacante visão completa do ambiente. Cerca de 90 minutos depois do início dessa varredura, o segundo principal enumerou VMs e grupos de recursos de duas assinaturas em cinco segundos. Os dois usaram infraestrutura ligada ao Storm-3168, a mesma impressão de rede e o user agent python-requests/2.34.2, sinal claro de execução automatizada.
Depois de inventariar configurações do Azure App Service, possivelmente em busca de credenciais embutidas, e de tentar sem sucesso uma operação ListKey contra uma conta de armazenamento inexistente, o segundo principal iniciou a fase destrutiva. A sequência durou cerca de sete minutos e concentrou mais de 100 tentativas de deletar contas de armazenamento, a maioria concluída com sucesso. Um Key Vault, um Function App e um plano de App Service do mesmo grupo de recursos também foram apagados. No balanço completo, o principal executou mais de 150 operações destrutivas e de coleta de credenciais em cerca de 35 minutos, com cinco tokens distintos emitidos em fluxos sobrepostos.
Um detalhe vale destaque: as tentativas contra bancos Azure SQL falharam porque o atacante usou uma versão de API não suportada para aquele tipo de recurso, e algumas contas de armazenamento sobreviveram graças a bloqueios de recurso e proteções de exclusão no nível da conta. São salvaguardas independentes que continuam funcionando mesmo quando a identidade comprometida tem permissões administrativas amplas — o argumento mais forte do relatório a favor de defesa em profundidade.
A credencial exposta no GitHub
A investigação não confirmou o vetor inicial, mas encontrou o cenário clássico: o client ID, o client secret e o tenant ID de um dos principais de serviço apareceram em texto claro em uma issue pública do GitHub, publicada por um funcionário da própria organização afetada. A issue foi editada para remover o segredo, mas o valor continuou acessível no histórico público de edições. A Microsoft é categórica ao afirmar que editar ou apagar a exposição não invalida a credencial: segredo exposto em qualquer local da internet pública deve ser tratado como comprometido e revogado ou rotacionado imediatamente.
Para equipes de segurança, isso redefine o perímetro da caça. O vazamento não está apenas no código: comentários, issues, tickets e snapshots de configuração publicados por funcionários mantêm segredos vivos por anos, e ferramentas de varredura que olham apenas o branch principal não os encontram. Um segredo de principal de serviço não expira sozinho, não exige segundo fator e herda todas as permissões atribuídas ao aplicativo — a combinação ideal para um invasor que quer velocidade e silêncio.
O padrão de extorsão
A escolha dos alvos revela intenção. Além das contas de armazenamento de produção, o atacante tentou deletar bloqueios do Azure Site Recovery e proteções do Azure Backup, e mirou contas com nomes ligados a backups e a automação de infraestrutura. Cerca de 30 minutos após a destruição, o mesmo principal emitiu mais de 30 requisições ListKey bem-sucedidas, incluindo contas de armazenamento usadas pela própria estrutura de recuperação de desastres. Destruir a capacidade de restauração e coletar chaves de acesso na sequência é o enxerto clássico de extorsão: sem backup e com dados acessíveis, a pressão sobre a vítima dobra.
A Microsoft não observou nota de resgate nem confirmou exfiltração neste incidente específico, mas conecta a atividade à linha JADEPUFFER descrita pela Sysdig em julho. No caso original, o atacante obteve acesso inicial explorando a CVE-2025-3248 em uma instância Langflow exposta na internet e conduziu toda a operação com um agente de IA: os payloads se autodescreviam com raciocínio em linguagem natural e o sistema corrigia erros em tempo real, passando de um login fracassado a uma correção funcional em 31 segundos. A infraestrutura do grupo também sondou endpoints de administração do WordPress, caminhos PHP-CGI e o endpoint de validação de código do Langflow em outros clientes, sem sobreposição com o tenant afetado.
Sinais para investigar agora
| Sinal | Onde procurar | Leitura |
|---|---|---|
| Rajada de leituras no Azure Resource Manager seguida de deleções em massa | Logs de atividade da assinatura e do tenant | Automação por identidade de máquina comprometida |
| ListKeys em série, inclusive em contas de recuperação | Log de atividades do ARM e alertas do Defender for Resource Manager | Coleta de chaves para acesso persistente a dados |
| Tokens sobrepostos do mesmo principal com funções distintas | Sign-in logs de identidades de workload | Divisão de trabalho típica do Storm-3168 |
| Tráfego com user agent python-requests a partir de IPs fora do previsto | Firewall e logs de acesso aos serviços de nuvem | Cruzar com os IOCs publicados pela Microsoft |
Os indicadores divulgados incluem os endereços 45.131.66.106, 34.153.223.102 e 64.20.53.230, ligados à sondagem de App Services e às requisições maliciosas ao ARM. Uma busca retroativa por esses IPs e pelo user agent no tráfego administrativo é o primeiro passo de qualquer triagem séria, mesmo em ambientes sem sinais de comprometimento visíveis.
Ações priorizadas de defesa
- P1 — Rotacionar tudo que já foi público. Tratar como comprometidos todos os segredos que apareceram em issues, repositórios ou fóruns, incluindo versões removidas e históricos de edição.
- P1 — Cortar privilégios de service principal. Revisar atribuições de papel: Contributor direto e Storage Account Contributor herdado por grupo autorizaram quase toda a destruição observada.
- P1 — Ativar detecção no plano de controle. Defender for Resource Manager, Storage, Key Vault, App Service e Databases geram alertas para rajadas de leitura, deleção e ListKeys.
- P2 — Blindar a recuperação. Bloqueios CanNotDelete em contas de armazenamento críticas e cofres de backup; o relatório mostra que essa camada salvou recursos mesmo com identidade administrativa comprometida.
- P2 — Eliminar segredos longos. Substituir client secrets por credenciais federadas, seguindo o modelo de identidade de serviço com menor exposição.
- P2 — Encurtar a vida dos tokens. Ajustar emissão, rotação e revogação seguindo o guia que endurece tokens de acesso na nuvem.
O episódio mostra que a pergunta relevante deixou de ser se a credencial vazou, e passou a ser quanto tempo ela continua válida depois de vazar. Identidade de máquina sem governo equivale a acesso administrativo à venda, e o custo de rotacionar segredos é sempre menor que o custo de reconstruir um ambiente inteiro destruído por um agente automatizado.