PENTESTY · ANÁLISE EDITORIAL · · 4 min de leitura
JadePuffer no Azure: quem pode apagar o que mantém a recuperação?
Uma cópia só ajuda quando a empresa consegue preservá-la e utilizá-la. Relacione o poder de excluir recursos com os acessos necessários para recuperar o serviço.
Por Pentesty
O que a investigação publicada confirma
Em 25 de setembro de 2026, a Microsoft descreveu atividade no Azure associada ao JadePuffer, rastreado como Storm-3168, usando dois service principals comprometidos. A investigação observou exclusões de recursos e coleta de credenciais; alguns controles impediram exclusões. A origem inicial do comprometimento permaneceu incerta. O relato não confirmou exfiltração bem-sucedida nem nota de resgate. A análise abaixo propõe testes de autorização, sem reconstruir o ambiente da vítima.
Faça o inventário do poder de excluir
Escolha uma aplicação e relacione suas identidades aos recursos utilizados. Para cada permissão de exclusão, registre a finalidade, o responsável e o caminho pelo qual foi concedida. Inclua grupos e escopos herdados: o nome de uma conta de aplicação não informa sozinho seu alcance efetivo.
Compare esse alcance com a tarefa de negócio. Uma automação que publica uma versão precisa apagar todo o armazenamento do projeto? Quem pode autorizar uma limpeza permanente? A revisão deve diferenciar a manutenção esperada de uma capacidade que permaneceu disponível apenas por conveniência ou por uma exceção sem revisão.
Trate a recuperação como uma relação de confiança própria
Mapeie quem administra as cópias, quem altera suas proteções e quem pode recuperá-las. Depois compare essas funções com as identidades que operam a aplicação. Se um único acesso alcança operação e recuperação, documente o alcance e a decisão de controle necessária, em vez de presumir independência porque os recursos têm nomes diferentes.
Defina o que cada proteção pretende impedir. Um bloqueio de recurso precisa ser avaliado pela operação concreta que cobre; ele não demonstra, isoladamente, proteção de todo o conteúdo ou de todas as dependências. Mantenha a configuração aplicada, os responsáveis por alterá-la e a forma de verificar seu efeito.
Demonstre a recusa antes de discutir a restauração
Use um ambiente isolado, recursos descartáveis e dados sintéticos. Combine uma operação legítima que deve funcionar e uma exclusão que a identidade de teste não deveria realizar. Registre a hipótese e os limites antes da execução, sem apagar dados reais nem remover proteções da produção para demonstrar o risco.
Compare a autorização declarada com a resposta observada e o estado do recurso. Uma operação recusada e outra que falha por erro de versão da API não comprovam o mesmo controle. Quando o resultado for inconclusivo, preserve a limitação e defina a próxima verificação, sem contar a falha como sucesso da proteção.
- Identifique a identidade, o escopo e a origem da permissão.
- Registre a ação permitida e a exclusão que deve ser negada.
- Preserve resposta, horário e estado final sem incluir segredos.
- Defina quem aceita o resultado e encerra o acesso do exercício.
Verifique se a cópia permite retomar a função
Depois avalie uma restauração autorizada com material sintético. Escolha uma função pequena da aplicação e confirme dados, configuração e acessos necessários para executá-la. O anúncio de um backup concluído não mostra sozinho que outra equipe consegue obter a cópia e operar o serviço recuperado.
A análise sobre perda de uma zona de nuvem ajuda a testar dependências e aceitação operacional. Neste cenário, acrescente uma pergunta: o caminho de recuperação continua disponível quando a identidade da aplicação é revogada? Documente a resposta observada e qualquer dependência ainda compartilhada.
Conecte o ciclo das credenciais à decisão de encerramento
Relacione cada credencial às integrações que precisam ser alteradas quando seu uso termina. A revisão de segredos no GitHub Actions complementa esse inventário. Uma remoção de conteúdo e uma revogação são ações diferentes; a entrega deve mostrar qual delas ocorreu e como seu efeito foi verificado.
Encerre com responsáveis por corrigir permissões, revisar proteções e aceitar a recuperação. Repita o cenário após mudanças relevantes e preserve as condições do teste. O resultado útil é uma decisão sobre o alcance observado, sem extrapolar a amostra para todos os recursos da assinatura.
Perguntas frequentes
A Microsoft confirmou a credencial pública como entrada inicial?
O relato informa exposição anterior, mas não confirma que aquele segredo foi usado na atividade descrita. Preserve essa incerteza ao explicar o caso.
Uma exclusão que falhou prova que a proteção funcionou?
Verifique a causa e o estado final. Uma recusa por autorização e uma falha por requisição incompatível são evidências diferentes e sustentam conclusões distintas.
Ter backup demonstra capacidade de recuperação?
Teste a restauração da função escolhida, com dados sintéticos e acesso autorizado. Registre dependências, permissões, limitações e quem aceitou o resultado observado.
Qual é o primeiro passo para a equipe responsável?
Escolha uma aplicação e relacione identidades, recursos e permissões de exclusão. Defina a operação legítima, a recusa esperada e os responsáveis pela recuperação.
Fontes e referências
- Microsoft: investigação Storm-3168, 25 de setembro de 2026
- Microsoft Learn: bloqueio de recursos de uma conta de armazenamento
- Microsoft Learn: boas práticas de proteção do Azure Backup
- Cyber Security Brazil: referência editorial da notícia
Análise original da Pentesty, publicada em 16 de outubro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.