10 mil chaves AWS expostas: 242 permitiam acesso de administrador
Uma investigação da Truffle Security revelou a exposição pública de 10.616 chaves de acesso da Amazon Web Services (AWS) que ainda estavam ativas e válidas. O levantamento considerou materiais publicados entre agosto de 2022 e agosto de 2026 e foi divulgado em 19 de agosto de 2026.
O caso chama atenção porque parte dessas credenciais estava associada a ambientes corporativos. Ao todo, 817 chaves pertenciam a empresas, incluindo 526 credenciais do tipo root. Além disso, 242 chaves estavam ligadas a usuários do AWS Identity and Access Management (IAM) com a política AdministratorAccess, capaz de conceder controle praticamente irrestrito sobre os recursos de uma conta.
Na prática, uma credencial desse tipo pode permitir que um invasor crie, altere, consulte ou apague serviços, servidores, bancos de dados, aplicações e arquivos armazenados na nuvem. A Truffle Security afirmou que 768 das chaves analisadas nos dois grupos apresentavam potencial para oferecer controle total sobre a conta AWS correspondente.
Hugging Face aparece como principal origem dos vazamentos
A plataforma Hugging Face, utilizada por desenvolvedores para compartilhar modelos e projetos de inteligência artificial, foi identificada como a maior fonte individual de exposição. Segundo o relatório, 8.482 vazamentos únicos de chaves AWS foram encontrados em conteúdos publicados no serviço.
A análise mais ampla localizou 431.875 segredos relacionados à AWS em diferentes tipos de material técnico. Entre os locais estavam repositórios de código, históricos do Git, conjuntos de dados, imagens Docker, registros de sistemas e logs de pipelines de integração contínua.
Depois da eliminação de cópias repetidas, os pesquisadores chegaram a 64.024 chaves exclusivas, vinculadas a 50.654 contas AWS. O resultado evidencia que o problema não está restrito a um único projeto ou equipe: credenciais podem permanecer espalhadas em ambientes de desenvolvimento, arquivos de teste, ferramentas de colaboração e sistemas automatizados.
Credenciais antigas ampliam o risco
Outro ponto crítico foi a idade das chaves. Entre 2.903 credenciais que possuíam informações sobre a data de criação, a média chegou a 1.831 dias, aproximadamente cinco anos. A chave mais antiga tinha 17,4 anos.
Apenas 398 registros, equivalentes a 13,7% da amostra, apresentavam uma chave de acesso mais recente associada ao mesmo usuário. Esse indicador sugere que a maioria das credenciais não passou por rotação regular. Quanto mais tempo uma chave permanece ativa, maior é a probabilidade de ter sido copiada, reutilizada ou armazenada em locais fora do controle da empresa.
Credenciais antigas também costumam estar ligadas a projetos abandonados, funcionários que mudaram de função, aplicações descontinuadas e integrações que já não são monitoradas. Mesmo sem uso aparente, uma chave válida continua representando uma porta de entrada.
O que um invasor pode fazer com uma chave administrativa
O comprometimento de uma conta AWS pode provocar consequências que vão muito além do acesso não autorizado a um único serviço. Um atacante pode copiar informações sensíveis, modificar configurações de segurança, interromper aplicações e apagar recursos essenciais à operação.
Também é possível criar novos usuários administrativos, alterar políticas IAM e estabelecer mecanismos de persistência. Dessa forma, mesmo que a credencial original seja revogada, o invasor pode manter outro caminho de acesso.
Outro abuso comum é a instalação de mineradores de criptomoedas. Nesse cenário, a infraestrutura da empresa passa a consumir grandes volumes de processamento, provocando aumento expressivo na fatura da AWS. A companhia pode descobrir o incidente apenas quando receber uma cobrança muito acima do padrão.
A investigação constatou ainda que somente 262 das 2.754 contas que puderam ser verificadas tinham alertas de orçamento configurados. Sem esse tipo de monitoramento, o uso indevido de recursos pode continuar por dias ou semanas.
Como reduzir a exposição de chaves AWS
A primeira medida deve ser eliminar o uso de chaves root para tarefas rotineiras. A conta root deve permanecer protegida com autenticação multifator e ser utilizada apenas em situações excepcionais. As atividades diárias precisam ser executadas por identidades IAM com permissões limitadas.
Também é necessário aplicar o princípio do menor privilégio. Uma aplicação que precisa acessar um bucket específico não deve receber autorização para administrar toda a conta. Permissões devem ser definidas de acordo com a função real de cada usuário, serviço ou pipeline.
A rotação periódica é outra etapa fundamental. Chaves que não podem ser substituídas automaticamente precisam ter responsáveis, prazo de validade e justificativa documentados. Quando uma credencial é exposta, a prioridade é revogá-la imediatamente, investigar seu uso e emitir uma nova somente depois de corrigir a origem do vazamento.
Prevenção no código e nos pipelines
Segredos nunca devem ser incluídos diretamente em arquivos de código, scripts, imagens Docker ou variáveis visíveis em registros de execução. O ideal é utilizar serviços próprios de gerenciamento de segredos, com controle de acesso, auditoria e substituição automatizada.
Ferramentas de varredura podem ser incorporadas ao processo de desenvolvimento para identificar chaves antes que um commit seja aceito. A verificação deve analisar não apenas os arquivos atuais, mas também o histórico do Git, branches antigas e artefatos gerados durante a compilação.
É importante lembrar que apagar uma chave de um repositório não elimina necessariamente o vazamento. A credencial pode continuar disponível no histórico de versões, em forks, caches ou cópias locais. Por isso, qualquer segredo encontrado publicamente deve ser tratado como comprometido.
Monitoramento e resposta a incidentes
Empresas devem acompanhar chamadas de API, alterações em políticas IAM, criação de usuários, mudanças em grupos de segurança e aumentos incomuns no consumo de recursos. Alertas de orçamento e notificações de comportamento anômalo ajudam a reduzir o tempo entre o abuso e a descoberta.
Ao identificar uma exposição, o procedimento deve incluir revogação da chave, preservação de evidências, análise de logs, revisão de permissões e busca por contas ou recursos criados pelo invasor. Também é necessário avaliar se dados foram acessados ou retirados da infraestrutura.
A AWS informou que notifica clientes quando identifica chaves expostas, analisa denúncias e adota medidas de quarentena para reduzir possíveis impactos. A empresa reforçou, contudo, o modelo de responsabilidade compartilhada: o provedor protege a infraestrutura da nuvem, enquanto o cliente precisa proteger identidades, dados, configurações e aplicações executadas nela.
O episódio mostra que uma chave aparentemente esquecida pode representar um risco corporativo de grande escala. A combinação de credenciais antigas, permissões excessivas, ausência de alertas e exposição em plataformas públicas cria condições para que um simples vazamento se transforme em comprometimento total da conta AWS.