JadePuffer/Storm-3168: um ator agêntico exclui o armazenamento de um locatário do Azure em uma rajada destrutiva de 7 minutos

A Microsoft Security Research informou em 25 de setembro de 2026 que um agente usando duas entidades de serviço comprometidas operou dentro de um locatário do Azure não identificado no início de junho de 2026, começando com mais de 15 horas de reconhecimento, depois, em cerca de sete minutos, tentou excluir mais de 100 contas de armazenamento, obtendo sucesso na maioria delas, e excluiu um Azure Key Vault, um Function App e um plano do App Service. A Microsoft atribui a intrusão ao agente que rastreia como Storm-3168, que a empresa de segurança Sysdig chama de JADEPUFFER e documentou em julho de 2026 como a primeira operação de ransomware executada de ponta a ponta por um grande modelo de linguagem. A Microsoft disse que não encontrou nenhuma nota de resgate e não confirmou que quaisquer dados tenham sido exfiltrados. O arquivo registra esta campanha como um incidente de alta gravidade com envolvimento confirmado de IA e danos reais, e a entrada completa no Orca AI Incident Archive traz suas fontes, classificação de gravidade e avaliação de confiança.

A vítima não é identificada. O relatório da Microsoft descreve um único tenant do Azure, duas entidades de serviço comprometidas que pertenciam a ele e uma divisão de trabalho entre elas: uma entidade cuidou do reconhecimento por cerca de 15 horas e 30 minutos e fez mais de 300 operações de leitura bem-sucedidas, enumerando máquinas virtuais, assinaturas, grupos de recursos e recursos; a outra realizou a descoberta, as operações destrutivas e a coleta de credenciais. A Microsoft não disse quantas organizações foram afetadas e não conseguiu estabelecer como as entidades de serviço foram comprometidas inicialmente.

O que a telemetria mostra, em ordem

A segunda entidade principal começou cerca de 90 minutos depois que a primeira começou e enumerou máquinas virtuais e grupos de recursos em duas assinaturas em cerca de cinco segundos, segundo a Microsoft. Ambas as identidades usaram infraestrutura que a Microsoft associa ao Storm-3168, compartilharam a mesma impressão digital de rede e apresentaram o mesmo user agent, python-requests/2.34.2. A Microsoft disse que o momento e a divisão de trabalho "indicam fortemente execução automatizada ou scriptada."

Cerca de 16 horas depois, a segunda entidade principal verificou os armazenamentos de configuração do Azure App Service em busca de credenciais expostas e procurou, sem sucesso, pelo Azure OpenSearch. Setenta segundos depois disso, ela tentou uma operação ListKey contra uma conta de armazenamento que não existia. Menos de um segundo após essa chamada malsucedida, a destruição começou. Ao longo dos 35 minutos seguintes, a Microsoft contou mais de 150 operações destrutivas ou de coleta de credenciais; a fase destrutiva principal durou cerca de sete minutos.

Os sete minutos, e os controles que aguentaram

A Microsoft afirma que a maioria das contas de armazenamento visadas pelo ator foi excluída com êxito. O ator também excluiu um Azure Key Vault, um Function App e um plano do App Service que estavam no mesmo grupo de recursos e pareciam dar suporte ao Function App. O direcionamento não se limitou ao armazenamento: a Microsoft registrou várias tentativas de excluir bloqueios do Azure Site Recovery e bloqueios de proteção do Azure Backup, e informou que essas tentativas falharam.

A Microsoft afirma que nem todas as exclusões funcionaram, e os motivos diferem de uma forma que é importante para os defensores. Algumas contas de armazenamento sobreviveram porque bloqueios de recursos do Azure e a proteção contra exclusão no nível da conta de armazenamento bloquearam a operação. As tentativas paralelas de excluir bancos de dados Azure SQL falharam por um motivo diferente: todas usaram uma versão de API sem suporte. A Cloud Security Alliance descreveu isso como um erro operacional, e não como uma ação bloqueada. A Microsoft resumiu a combinação de exclusão de recursos, tentativas de interferir na recuperação e coleta de credenciais como "consistente com táticas que podem dar suporte a operações de ransomware e extorsão."

A descrição da Microsoft trata de atribuições comuns de função do Azure, e não de uma exploração do próprio Azure. Ela constatou que uma função Storage Account Contributor concedida a um grupo permitiu a destruição do armazenamento, uma função Contributor direta permitiu a exclusão dos três recursos de aplicativo e outra recuperação de chave, e uma função SQL DB Contributor direta permitiu as tentativas de SQL malsucedidas. A Microsoft observou cinco tokens exclusivos emitidos para o segundo principal de serviço: quatro permitiam exclusão e o quinto tratava do inventário de armazenamento e da recuperação de chave. Dois dos tokens de exclusão estavam ativos durante o mesmo período de 70 segundos. O relatório também observa que contas de armazenamento com nomes com tema terraform e backup estavam entre os alvos, potencialmente para prejudicar a recuperação.

O retorno das chaves de armazenamento

Cerca de 30 minutos após o fim da destruição, o mesmo principal retornou. Ele inventariou contas de armazenamento e fez mais de 30 solicitações ListKeys bem-sucedidas, incluindo contra armazenamento vinculado ao Site Recovery. Uma conta de armazenamento com nome semelhante no mesmo grupo de recursos foi poupada durante a fase de exclusão e, em seguida, teve as chaves listadas com sucesso. A Microsoft não observou uma nota de resgate e não confirmou exfiltração de dados bem-sucedida, mas afirmou que as chaves coletadas poderiam viabilizar exfiltração futura.

Essa sequência muda o que significa recuperação, segundo Ross Filipek, diretor de segurança da informação da Corsica Technologies, que falou ao CSO Online sobre o incidente. Reconstruir os ativos excluídos não é suficiente, disse ele, porque as solicitações posteriores por chaves de armazenamento podem criar outro caminho para os dados; os responsáveis pela resposta precisam estabelecer quais identidades e chaves foram afetadas e revisar seu uso antes de confiar nos serviços restaurados. “Quando os atacantes detêm uma identidade de aplicação, sua atividade pode parecer administração comum de nuvem”, disse Filipek ao CSO Online.

Como as credenciais surgiram

A Microsoft não conseguiu confirmar o vetor de acesso inicial. O que ela encontrou foi uma exposição: o ID do cliente, o segredo do cliente e o ID do locatário de uma das entidades de serviço haviam aparecido em texto simples em uma issue pública do GitHub, publicada por um funcionário da organização afetada. A issue foi editada posteriormente, mas a Microsoft disse que o segredo permaneceu acessível por meio do histórico público de edições da issue. O relatório afirma claramente que a Microsoft não conseguiu confirmar se esse segredo foi o utilizado.

O aviso associado a essa constatação é a parte prática. A Microsoft afirma que credenciais que tenham sido expostas publicamente devem ser tratadas como comprometidas, revogadas ou rotacionadas imediatamente, e investigadas quanto a uso anterior; remover ou ocultar um segredo exposto não o invalida, e credenciais expostas publicamente permanecem utilizáveis até serem revogadas ou rotacionadas.

A Microsoft também descreveu uma sondagem mais ampla por infraestrutura vinculada ao Storm-3168 desde o início de 2026 contra o Azure App Services na administração do WordPress, no PHP-CGI, no endpoint do Langflow /api/v1/validate/code, e em caminhos semelhantes a webshell. Esses alvos não se sobrepunham às assinaturas da vítima, e a Microsoft não encontrou nenhum caminho de um App Service para credenciais do Azure Resource Manager. O relatório lista três indicadores: 45.131.66[.]106 para sondagem e solicitações ARM maliciosas, e 34.153.223[.]102 e 64.20.53[.]230 para sondagem do App Service.

O mesmo ator, uma operação diferente.

O relatório da Sysdig de 1º de julho de 2026 é o motivo pelo qual a palavra "agêntico" se associa a esse ator. A Sysdig descreveu o JADEPUFFER como o primeiro caso documentado de ransomware agêntico — "uma operação completa de extorsão conduzida de ponta a ponta por um modelo de linguagem de grande porte" — e afirmou que suas capacidades vinham de um agente de IA, e não de um conjunto de ferramentas operado por humanos. Nessa intrusão, o ator explorou CVE-2025-3248 em uma instância do Langflow exposta à internet, criptografou 1.342 itens de configuração do Nacos usando a função nativa do MySQL AES_ENCRYPT(), descartou as tabelas originais e deixou uma tabela README_RANSOM com um endereço Bitcoin e um contato do Proton Mail. A Sysdig relatou mais de 600 payloads distintos, código que se autodescreve e um payload corretivo de várias etapas executado 31 segundos após uma falha de login no Nacos. A Sysdig também afirmou que não tinha visibilidade sobre o prompt do sistema ou a configuração do agente.

A campanha Azure é uma operação distinta do mesmo ator, não uma repetição da intrusão de julho: tratava-se de exclusão e coleta de chaves, não de criptografia, e a Microsoft não encontrou nenhuma nota de resgate. O vínculo entre as duas baseia-se em parte na infraestrutura. A Cloud Security Alliance observou, em uma nota de pesquisa de 28 de setembro, que dois dos endereços IP listados pela Microsoft, 45.131.66[.]106 e 34.153.223[.]102, haviam aparecido nos relatórios de julho da Sysdig. A mesma nota alertou que a reutilização de IP por si só não pode descartar a hospedagem compartilhada de terceiros.

Estabelecido, avaliado e ainda em aberto

A mecânica da intrusão no Azure está bem documentada. A autonomia não está documentada no mesmo padrão, e a diferença é a qualificação mais importante neste registro.

Estabelecido pela telemetria da Microsoft: duas entidades de serviço comprometidas em um único locatário; mais de 300 operações de leitura bem-sucedidas ao longo de cerca de 15 horas e meia; mais de 100 tentativas de exclusão de conta de armazenamento, a maioria das quais bem-sucedida; a exclusão de um Key Vault, de um Function App e de um plano do App Service; exclusões de bancos de dados SQL que falharam todas devido a uma versão de API não suportada; contas de armazenamento salvas por bloqueios de recursos e proteção contra exclusão; mais de 30 solicitações ListKeys bem-sucedidas após a destruição; credenciais de entidade de serviço em texto simples em uma issue pública do GitHub e em seu histórico de edições; nenhuma nota de resgate observada; e nenhuma exfiltração confirmada.

Avaliado pela Microsoft: que a atividade pertence ao Storm-3168; que a combinação de exclusão, interferência na recuperação e coleta de chaves é consistente com ransomware e extorsão; que a execução provavelmente foi automatizada ou scriptada; e que as chaves coletadas poderiam subsidiar futura exfiltração. O relatório público da Microsoft não descreve um agente autônomo raciocinando pelas etapas específicas do Azure.

Em aberto: como os service principals foram comprometidos inicialmente; a identidade da vítima e o número de organizações afetadas; se algum dado saiu do tenant; e se um agente de IA, em vez de um script, dirigiu as próprias operações do Azure.

A Cloud Security Alliance expôs a lacuna probatória com precisão em sua nota de 28 de setembro: a caracterização de "agêntico", escreveu ela, atualmente se baseia "na precisão, no ritmo e na divisão do trabalho entre identidades", e não em traços capturados do raciocínio do agente. As evidências que a Sysdig usou em julho — payloads que se autodescrevem e um ciclo rápido de diagnosticar e corrigir — estão ausentes do registro público da campanha do Azure. Nick Tausek, da empresa de segurança Swimlane, disse à CSO Online que as evidências do Azure mostram "automação coordenada, em vez de provar que a IA dirigiu cada etapa".

A cobertura da divulgação usou o enquadramento mais forte. A manchete do BleepingComputer descreveu "ataques de IA agêntica" contra o Azure, e a do Dark Reading descreveu um "ator de IA" comprometendo um tenant do Azure; o próprio relatório da Microsoft afirma que o momento e a divisão do trabalho "indicam fortemente execução automatizada ou por script" e não atribui as etapas individuais no Azure a um agente.

O arquivo classifica este registro com confiança A e não o sinaliza como disputado. O rótulo de envolvimento de IA "confirmado" do registro depende da atribuição a JADEPUFFER, o ator que a Sysdig documentou como orientado por LLM; não é uma afirmação de que a Microsoft capturou o raciocínio de um agente durante as exclusões no Azure. O dano está estabelecido, a automação está estabelecida e a autonomia é inferida.

O que a Microsoft diz que deveria mudar

As recomendações da Microsoft têm caráter operacional e decorrem diretamente de como esta intrusão funcionou. Elas solicitam que as equipes de defesa habilitem os planos relevantes do Microsoft Defender for Cloud para Resource Manager, Storage, Key Vault, App Service e Bancos de Dados; mantenham credenciais de entidade de serviço, chaves de armazenamento, cadeias de conexão e outros segredos fora do código-fonte, da configuração, dos repositórios e dos problemas; usem o Microsoft Entra Workload ID em vez de segredos de longa duração; apliquem o privilégio mínimo e revisem as atribuições do RBAC do Azure para identidades de carga de trabalho; e restrinjam e monitorem os recursos de backup e recuperação, incluindo tentativas de alterar seus controles de proteção.

O relatório público da Microsoft não diz se o locatário restaurou os seus dados, se a vítima foi notificada ou se alguma das chaves recolhidas foi utilizada posteriormente. Esses resultados não constam do registo. O que o registo contém é um contraste mensurável: os bloqueios de recursos e a proteção contra exclusão impediram algumas exclusões mesmo contra identidades com amplos privilégios, enquanto as bases de dados SQL foram salvas por um erro de versão da API e não por uma decisão de um defensor. O relato da Microsoft não diz o que o locatário fez a seguir. Diz, sim, que o ator passou mais de 15 horas a ler antes de passar sete minutos a excluir.