Bucket hijacking desvia logs da nuvem sem acionar alerta

Pesquisadores da Unit 42, da Palo Alto Networks, revelaram em 22 de junho de 2026 uma nova técnica chamada bucket hijacking, que desvia silenciosamente logs de auditoria e dados sensíveis de fluxos na nuvem para buckets controlados por atacantes. A falha arquitetural afeta AWS, Google Cloud e Microsoft Azure e não dispara alertas nativos.

Como o ataque funciona

A técnica explora um princípio fundamental do armazenamento em nuvem: os nomes dos buckets são globalmente únicos. Dentro do namespace de cada provedor, nenhum usuário pode registrar um nome idêntico ao de outro. A identidade do destino de um fluxo de dados fica vinculada apenas ao nome do bucket, e não à conta que o possui. É essa característica que sustenta a descoberta.

Após comprometer um ambiente de nuvem e obter permissões de exclusão de bucket, um atacante executa o golpe em três passos. Primeiro, exclui o bucket de armazenamento ativo da organização-alvo. Em seguida, recria imediatamente um novo bucket com o nome idêntico dentro de uma conta própria. Por fim, o fluxo de dados original — um sink de registros no Google Cloud, uma regra de replicação no S3 da AWS ou uma exportação de diagnóstico do Azure Monitor — continua operando de forma autônoma e passa a gravar os dados diretamente no bucket do atacante.

O pesquisador Yahav Festinger, da Unit 42, descreveu o vetor como um risco de namespace global. A pesquisa foi compartilhada com Google Cloud, Amazon Web Services e Microsoft Azure por meio de divulgação responsável.

Por que é silencioso

O ataque é autossustentável. Uma vez concluído o sequestro, a configuração legítima do sink ou da replicação continua válida sob inspeção, não gera estados de erro e não aciona alertas nativos. Logs, métricas e telemetria sensível fluem de forma oculta para o ambiente do atacante por tempo indeterminado.

O perigo maior incide sobre a integridade investigativa. Logs de segurança e auditoria são a principal ferramenta das equipes de resposta a incidentes. Um atacante que desvia esses registros antes da descoberta de uma invasão pode apagar o rastro de evidências. A equipe abre o console de registros, tudo parece normal, os logs aparentam fluir — mas o atacante os lê primeiro. Para setores regulados, como bancos, saúde e infraestrutura crítica, a consequência extrapola o roubo de dados e compromete provas de conformidade.

Serviços afetados nas nuvens

A Unit 42 simulou o bucket hijacking em vários serviços dos três principais provedores. A tabela resume os fluxos confirmados e as permissões exigidas:

Os pesquisadores destacaram uma falha de permissão preocupante no Google Cloud: o papel padrão de Storage Admin concede storage.buckets.delete por padrão, contornando a permissão mais restritiva logging.sinks.update, que seria a exigida para reconfigurar um fluxo de dados de forma legítima. Isso permite que atacantes redirecionem fluxos sem sequer tocar nas configurações do stream. Na AWS, o ataque foi confirmado em replicação de buckets S3 e em pipelines do Amazon Data Firehose; no Azure, foi demonstrado como invasão entre assinaturas, ainda limitada ao escopo do mesmo locatário por atrasos impostos pela plataforma na reutilização de nomes.

Cronologia da descoberta

Embora nenhum ator de ameaça real tenha sido observado explorando a técnica até o fechamento desta reportagem, os pesquisadores alertam que a detecção seria extremamente difícil após a implantação. A linha do tempo da divulgação:

• 22 de junho de 2026 — a Unit 42 publica a pesquisa detalhando o bucket hijacking nos três principais provedores de nuvem.
• 22 de junho de 2026 — divulgação responsável concluída com Google Cloud, AWS e Microsoft Azure.
• 27 de junho de 2026 — cobertura ampla pela imprensa especializada, incluindo análise técnica dos serviços e permissões afetados.

A pesquisa reforça que filosofias de projeto compartilhadas entre provedores significam que uma falha descoberta em um ecossistema pode servir de modelo direto para explorar outro — um alerta central para equipes que administram ambientes multi-nuvem.

Como se proteger agora

A Unit 42 recomenda uma defesa em duas frentes, combinando controle de acesso de menor privilégio e monitoramento proativo. As organizações devem restringir permissões de exclusão — storage.buckets.delete no Google Cloud, DeleteBucket na AWS e Microsoft.Storage/storageAccounts/delete no Azure — aos papéis administrativos mínimos necessários, e nunca como padrão em perfis amplos.

Controles de perímetro de dados, como as Service Control Policies (SCPs) da AWS e os VPC Service Controls do Google Cloud, conseguem bloquear gravações em buckets fora do limite organizacional confiável. A ativação de namespaces S3 regionais por conta, na AWS, delimita nomes de bucket a contas e regiões específicas e elimina diretamente o vetor do ataque. Alertas de monitoramento de alta prioridade para chamadas de API de exclusão de bucket, sobretudo em buckets com dados sensíveis ou regulados, completam a postura defensiva.

A técnica não se restringe aos três provedores testados. Qualquer plataforma de nuvem que dependa de recursos de armazenamento com nomes globalmente únicos e estáticos para o roteamento de fluxos de dados pode ser vulnerável à mesma metodologia, o que torna a revisão de permissões de exclusão uma prioridade imediata para administradores multi-nuvem.

Leia também: a plataforma Prisma Cloud para postura de segurança na nuvem e lições de defesa digital após o vazamento de chaves da CISA no GitHub no ciberseguranca.org.

Fontes

• Unit 42 (Palo Alto Networks) — The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration
• Cyber Security News — New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage
• The420.in — Bucket Hijacking Attack Can Reroute Cloud Audit Logs Without Triggering Any Alert