Duas identidades roubadas na Azure e 18 horas: o ataque atribuído ao JADEPUFFER

A Microsoft divulgou a primeira análise detalhada da atividade do agente de ameaça JADEPUFFER dentro do Microsoft Azure: um ataque destrutivo, ocorrido no início de junho de 2026, em que dois service principals comprometidos do mesmo tenant foram usados para mapear o ambiente de nuvem da vítima, apagar dezenas de recursos críticos, atacar mecanismos de recuperação e recolher chaves de acesso a contas de armazenamento. O caso é relevante porque o mesmo operador foi identificado em julho de 2026 como responsável pela primeira operação de ransomware documentada como executada de ponta a ponta por um agente de inteligência artificial — e porque a cadeia de ataque não exigiu qualquer técnica nova: bastou uma credencial de aplicação válida com permissões excessivas.

O que a Microsoft observou dentro da Azure

A investigação foi publicada pela Microsoft Security Research a 25 de setembro de 2026. A empresa identificou atividade maliciosa em nuvem associada ao JADEPUFFER, agente descoberto pela Sysdig em julho de 2026 e descrito como a primeira operação de ransomware agêntica documentada, e a sua investigação encontrou destruição extensiva de recursos Azure através de service principals comprometidos, além da recolha de credenciais de nuvem que poderia facilitar exfiltração futura; a Microsoft segue o agente como Storm-3168 e considera estes dados a primeira visão detalhada da sua atividade na Azure.

As operações destrutivas foram viabilizadas pelo comprometimento de service principals e visaram contas de armazenamento (Azure Storage), bases de dados SQL, Key Vaults, Function Apps, locks de proteção de recuperação, máquinas virtuais e App Services. A Microsoft observou dois service principals comprometidos pertencentes ao mesmo tenant: um realizou reconhecimento e descoberta de recursos, o outro fez descoberta, operações destrutivas e recolha de credenciais.

No tenant afetado, no início de junho de 2026, uma das identidades comprometidas enumerou máquinas virtuais, subscrições, grupos de recursos e recursos durante cerca de 15 horas e 30 minutos, com mais de 300 operações de leitura bem sucedidas — dando ao atacante visibilidade transversal sobre o ambiente Azure da organização. Segundo o relato da investigação, ambos os service principals usaram infraestrutura ligada ao Storm-3168, a mesma impressão digital de rede e o user agent python-requests/2.34.2, e 16 horas depois a segunda identidade enumerou com sucesso repositórios de configuração de Azure App Service, possivelmente à procura de credenciais expostas, tendo também tentado sem êxito localizar recursos Azure OpenSearch.

A transição entre reconhecimento e destruição foi praticamente instantânea. De acordo com os relatos da análise da Microsoft, setenta segundos após a última chamada de inventário, a identidade tentou uma operação ListKey contra uma conta de armazenamento inexistente e, menos de um segundo depois, começaram as eliminações; ao longo de 35 minutos foram tentadas mais de 150 operações destrutivas ou de recolha de credenciais, com a parte destrutiva a durar cerca de sete minutos e a incluir mais de 100 tentativas de eliminação de contas de armazenamento. A maioria das contas de armazenamento visadas foi efetivamente apagada, tendo o atacante eliminado também um Key Vault, uma Function App e um plano de App Service associados ao mesmo grupo de recursos. A mesma identidade fez depois mais de 30 pedidos ListKeys bem sucedidos contra contas de armazenamento, recolhendo chaves de acesso após a atividade destrutiva.

Um detalhe merece atenção especial das equipas de desenvolvimento: a Microsoft referiu que credenciais expostas tinham surgido anteriormente numa issue pública do GitHub e que editar essa issue não invalidou o segredo — o que ilustra por que razão credenciais expostas têm de ser revogadas e não apenas removidas do texto visível. Não foi observada nota de resgate nem exfiltração de dados bem sucedida associada à intrusão, embora a eliminação de recursos de backup e recuperação sugira a intenção de degradar a capacidade de recuperação da vítima.

Cronologia: do CVE de 2025 ao relatório da Microsoft

Ataque “agêntico” ou apenas script bem feito?

A Microsoft intitulou o relatório como atividade de nuvem “conduzida de forma agêntica”, mas as provas apresentadas são de natureza comportamental. A empresa explica que o encadeamento temporal das operações, a divisão de trabalho entre vários service principals e os fluxos de tokens sobrepostos da mesma identidade indicam fortemente execução automatizada ou por script. A identidade destrutiva usou cinco tokens distintos — quatro para eliminação e um para inventário e obtenção de chaves de armazenamento — com dois dos tokens de eliminação ativos em simultâneo durante 70 segundos.

Vale a pena registar a leitura crítica que tem sido feita destes indícios: automação de alta velocidade e paralelismo de tokens são compatíveis com um agente autónomo, mas também com um script Python bem construído, pelo que a atribuição de controlo a um modelo de linguagem não é diretamente demonstrada pelos registos de atividade. A Microsoft enquadra o caso na tendência mais ampla de ataques orquestrados por IA, em que os atacantes conseguem coordenar operações complexas de pós-comprometimento em ambientes de nuvem com maior velocidade e escala. Para quem defende, a distinção é menos importante do que a consequência: a janela entre descoberta e destruição passou a medir-se em segundos.

Quem é o JADEPUFFER e como tudo começou no Langflow

A Sysdig Threat Research Team descreveu, a 1 de julho de 2026, o que avalia como o primeiro caso documentado de ransomware agêntico: uma operação de extorsão conduzida de ponta a ponta por um modelo de linguagem, batizada JADEPUFFER, que obteve acesso inicial a uma instância Langflow exposta na Internet através do CVE-2025-3248 e correu uma campanha adaptativa e totalmente automatizada, acabando por executar um playbook destrutivo de extorsão contra o servidor de base de dados de produção da vítima. Nessa operação foram cifrados 1342 itens de configuração do Nacos, com eliminação dos originais, e a Sysdig registou uma sequência em que o agente passou de um login falhado a uma correção funcional em 31 segundos.

A vulnerabilidade de entrada continua a ser um dos pontos fracos mais explorados do ecossistema de IA. O CVE-2025-3248 afeta versões do Langflow anteriores à 1.3.0, através do endpoint /api/v1/validate/code, tem uma pontuação CVSS de 9,8 em 10 e consta também do catálogo europeu de vulnerabilidades exploradas da ENISA (EUVD-2025-10011, adicionado a 5 de maio de 2025). Instâncias Langflow são alvos atrativos porque tendem a estar expostas na Internet e a guardar chaves de API e credenciais de nuvem dos serviços a que se ligam.

Semanas depois, o mesmo operador voltou. A Sysdig documentou a 20 de julho o regresso à mesma instância Langflow com o ENCFORGE, um binário de ransomware em Go empacotado com UPX que visa cerca de 180 extensões de ficheiro do stack moderno de machine learning, incluindo checkpoints de modelos (.gguf, .safetensors, .ckpt, .pt), bases de dados vetoriais (.faiss) e conjuntos de treino (.parquet, .tfrecord, .npy), com cifra AES-256-CTR e encapsulamento de chave RSA-2048. A atribuição baseou-se no contacto de extorsão embutido no binário, coincidente com o endereço divulgado no relatório anterior.

Indicadores e dados técnicos a pesquisar

Mitigação: o que fazer esta semana

• Inventariar todos os service principals e identidades de aplicação do tenant, identificando quais têm papéis Owner ou Contributor a nível de subscrição e reduzindo-os ao mínimo privilégio necessário.
• Substituir segredos de cliente de longa duração por federação de identidade de carga de trabalho ou certificados com rotação curta e prazos de validade reduzidos.
• Tratar qualquer segredo que tenha aparecido em repositórios, issues, logs ou pipelines públicos como comprometido: revogar e emitir novo, sem confiar na edição do conteúdo visível.
• Proteger a capacidade de recuperação com locks de recurso, soft delete e proteção contra purga em contas de armazenamento e Key Vaults, e manter cópias imutáveis fora do alcance das mesmas credenciais.
• Criar deteções sobre os registos de atividade da nuvem para eliminações em massa, remoção de locks, chamadas ListKeys anómalas e uso de tokens em paralelo pela mesma identidade.
• Atualizar o Langflow para a versão 1.3.0 ou superior, retirar da Internet consolas de desenvolvimento de agentes de IA e colocá-las atrás de autenticação e segmentação de rede.
• Preparar resposta a incidentes para contenção simultânea de vários planos (identidade, nuvem, CI/CD), porque isolar apenas um permite ao atacante reativar acessos noutro.

Porque é que isto importa para organizações em Portugal

O padrão deste incidente é dolorosamente comum no tecido empresarial português: uma aplicação com credenciais permanentes, permissões herdadas de um projeto antigo e um segredo que passou por um repositório. Em qualquer PME que use nuvem pública, a diferença entre um susto e uma paragem de dias está na existência de cópias de segurança que não possam ser apagadas com as mesmas chaves que operam o ambiente.

No plano legal, a gestão de identidades de aplicação e a resiliência das cópias de segurança deixaram de ser boas práticas opcionais para muitas entidades. Com o Regime Jurídico da Ciberseguranca (Decreto-Lei n.º 125/2025, que transpõe a NIS2), as entidades abrangidas têm de demonstrar medidas de gestão de riscos que incluem controlo de acessos, continuidade de negócio e notificação de incidentes significativos ao CNCS, apoiando-se no CERT.PT para coordenação técnica. Uma eliminação massiva de recursos de nuvem com impacto operacional entra facilmente nesse perímetro de notificação.

Há ainda a dimensão de proteção de dados: mesmo sem exfiltração confirmada, a destruição de dados pessoais é uma violação de segurança nos termos do RGPD, por perda de disponibilidade e integridade, com possível obrigação de notificação à CNPD no prazo de 72 horas. Neste caso concreto, a ausência de nota de resgate e de exfiltração observada não elimina o impacto — apenas muda a natureza do dano: em vez de chantagem, perda irreversível.

Perguntas frequentes

O que é um service principal e porque é tão perigoso quando é roubado?

É a identidade que uma aplicação ou automatismo usa para atuar na nuvem, sem intervenção humana. Se tiver permissões amplas, quem obtiver o seu segredo pode enumerar e apagar recursos à velocidade da API, como aconteceu neste caso, em que mais de 100 tentativas de eliminação de contas de armazenamento ocorreram numa janela de minutos.

O JADEPUFFER e o Storm-3168 são o mesmo agente de ameaça?

Sim, são designações diferentes para a mesma atividade: JADEPUFFER é o nome atribuído pela Sysdig em julho de 2026 e Storm-3168 é a designação temporária usada pela Microsoft, que associa a atividade Azure observada ao mesmo operador.

Foi confirmado que o ataque foi conduzido por inteligência artificial?

A Microsoft indica que o encadeamento temporal, a divisão de tarefas entre identidades e os fluxos de tokens sobrepostos apontam fortemente para execução automatizada ou por script, e enquadra o caso na tendência de ataques orquestrados por IA. Os registos, por si, não provam qual o motor de decisão.

A minha organização usa Langflow. Qual é a ação prioritária?

Atualizar para a versão 1.3.0 ou superior, remover a exposição direta à Internet e rodar todas as chaves de API e credenciais de nuvem que a instância tivesse configuradas, assumindo que podem ter sido recolhidas.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft Security Research, pela Sysdig Threat Research Team, pela CISA e pela ENISA.