Milhares de credenciais AWS vazadas continuam ativas por anos

Milhares de credenciais AWS vazadas continuam ativas — algumas há mais de cinco anos

Uma credencial de acesso à nuvem publicada por engano em um repositório, notebook, imagem de container ou log de integração contínua pode parecer, à primeira vista, apenas mais um erro operacional no ciclo de desenvolvimento. O problema assume outra dimensão quando essa credencial continua válida depois da exposição e, principalmente, quando permanece esquecida durante anos. Foi exatamente esse cenário que pesquisadores da Truffle Security encontraram ao analisar milhares de credenciais da Amazon Web Services (AWS) expostas em fontes públicas. O levantamento mostra que o problema dos segredos vazados não termina quando alguém remove uma chave de um repositório: em muitos casos, a identidade associada àquela credencial continua existindo, autenticando e oferecendo acesso a recursos corporativos muito tempo depois de sua exposição.

Os números ajudam a dimensionar o problema. Segundo a Truffle Security, foram identificadas 64.024 chaves AWS únicas durante a pesquisa. Para uma análise mais detalhada, os pesquisadores reavaliaram 10.616 conjuntos completos de credenciais AWS em 10 de agosto de 2026 e descobriram que aproximadamente 88% ainda conseguiam se autenticar. O dado é preocupante porque demonstra que a exposição pública não estava restrita a credenciais antigas e inutilizadas, preservadas apenas como resíduos históricos em algum repositório. Milhares delas continuavam tecnicamente funcionais e, dependendo das permissões associadas, poderiam representar uma porta de entrada para ambientes cloud, aplicações, dados e serviços corporativos.

O verdadeiro risco está no que existe atrás da credencial

Uma AWS Access Key não deve ser tratada simplesmente como uma sequência de caracteres secreta. Na prática, ela representa uma identidade técnica utilizada para autenticação programática e, quando combinada às permissões atribuídas por meio do Identity and Access Management (IAM), determina quais operações aquela identidade pode realizar. Isso significa que descobrir uma credencial exposta é apenas o início da análise de risco. A pergunta realmente importante é outra: o que um atacante conseguiria fazer caso utilizasse essa credencial? Uma chave associada a permissões restritas pode produzir um impacto limitado; a mesma exposição envolvendo uma identidade administrativa pode abrir caminho para comprometimento muito mais amplo do ambiente.

Esse é justamente um dos pontos mais preocupantes apresentados pela pesquisa. Entre as credenciais identificadas e associadas a empresas, os pesquisadores encontraram centenas vinculadas a níveis elevados de privilégio. A análise apontou 526 root access keys e outras 242 credenciais vinculadas a usuários IAM com a política AdministratorAccess, totalizando 768 casos associados a capacidades administrativas significativas. A presença de credenciais root merece atenção especial porque a identidade root está diretamente vinculada à conta AWS e possui poderes extremamente amplos. Em termos de risco, seria como encontrar uma chave esquecida em um local público e descobrir, posteriormente, que ela não abre apenas uma porta lateral do edifício, mas potencialmente dá acesso às áreas mais críticas da infraestrutura.

Algumas chaves sobreviveram por anos sem serem eliminadas

A idade das credenciais encontradas talvez seja ainda mais reveladora do que a quantidade. Entre aquelas para as quais os pesquisadores conseguiram determinar informações de criação, a idade mediana das credenciais ainda ativas ficou em aproximadamente 1.831 dias — cerca de cinco anos. A credencial mais antiga identificada durante a pesquisa teria sido criada aproximadamente 17,4 anos antes da análise. Esses números afastam a hipótese de que o problema seja explicado apenas por vazamentos recentes ainda não tratados pelas equipes responsáveis. Parte das credenciais aparentemente atravessou anos de mudanças em aplicações, equipes, projetos, arquiteturas e processos sem que seu ciclo de vida fosse encerrado.

Esse cenário revela uma fragilidade de governança que vai além do armazenamento inadequado de secrets. Uma aplicação pode ser descontinuada, um desenvolvedor pode deixar a empresa, um projeto pode ser migrado ou um pipeline pode ser substituído, mas nada disso garante automaticamente que as credenciais utilizadas anteriormente sejam revogadas. Quando não existe um processo consistente de ownership, inventário e revisão de identidades de máquinas e workloads, essas chaves podem sobreviver à própria finalidade para a qual foram originalmente criadas. A organização deixa de saber claramente quem utiliza a credencial, por que ela ainda existe e quais sistemas dependem dela, enquanto a AWS continua reconhecendo aquela identidade como válida.

Rotacionar credenciais ainda parece ser uma disciplina negligenciada

A pesquisa também encontrou sinais de baixa adoção de rotação entre as credenciais analisadas. Em 2.903 casos nos quais foi possível enumerar outras access keys associadas ao mesmo usuário, apenas 398 — aproximadamente 13,7% — possuíam uma chave mais nova. Embora esse indicador, isoladamente, não permita reconstruir todo o processo de gestão de credenciais de cada organização, ele reforça uma questão operacional importante: detectar que um segredo apareceu em um ambiente público não significa que o incidente foi efetivamente corrigido. A exposição só deixa de representar aquele risco específico quando a credencial comprometida é revogada ou substituída e o possível uso indevido é investigado.

A resposta adequada, portanto, não deveria terminar com a exclusão do arquivo, do commit ou do repositório onde a chave foi encontrada. Uma credencial publicada em ambiente acessível publicamente deve ser tratada como potencialmente comprometida, porque não há como garantir que ela não tenha sido coletada antes da remoção. Bots, mecanismos de indexação, scanners automatizados, datasets e serviços de arquivamento podem copiar esse conteúdo em poucos minutos. A remediação precisa atuar sobre a própria identidade: revogar ou rotacionar a credencial, revisar suas permissões, determinar quais recursos estavam acessíveis e examinar logs para identificar possíveis atividades anômalas durante o período em que o segredo permaneceu exposto.

Algumas credenciais já haviam sido identificadas como comprometidas

Outro resultado da pesquisa ajuda a mostrar a diferença entre detectar, conter e efetivamente remediar uma exposição. Segundo a Truffle Security, 929 das credenciais analisadas estavam associadas à política AWSCompromisedKeyQuarantine, mecanismo utilizado pela AWS quando uma access key é identificada como potencialmente comprometida. Ainda assim, essas credenciais continuavam conseguindo autenticar, e algumas teriam sido identificadas como comprometidas havia mais de três anos. O mecanismo de quarentena reduz determinadas capacidades e procura limitar possíveis abusos, mas não deve ser interpretado como substituto para a revogação e investigação conduzidas pelo responsável pela conta.

O caso demonstra um princípio importante de resposta a incidentes: um alerta emitido pelo provedor de nuvem não encerra o ciclo de tratamento. A AWS pode identificar sinais de exposição, aplicar medidas de proteção e informar o cliente, mas a organização continua responsável por entender por que aquela credencial existia, quais permissões possuía, onde foi utilizada e se deveria continuar ativa. Uma identidade potencialmente comprometida que permanece operacional durante anos transforma um problema inicialmente técnico em uma questão de governança, accountability e gestão do ciclo de vida de acessos.

O vazamento de secrets já não acontece apenas no GitHub

Durante muito tempo, o exemplo clássico de exposição de credenciais era relativamente simples: um desenvolvedor inseria uma senha, token ou API key diretamente no código e posteriormente enviava o projeto para um repositório público. Esse cenário continua relevante, mas a superfície atual é muito maior. Credenciais podem aparecer em históricos Git, imagens de containers, registries, logs de pipelines de Continuous Integration/Continuous Delivery (CI/CD), notebooks de Data Science, arquivos de configuração, artefatos de desenvolvimento, datasets e ambientes utilizados para treinamento ou experimentação com Inteligência Artificial.

Essa expansão é importante porque altera a própria estratégia de detecção. Uma empresa pode revisar o código-fonte atual de suas aplicações e concluir que não existem secrets expostos, enquanto uma credencial continua armazenada em um commit antigo, em uma camada histórica de uma imagem Docker, em um notebook compartilhado anos atrás ou em um dataset posteriormente publicado. A segurança de credenciais precisa, portanto, acompanhar todo o ciclo de desenvolvimento e distribuição dos artefatos, e não apenas o estado atual do código que está em produção.

Hugging Face mostra como a IA amplia essa superfície

Um dos resultados mais interessantes da pesquisa aparece justamente fora do ecossistema tradicional de repositórios de software. A Truffle Security afirma ter analisado aproximadamente 7,6 petabytes de dados públicos de treinamento disponíveis no Hugging Face, identificando 3.343 credenciais AWS ainda válidas. Segundo os pesquisadores, mais de 900 dessas credenciais conseguiam enumerar buckets S3 que, em conjunto, armazenavam pelo menos 51,7 TB de dados privados. O achado é relevante porque demonstra como a rápida expansão de plataformas de Inteligência Artificial, datasets e notebooks cria novos caminhos pelos quais informações sensíveis podem escapar dos controles tradicionais de desenvolvimento seguro.

A consequência é que o fluxo de exposição de secrets deixou de seguir apenas a conhecida sequência desenvolvedor → código → repositório → produção. Dados corporativos agora atravessam ambientes de experimentação com IA, notebooks, datasets, modelos, containers, ferramentas de automação e agentes capazes de acessar APIs e serviços externos. À medida que essas tecnologias entram nos processos empresariais, elas também precisam entrar no escopo de Secrets Management, Data Loss Prevention (DLP), DevSecOps, Cloud Security e governança de Inteligência Artificial. Caso contrário, a organização corre o risco de proteger cuidadosamente seu código-fonte enquanto credenciais sensíveis escapam por caminhos que sequer fazem parte dos controles tradicionais de Secure Software Development.

O caso da CISA mostrou que o problema está longe de ser teórico

Um episódio recente envolvendo a Cybersecurity and Infrastructure Security Agency (CISA) dos Estados Unidos ajuda a contextualizar a gravidade desse tipo de exposição. Em 2026, pesquisadores identificaram um repositório público mantido por um contratado da agência contendo aproximadamente 844 MB de informações relacionadas à CISA, incluindo credenciais privilegiadas associadas a ambientes AWS GovCloud, além de usernames, senhas e outros dados internos. O material teria permanecido publicamente acessível durante meses antes de sua descoberta, levando a agência a conduzir uma resposta ao incidente e posteriormente divulgar informações sobre o ocorrido.

O episódio é significativo justamente porque elimina uma interpretação confortável de que vazamentos desse tipo seriam um problema restrito a desenvolvedores inexperientes, pequenas empresas ou projetos abandonados. Mesmo organizações altamente reguladas e diretamente envolvidas com cibersegurança dependem de cadeias de desenvolvimento, fornecedores, contratados e processos humanos sujeitos a falhas. Em ambientes complexos, basta que uma credencial privilegiada atravesse a fronteira errada para que um erro aparentemente simples de configuração se transforme em um incidente com potencial de comprometimento muito maior.

Apagar o segredo publicado não resolve o problema

Existe uma regra operacional que merece ser reforçada: uma credencial secreta publicada em um ambiente publicamente acessível deve ser considerada comprometida. Tornar o repositório privado, remover o arquivo ou apagar o commit não oferece garantia de que o segredo deixou de circular. Durante o período de exposição, ele pode ter sido coletado automaticamente, indexado por mecanismos de busca, copiado para outro repositório, incorporado a datasets ou armazenado por scanners especializados em localizar justamente esse tipo de informação.

Por essa razão, a primeira ação relevante precisa ocorrer sobre a própria credencial. Ela deve ser revogada ou rotacionada e, a partir daí, a organização precisa identificar qual identidade estava associada à chave, quais permissões possuía, quais recursos poderiam ser alcançados e se existem registros de utilização suspeita. Em ambientes AWS, isso também significa utilizar registros como os fornecidos pelo AWS CloudTrail e outras fontes de telemetria disponíveis para reconstruir atividades relacionadas à identidade comprometida. A simples remoção do segredo da internet trata a evidência visível do problema; a revogação e a investigação tratam o risco.

O caminho mais seguro é reduzir a dependência de credenciais permanentes

O episódio também reforça uma discussão arquitetural mais ampla. Em vez de concentrar todos os esforços em armazenar melhor credenciais de longa duração, organizações deveriam questionar quantas dessas credenciais realmente precisam existir. A própria AWS recomenda priorizar, sempre que possível, mecanismos baseados em credenciais temporárias, IAM Roles e federação de identidade, reduzindo a necessidade de manter Access Keys permanentes distribuídas por aplicações, servidores e pipelines.

Em ambientes de CI/CD, por exemplo, mecanismos baseados em OpenID Connect (OIDC) permitem que plataformas compatíveis obtenham credenciais temporárias para acessar recursos AWS sem manter Access Keys permanentes armazenadas como secrets do pipeline. A diferença de segurança é significativa: em vez de entregar ao processo uma credencial capaz de continuar funcionando durante meses ou anos caso seja copiada, o ambiente concede uma autorização temporária e contextual, limitada ao período necessário para determinada execução. O objetivo deixa de ser apenas esconder melhor uma chave permanente e passa a ser reduzir a necessidade de essa chave existir.

Secrets Management precisa acompanhar todo o ciclo DevSecOps

A descoberta da Truffle Security mostra também por que Secrets Management não deveria funcionar apenas como um scanner executado no final do pipeline. O controle precisa começar antes do commit e continuar durante todo o ciclo de vida do software, incluindo análise de histórico Git, containers, registries, notebooks, datasets, logs de CI/CD e demais artefatos capazes de transportar informações sensíveis. Da mesma forma, alertas de credenciais comprometidas precisam estar integrados a processos formais de resposta a incidentes, com responsáveis definidos e prazos para investigação e remediação.

O princípio do Least Privilege também assume papel decisivo nesse contexto. Duas organizações podem cometer exatamente o mesmo erro e publicar uma AWS Access Key em um repositório público, mas experimentar consequências completamente diferentes. Se a primeira credencial tiver acesso estritamente limitado a um recurso específico, o raio potencial de impacto será menor. Se a segunda estiver vinculada a AdministratorAccess ou à identidade root, o mesmo erro poderá criar condições para comprometimento muito mais amplo. O segredo vazado pode ser idêntico em natureza; o que determina grande parte do blast radius são os privilégios existentes atrás daquela identidade.

O problema de fundo é uma dívida de identidade

Quando observados em conjunto, os resultados da pesquisa revelam algo maior do que milhares de chaves AWS esquecidas na internet. Eles mostram como identidades técnicas podem escapar silenciosamente dos processos tradicionais de governança. Uma aplicação é descontinuada, mas sua chave continua válida. Um desenvolvedor deixa a organização, mas um script criado anos antes permanece utilizando sua credencial. Um notebook experimental se transforma em dataset público. Uma imagem de container é substituída, mas suas camadas antigas continuam disponíveis. Um pipeline é modernizado, enquanto ninguém elimina as credenciais utilizadas pela versão anterior.

Com o passar dos anos, esse acúmulo cria uma espécie de dívida de identidade: credenciais que continuam tecnicamente válidas embora a organização já não saiba claramente por que existem, quem responde por elas ou quais sistemas ainda dependem de seu funcionamento. Assim como a dívida técnica cresce silenciosamente até começar a comprometer a manutenção e a segurança dos sistemas, a dívida de identidade amplia a superfície de ataque por meio de acessos antigos, privilégios excessivos e credenciais esquecidas que continuam sendo reconhecidas pela infraestrutura.

Conclusão

Os números apresentados pela Truffle Security são preocupantes, mas talvez o dado mais importante da pesquisa não seja a quantidade de credenciais encontradas. É o tempo durante o qual muitas delas permaneceram utilizáveis. Uma idade mediana próxima de cinco anos para credenciais vazadas ainda capazes de autenticar mostra que o problema não termina quando o segredo aparece na internet — e muito menos quando o arquivo que o continha é removido. O incidente só deixa de representar aquele risco quando a identidade é efetivamente tratada, suas permissões são revistas e a organização consegue determinar se houve utilização indevida durante o período de exposição.

Para CISOs e equipes de Cloud Security, IAM, DevSecOps e Security Operations, a discussão precisa avançar de uma pergunta relativamente simples — “onde armazenamos nossos secrets?” — para questões muito mais incômodas: quantas credenciais permanentes existem hoje na organização? Quem é responsável por cada uma delas? Quando foram utilizadas pela última vez? Quais privilégios possuem? Onde podem ter sido copiadas ao longo dos anos? Quantas pertencem a aplicações que nem existem mais? E, talvez a pergunta mais importante, quantas dessas credenciais poderiam simplesmente deixar de existir?

A pesquisa deixa uma mensagem clara: um segredo esquecido pode desaparecer do radar da organização, mas isso não significa que tenha desaparecido da superfície de ataque. Em ambientes cloud, credenciais são identidades, identidades carregam privilégios e privilégios determinam impacto. Enquanto uma credencial comprometida continuar autenticando, ela continuará representando risco.

Recomendações para as organizações

A partir dos riscos demonstrados pela pesquisa e das práticas recomendadas para ambientes AWS, organizações deveriam revisar o inventário de Access Keys existentes, eliminar root access keys desnecessárias, revogar imediatamente credenciais identificadas em fontes públicas e investigar possíveis utilizações por meio dos registros disponíveis. Também é recomendável revisar privilégios administrativos, aplicar Least Privilege, substituir credenciais permanentes por roles e credenciais temporárias sempre que tecnicamente possível e avaliar mecanismos como OIDC para pipelines CI/CD.

Essa revisão não deveria se limitar aos repositórios de código. Histórico Git, imagens e registries de containers, notebooks, datasets, logs de CI/CD e ambientes utilizados para desenvolvimento ou treinamento de Inteligência Artificial também precisam fazer parte da superfície monitorada. Acima de tudo, cada identidade técnica deveria possuir um proprietário, uma finalidade conhecida e um ciclo de vida definido. Credenciais antigas, inativas, excessivamente privilegiadas ou sem ownership claro não deveriam permanecer indefinidamente no ambiente simplesmente porque ainda não causaram um incidente conhecido.

Referências

Truffle Security — TruffleHog AWS Analyze / pesquisa sobre credenciais AWS vazadas. Fonte primária da pesquisa divulgada em agosto de 2026, contendo os principais resultados relacionados às credenciais analisadas, validade das chaves, privilégios e exposição em datasets.

Infosecurity Magazine — Researchers Find Thousands of Leaked AWS Credentials. Matéria que repercute a pesquisa e contextualiza os riscos associados às credenciais AWS expostas.

BleepingComputer — cobertura sobre credenciais AWS vazadas e acesso administrativo. Fonte complementar para os resultados e implicações de segurança identificados pela pesquisa.

AWS Well-Architected Framework. Referência oficial da AWS para práticas relacionadas à gestão, auditoria e rotação de credenciais.

AWS Secrets Manager — Best Practices. Documentação oficial para gerenciamento de secrets e redução da exposição de informações sensíveis.

GitHub Documentation — Configuring OpenID Connect in Amazon Web Services. Referência para utilização de OIDC e credenciais temporárias em workflows integrados à AWS.

KrebsOnSecurity — Lessons Learned from CISA’s Recent GitHub Leak. Análise do incidente envolvendo exposição de informações e credenciais relacionadas à CISA.