10 mil chaves AWS expostas: 242 tinham privilégios 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) consideradas ativas e válidas. O levantamento analisou materiais publicados entre agosto de 2022 e agosto de 2026 e foi divulgado em 19 de agosto de 2026.
Entre as credenciais identificadas, 817 estavam relacionadas a empresas. Desse grupo, 526 eram chaves associadas ao usuário root, a identidade de maior privilégio dentro de uma conta AWS. Além disso, 242 credenciais pertenciam a usuários do IAM com a política AdministratorAccess, capaz de autorizar praticamente qualquer operação no ambiente de nuvem.
Na prática, uma chave com esse nível de permissão pode permitir a criação, alteração, exclusão e consulta de recursos em diversos serviços da AWS. Dependendo da configuração da conta, o invasor poderia assumir o controle de servidores, bancos de dados, aplicações, redes virtuais e mecanismos de armazenamento.
Hugging Face aparece como principal origem das credenciais
A plataforma Hugging Face, utilizada por desenvolvedores para compartilhar modelos e projetos de inteligência artificial, concentrou a maior quantidade de exposições individuais. Segundo o relatório, foram encontradas 8.482 chaves AWS distintas publicadas em conteúdos relacionados ao serviço.
A análise mais ampla identificou 431.875 segredos da AWS distribuídos em 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. Após a eliminação de duplicidades, o material correspondia a 64.024 chaves exclusivas ligadas a 50.654 contas AWS.
O resultado mostra que o vazamento de credenciais não ocorre apenas por invasões sofisticadas. Uma chave pode ser publicada acidentalmente em um arquivo de configuração, incluída em um commit, armazenada em um log de erro ou incorporada a uma imagem de contêiner. Quando esse conteúdo fica público, mecanismos automatizados conseguem localizá-lo rapidamente.
Credenciais antigas continuam ativas por anos
A idade das chaves também chamou atenção. Entre 2.903 credenciais cuja data de criação estava disponível, a média foi de 1.831 dias, aproximadamente cinco anos. A chave mais antiga analisada tinha 17,4 anos.
Somente 398 registros, equivalentes a 13,7% do total, apresentavam uma chave de acesso mais recente vinculada ao mesmo usuário. Esse dado indica que a maior parte das credenciais provavelmente nunca passou por um processo regular de rotação.
Manter chaves antigas aumenta consideravelmente a janela de oportunidade para criminosos. Mesmo que uma credencial não esteja sendo usada ativamente, ela pode continuar válida e conservar permissões elevadas. Sem inventário, expiração e revisão periódica, a organização pode não perceber que uma conta esquecida ainda representa um caminho de entrada.
O que um invasor pode fazer com acesso administrativo
O comprometimento de uma chave com privilégios amplos pode gerar consequências muito graves. O atacante pode copiar informações armazenadas em buckets, bancos de dados e sistemas de backup, além de alterar configurações, apagar recursos e interromper aplicações essenciais.
Outra possibilidade é a criação de novos usuários ou chaves com privilégios elevados. Esse mecanismo permite manter o acesso mesmo depois que a credencial original é revogada. O invasor também pode modificar regras de rede, enfraquecer controles de segurança, desativar registros de auditoria e alterar políticas de identidade.
A infraestrutura comprometida ainda pode ser usada para instalar mineradores de criptomoedas. Nesse cenário, a empresa sofre não apenas com o incidente, mas também com o aumento repentino da fatura da nuvem. A Truffle Security observou que somente 262 das 2.754 contas avaliadas tinham algum alerta de orçamento configurado.
Como reduzir o risco de vazamento
A primeira medida é eliminar o uso de chaves de acesso associadas ao usuário root. A AWS recomenda utilizar identidades IAM com permissões específicas e autenticação multifator, reservando o root para tarefas excepcionais de administração da conta.
Também é importante adotar o princípio do menor privilégio. Usuários, aplicações e serviços devem receber apenas as autorizações indispensáveis para executar suas funções. Uma aplicação que precisa gravar arquivos, por exemplo, não deveria ter permissão para excluir bancos de dados ou criar novos administradores.
A rotação de credenciais precisa fazer parte de uma rotina formal. As equipes devem identificar chaves sem uso, verificar sua idade, substituir as que permanecem necessárias e revogar imediatamente aquelas publicadas ou potencialmente comprometidas. A simples criação de uma nova chave não basta: a credencial antiga deve ser desativada e removida.
Segurança no código e nos pipelines
Repositórios de código devem passar por varreduras automáticas em busca de segredos antes de cada envio. É recomendável utilizar cofres de credenciais, variáveis protegidas de ambiente e serviços de gerenciamento de segredos, evitando a inclusão de chaves em arquivos de configuração ou no código-fonte.
Os históricos do Git também precisam ser considerados. Apagar uma chave do arquivo atual não remove necessariamente suas versões anteriores. Por isso, quando um segredo é publicado, a organização deve revogá-lo imediatamente e investigar todo o histórico do repositório, além de verificar logs, imagens e artefatos gerados pelos pipelines.
Imagens Docker, conjuntos de dados e registros de integração contínua merecem atenção especial. Esses ambientes frequentemente são compartilhados entre equipes ou publicados em plataformas externas, o que amplia a chance de uma credencial permanecer disponível mesmo depois de removida do projeto principal.
Monitoramento e resposta a incidentes
Alertas de orçamento devem ser configurados para identificar aumentos anormais no consumo. Embora não impeçam diretamente um ataque, eles podem reduzir o tempo de resposta e revelar atividades como mineração ilícita, criação massiva de recursos ou transferência incomum de dados.
As organizações também devem acompanhar eventos de autenticação e alterações administrativas por meio dos recursos de auditoria da AWS. Atividades fora do padrão, acessos de localidades inesperadas e mudanças repentinas em políticas de IAM podem indicar o uso indevido de uma chave.
Ao suspeitar de exposição, o procedimento deve incluir a revogação da credencial, a análise dos registros, a verificação de usuários e chaves criados recentemente, a revisão das políticas de acesso e a avaliação de possíveis dados exfiltrados. Se houver impacto financeiro ou operacional, as áreas de segurança, infraestrutura, jurídico e gestão devem atuar de forma coordenada.
Responsabilidade compartilhada
A AWS afirmou que notifica clientes quando identifica chaves expostas, analisa as denúncias recebidas e aplica políticas de quarentena para limitar possíveis abusos. A empresa também reforça que a proteção da infraestrutura depende do modelo de responsabilidade compartilhada.
Nesse modelo, a provedora protege a infraestrutura física e os serviços básicos da nuvem, enquanto o cliente precisa cuidar das identidades, permissões, dados, configurações, aplicações e credenciais utilizadas em sua conta.
O caso reforça uma conclusão importante: uma chave AWS deve ser tratada como uma senha de alto impacto. Ela não pode permanecer em código público, ser reutilizada por tempo indefinido ou receber permissões superiores às necessárias. Inventário contínuo, rotação, autenticação multifator, monitoramento e resposta rápida são medidas essenciais para evitar que uma credencial esquecida se transforme em controle total da infraestrutura corporativa.