Sete minutos para apagar a sua cloud: o que a Microsoft viu no ataque JadePuffer

A Microsoft divulgou a primeira análise detalhada da atividade em Azure atribuída ao JADEPUFFER, o ator de ameaça apresentado em julho como a primeira operação de ransomware conduzida de ponta a ponta com apoio de um modelo de linguagem. Segundo a investigação publicada a 25 de setembro de 2026, duas identidades de aplicação (service principals) comprometidas no mesmo tenant foram usadas para mapear todo o ambiente, apagar mais de uma centena de contas de armazenamento e recolher chaves de acesso — com um período destrutivo concentrado em cerca de sete minutos. Não foi observada nota de resgate nem exfiltração confirmada, mas o padrão operacional é compatível com extorsão.

Quem é o JADEPUFFER e porque é que o caso é diferente

A Microsoft Security Research identificou atividade maliciosa em cloud associada ao JADEPUFFER, ator descoberto pela Sysdig em julho de 2026 e descrito como a primeira operação de ransomware agêntica documentada, tendo encontrado uma extensa atividade de destruição de recursos em Azure com recurso a service principals comprometidos e recolha de credenciais de cloud que poderia facilitar exfiltração futura; estes dados alargam o que era publicamente conhecido sobre o ator, que a empresa rastreia como Storm-3168, e constituem a primeira visão detalhada da sua atividade em Azure.

A génese do caso está na investigação da Sysdig. A equipa de investigação de ameaças documentou a 1 de julho de 2026 um “ator de ameaça agêntico” que explorou o Langflow através da CVE-2025-3248 e, depois de entrar, encadeou autonomamente reconhecimento, recolha de credenciais, movimento lateral e um manual de extorsão destrutiva contra um MySQL e um servidor Alibaba Nacos a jusante — com a tese de operação autónoma sustentada em sinais comportamentais concretos, como cargas que narravam as próprias ações e ciclos de diagnóstico e correção de falhas em 31 segundos. Após a publicação da investigação inicial, o ator regressou à mesma instância Langflow com capacidade materialmente reforçada: em vez de scripts Python improvisados e da função AES_ENCRYPT() do MySQL, passou a preparar o ENCFORGE, um ransomware em Go compilado e empacotado com UPX orientado a infraestrutura de inteligência artificial e machine learning.

A porta de entrada mantém-se conhecida. O Langflow é uma framework open source amplamente usada para construir aplicações baseadas em LLM e a CVE-2025-3248 é uma falha de autenticação ausente no endpoint /api/v1/validate/code que permite a um atacante não autenticado executar código Python arbitrário no host, tendo entrado no catálogo de vulnerabilidades exploradas conhecidas da CISA em maio de 2025. A falha afeta versões anteriores à 1.3.0 e tem CVSS 9.8.

Cronologia: 15 horas de reconhecimento, sete minutos de destruição

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, um dos service principals 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, o que daria ao atacante visibilidade sobre todo o ambiente Azure da organização.

A Microsoft indica que o ator apagou a maioria das contas de armazenamento visadas e eliminou também um Azure Key Vault, uma Function App e um plano de App Service associados ao mesmo grupo de recursos. Durante a sequência destrutiva foram tentadas eliminações paralelas de bases de dados Azure SQL e a remoção de bloqueios de proteção do Azure Site Recovery e do Azure Backup, tendo as tentativas em SQL falhado. A causa apontada para essas falhas foi uma versão de API não suportada. Algumas contas de armazenamento sobreviveram devido a bloqueios de recursos Azure.

Indicadores e sinais de automação

Ambos os service principals comunicaram através de infraestrutura ligada ao Storm-3168 e usaram o user agent python-requests/2.34.2. Foram observados cinco tokens para o service principal responsável pela eliminação e recolha de credenciais, quatro usados em atividade destrutiva e um quinto na enumeração de armazenamento e obtenção de chaves. A Microsoft avaliou que o uso paralelo de identidades e tokens indicava execução automatizada ou por script, e recomendou às organizações que rodem credenciais expostas.

A Microsoft referiu ainda que, desde o início do ano, infraestrutura ligada ao JadePuffer tem sondado vários Azure App Services de diferentes clientes, aparentando testar formas de infiltração em ambientes de cloud. Há, no entanto, prudência analítica sobre o grau de autonomia neste episódio concreto: Nick Tausek, arquiteto de automação de segurança da Swimlane, afirmou concordar com o alerta da Microsoft sobre ataques orquestrados por IA, mas considerou que as provas em Azure mostram automação coordenada, sem provarem que a IA dirigiu cada passo.

Como entraram? A hipótese do segredo publicado por engano

O acesso inicial não foi confirmado: o client ID, o segredo e o tenant ID de um dos service principals comprometidos tinham estado publicamente expostos numa issue do GitHub, mas a Microsoft não conseguiu verificar que tenha sido esse o vetor da intrusão. A empresa também não observou nota de resgate nem confirmou exfiltração de dados bem-sucedida. A avaliação é de que o objetivo final estaria alinhado com ransomware, dada a eliminação de numerosos recursos Azure e de recursos ligados a backup e recuperação, o que sugere intenção de limitar a capacidade de recuperação da vítima.

Mitigações concretas para quem opera Azure

A Microsoft recomenda ativar proteções de cargas de trabalho em cloud, verificar repositórios públicos à procura de segredos expostos e avaliar as permissões de Azure RBAC face ao princípio do privilégio mínimo, uma vez que os ataques dependeram de credenciais de service principals comprometidas e de acesso excessivo a armazenamento, Key Vaults e recursos de computação. A orientação de RBAC da Microsoft aponta para limitar tanto as ações permitidas como o seu âmbito, evitar funções desnecessariamente amplas e usar permissões explícitas em vez de wildcards em funções personalizadas.

• Inventarie identidades de aplicação e trate-as com o mesmo rigor de contas privilegiadas humanas — um service principal é a identidade de uma aplicação no tenant Microsoft Entra da organização, permite que software se autentique e use recursos sem se fazer passar por um colaborador, e as suas permissões merecem o mesmo escrutínio que uma conta privilegiada de uma pessoa.
• Procure segredos de cliente em repositórios, issues, wikis, logs de pipelines e ficheiros de configuração — inclusive no histórico de edições — e trate qualquer exposição pública como comprometimento, rodando ou revogando a credencial e revendo como foi usada.
• Identifique atribuições amplas de Contributor em identidades de carga de trabalho.
• Aplique bloqueios de recursos (resource locks) e imutabilidade em armazenamento crítico e cofres de backup: neste incidente, foram esses controlos que salvaram parte dos dados.
• Alerte para padrões anómalos de API: enumerações massivas em segundos, chamadas ListKeys em série e eliminações em paralelo a partir de múltiplos tokens da mesma identidade.
• Atualize o Langflow para uma versão suportada atual e retire da internet interfaces de desenvolvimento de agentes que não precisem de exposição pública.

Porque é que isto importa em Portugal

Muitas PME e organizações portuguesas concentram em Azure não só aplicações, mas também as suas cópias de segurança. Um incidente deste tipo — eliminação de storage, cofres de chaves e controlos de recuperação em poucos minutos — traduz-se em indisponibilidade prolongada e, potencialmente, em perda definitiva de dados pessoais, com implicações ao nível do RGPD, que exige capacidade de restabelecer a disponibilidade e o acesso aos dados de forma atempada.

No plano regulatório, o quadro nacional mudou: a 4 de dezembro de 2025 foi publicado o Decreto-Lei n.º 125/2025, que aprova o novo Regime Jurídico da Cibersegurança e transpõe a Diretiva (UE) 2022/2555 (NIS2), sendo que para o concretizar foi publicado o Regulamento do Regime Jurídico da Cibersegurança (Regulamento n.º 756/2026, de 22 de junho), disponibilizado pelo Centro Nacional de Cibersegurança. Entre as novidades estão obrigações de registo, identificação das entidades abrangidas, comunicação de incidentes e implementação de medidas mínimas de segurança, começando o percurso pelo registo na plataforma MyCiber. O diploma reforça exigências de governação, gestão de risco, medidas técnicas e organizacionais e reporte de incidentes.

Para entidades abrangidas, a mensagem prática é dupla. Primeiro, a gestão de identidades não humanas — chaves de API, segredos de clientes, identidades de automação — deixou de ser um detalhe técnico para passar a ser um controlo central de resiliência. Segundo, o tempo de reação encurtou: quando a fase destrutiva cabe em sete minutos, a deteção tem de ser automática e as cópias de segurança têm de estar fora do alcance das mesmas credenciais que gerem a produção.

Perguntas frequentes

O que é um service principal e porque é tão apetecível para atacantes?

É a identidade de uma aplicação ou automação dentro do tenant Microsoft Entra, usada para autenticar software sem credenciais humanas. Como costuma ter permissões amplas e não estar sujeita a autenticação multifator interativa, uma credencial exposta pode autorizar operações destrutivas em larga escala.

Este ataque foi realmente conduzido por inteligência artificial?

A Microsoft associa a atividade ao JADEPUFFER, descrito pela Sysdig como a primeira operação de ransomware agêntica documentada, e avalia que o uso paralelo de identidades e tokens aponta para execução automatizada. Há, contudo, especialistas a sublinhar que as provas em Azure demonstram automação coordenada sem confirmar que um modelo dirigiu cada passo.

A minha organização foi afetada? Como verificar?

Reveja os registos de atividade de Azure à procura de enumerações massivas, chamadas ListKeys em série, eliminações de contas de armazenamento e remoções de bloqueios de recuperação, cruzando com o user agent python-requests. Verifique também se algum segredo de service principal foi publicado em repositórios, issues ou logs públicos.

Que medidas dão mais resiliência a curto prazo?

Rotação e revogação de segredos expostos, redução de funções amplas como Contributor em identidades de automação, bloqueios de recursos e imutabilidade em armazenamento e backups, ativação de proteções de cargas de trabalho em cloud e atualização de componentes expostos à internet, como instâncias Langflow afetadas pela CVE-2025-3248.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft Security Research, pela Sysdig Threat Research Team, pelo CNCS e por investigadores citados na imprensa especializada.