Sete minutos entre o primeiro comando e o tenant vazio

Há duas maneiras de ler esse relatório. A primeira é a leitura de manchete, e ela já circulou bastante: inteligência artificial agora apaga ambiente de nuvem sozinha. É verdadeira e não serve para muita coisa.

A segunda leitura está na cronologia, e essa muda o que um time de segurança faz na segunda-feira.

O que denuncia a automação

A Microsoft não afirma qual modelo ou arcabouço foi usado. O que ela apresenta é a evidência de comportamento, e o padrão é específico.

Entre a última operação de leitura e o primeiro comando de exclusão passou menos de um segundo. Um operador humano, depois de quinze horas de mapeamento, precisa de algum tempo para decidir por onde começar. Aqui não houve intervalo de decisão, porque a decisão já estava codificada na cadeia.

Foram emitidos cinco tokens distintos, e dois deles estiveram ativos simultaneamente em uma janela de setenta segundos, cada um trabalhando sobre um tipo diferente de recurso. É paralelismo, não multitarefa humana. As operações também respeitaram com precisão os limites de permissão atribuídos a cada identidade, o que indica que o agente leu o que podia fazer antes de tentar fazer.

E houve poda. Uma conta de armazenamento com nome parecido, dentro do mesmo grupo de recursos, foi deliberadamente poupada da exclusão e depois visitada para extração de chave. Alguém, ou alguma coisa, distinguiu entre destruir e manter útil.

A porta de entrada era um comentário apagado

Os service principals usados no ataque pertenciam ao próprio tenant. Não houve exploração de vulnerabilidade, contorno de autenticação ou phishing. Havia uma credencial de aplicação, com identificador de cliente, segredo e identificador de tenant, publicada em texto claro em uma issue pública do GitHub por um funcionário.

O comentário foi apagado depois. O segredo continuou acessível pelo histórico de edição, que o GitHub preserva e serve.

Esse detalhe merece ficar. Boa parte dos procedimentos internos de resposta a vazamento de segredo em repositório termina na frase "removemos o comentário". Remover não rotaciona. E enquanto a credencial não é revogada, ela continua sendo uma credencial válida, publicada, indexada e recuperável.

A cronologia

Momento	O que aconteceu
Início de junho	Primeiro service principal inicia o reconhecimento: 15,5 horas e mais de 300 operações de leitura sobre assinaturas, máquinas virtuais e grupos de recursos.
90 minutos depois do início	O segundo service principal entra em operação, em paralelo.
16 horas depois	Enumeração das configurações de App Service.
Menos de 1 segundo depois	Começa a fase destrutiva.
16 de junho, 7 minutos	Mais de cem tentativas de exclusão de contas de armazenamento. Ao longo de 35 minutos, mais de 150 operações destrutivas, atingindo também Key Vault, Function App e plano de App Service.
Cerca de 30 minutos depois	Mais de 30 requisições ListKeys bem-sucedidas, coletando chaves de armazenamento.

O que segurou

Essa é a parte que vale mais do que o resto do relatório.

Os bloqueios de recurso do Azure impediram a exclusão de parte das contas de armazenamento. A proteção contra exclusão configurada no nível da conta barrou outras tentativas. Os bloqueios do Site Recovery e do Azure Backup resistiram à tentativa de adulteração. E as exclusões de banco SQL falharam por um motivo quase cômico: o agente usou uma versão de API que não suportava a operação.

Nenhum desses controles é sofisticado. Todos eles são configuração feita em algum momento anterior, por alguém que provavelmente nunca imaginou esse cenário. É o argumento mais forte que já apareceu a favor de bloqueio de recurso como controle padrão, e não como exceção pedida em chamado.

Vale notar o contraste com a versão anterior do mesmo grupo. Na campanha documentada pela Sysdig em julho, o agente entrava por falha conhecida no Langflow, colhia credencial, cifrava 1.342 configurações do Nacos com AES e deixava pedido de resgate. A chave foi gerada, impressa na saída padrão e nunca guardada nem transmitida. Quem pagasse não teria como recuperar nada. Agora o mesmo grupo aparece dentro de um tenant legítimo, usando identidade de aplicação da própria casa. A técnica de entrada mudou. A cadência automatizada, não.

O que muda para quem opera no Brasil

• Identidade de carga de trabalho não tem dono. Service principal, conta de serviço e chave de aplicação costumam ser criados por um time de desenvolvimento e nunca revisados. Não há RH para desligá-los, não há gestor para revalidar acesso e raramente há expiração.
• A janela de destruição é menor que a de resposta. Sete minutos para cem exclusões. Nenhum processo de plantão que dependa de acionamento humano chega a tempo. O que chega a tempo é o controle que já estava configurado.
• Backup dentro do mesmo tenant é alvo, não refúgio. O agente tentou adulterar os bloqueios de recuperação antes de apagar o resto. Cópia imutável, em assinatura separada e com credencial distinta, deixa de ser recomendação de boa prática e vira requisito.
• O vazamento de segredo precisa de procedimento com rotação. Achou credencial em repositório público, rotaciona. Apagar o comentário não resolve, e o histórico de edição continua servindo o valor original.
• Há leitura de LGPD aqui. Mais de trinta chaves de armazenamento foram coletadas depois da destruição. Se havia dado pessoal nessas contas, o incidente não é só de disponibilidade. É de confidencialidade, com dever de comunicação.

Leitura LATAMSEC

Três perguntas, na ordem em que fazem diferença.

Para quem opera a nuvem: quantas identidades de aplicação existem no tenant, quais têm permissão de exclusão sobre recurso de produção e quando cada segredo foi rotacionado pela última vez? A terceira pergunta costuma não ter resposta, e é a que importa.

Para o time de resposta: se cem recursos começarem a ser apagados agora, o que existe para conter isso sem depender de alguém acordar? Bloqueio de recurso, proteção contra exclusão e assinatura separada para backup são respostas que funcionam sem plantão. Alerta que chega no celular às três da manhã, não.

Para o comitê de risco: a organização consegue reconstruir o ambiente se o tenant inteiro for perdido em uma madrugada? A pergunta não é sobre agente de IA. É sobre a premissa, quase sempre implícita, de que a destruição seria gradual o suficiente para alguém reagir. Esse relatório retira essa premissa da mesa.