Credenciais programáticas esquecidas em repositórios de código, ficheiros de configuração e artefactos de build continuam a ser uma das portas de entrada mais rentáveis para atacantes em ambientes de nuvem. A investigação mais recente da empresa de segurança Truffle Security, responsável pelo scanner de segredos TruffleHog, volta a colocar o problema em números concretos: a empresa afirma ter identificado 768 chaves AWS expostas com direitos de administração completos e ainda ativas. Não se trata de uma falha da Amazon Web Services, mas de higiene de credenciais nas organizações que a utilizam — e o impacto potencial vai do roubo de dados à extorsão, passando pela fatura de computação que aparece no fim do mês.
Resposta rápida: Investigadores da Truffle Security dizem ter encontrado 768 chaves de acesso AWS expostas publicamente que continuavam válidas e com privilégios de administrador, ou seja, com controlo efetivo sobre a conta cloud da organização. O problema não está na infraestrutura da AWS, mas em chaves de longa duração guardadas em código, ficheiros .env e artefactos de desenvolvimento. Faça um inventário de todas as chaves IAM ativas, elimine as de longa duração onde for possível, substitua-as por credenciais temporárias e ative deteção de segredos no fluxo de desenvolvimento. Em caso de exposição, revogue primeiro e investigue o CloudTrail depois.
O que está em causa nesta investigação
A conclusão divulgada pela Truffle Security parte de uma capacidade que a empresa desenvolveu para ir além da simples deteção de um segredo: a funcionalidade TruffleHog Analyze avalia o risco de uma credencial exposta enumerando os recursos e as permissões que lhe estão associados, sem necessitar de acesso à consola do fornecedor. Na versão empresarial, essa análise indica direitos de leitura, escrita e administração da credencial. É essa análise de permissões que permite distinguir uma chave inócua, limitada a um bucket de testes, de uma chave que dá literalmente controlo total sobre a conta.
A tese central não é nova, mas continua a confirmar-se com regularidade desconfortável. A própria Truffle Security já tinha documentado, em investigação anterior sobre diretórios .git expostos em sites de grande tráfego, que as chaves AWS e GitHub representavam 45% de todas as credenciais fugidas e que a maioria dos tokens GitHub válidos analisados (67%) tinha privilégios de nível administrativo. Por outras palavras: quando um segredo escapa, há uma probabilidade elevada de ser um segredo com poder a mais.
Porque é que uma chave AWS vale tanto para um atacante
Uma chave de acesso IAM é composta por um Access Key ID (normalmente com o prefixo AKIA) e por um Secret Access Key. É uma credencial de máquina: autentica chamadas à API sem palavra-passe escrita e, na esmagadora maioria dos casos, sem autenticação multifator. Uma vez obtida, o percurso do atacante é praticamente sempre o mesmo. Numa campanha analisada pela Unit 42 com base em ficheiros .env expostos, os atacantes usaram a chave para executar GetCallerIdentity e confirmar a identidade associada, seguindo-se ListUsers para enumerar utilizadores IAM e ListBuckets para identificar os buckets S3 existentes. Nesse caso, o papel IAM comprometido nem sequer tinha privilégios administrativos sobre todos os recursos, mas tinha permissão para criar novos papéis e associar políticas — o suficiente para escalar.
A velocidade é o segundo fator crítico. Investigação da Clutch Security, que semeou deliberadamente chaves em várias plataformas públicas, mostrou que os atacantes encontram e exploram em poucos minutos as chaves AWS expostas no GitHub e no DockerHub, em várias horas as publicadas no PyPI, Pastebin e Postman Community, e entre um a cinco dias as reveladas em GitLab, Crates.io, Gists públicos, JSFiddle, Stack Overflow, Reddit e Quora; apenas as do npm e de Gists privados ficaram por utilizar. Os investigadores concluíram ainda que os atacantes são muitas vezes mais rápidos do que os próprios alertas de exposição enviados pela AWS.
| Local da exposição | Janela típica até exploração |
|---|---|
| GitHub, DockerHub | Minutos |
| PyPI, Pastebin, Postman Community | Horas |
| GitLab, Crates.io, Gists públicos, JSFiddle, Stack Overflow, Reddit, Quora | 1 a 5 dias |
| npm, Gists privados | Sem utilização observada no teste |
O que acontece depois do acesso inicial
O destino de uma conta AWS comprometida deixou de ser apenas o roubo de dados. A monetização é múltipla e depende do que o atacante encontrar:
- Criptomineração. A Unit 42 documentou a campanha EleKtra-Leak, que visa automaticamente credenciais IAM expostas em repositórios públicos do GitHub e cria múltiplas instâncias EC2 para operações prolongadas de cryptojacking; entre 30 de agosto e 6 de outubro de 2023, os investigadores contabilizaram 474 mineradores únicos potencialmente controlados pelo agente de ameaça.
- Abuso de serviços de e-mail. A Wiz descreveu uma campanha de utilização indevida do Amazon SES com chaves de acesso roubadas, sublinhando que as chaves expostas continuam a ser um dos pontos de entrada mais comuns e eficazes para atacantes.
- Extorsão e roubo de dados. Segundo análise da Qualys, o grupo Crimson Collective visou ambientes AWS a partir de chaves de longa duração expostas e configurações IAM deficientes, enumerando recursos em S3 e EC2, enquanto na campanha TruffleNet credenciais AWS roubadas serviram para automatizar reconhecimento e abusar do Amazon SES em operações de comprometimento de e-mail empresarial.
- Abuso de computação de IA. Num caso analisado publicamente, após obter acesso administrativo o agente de ameaça exfiltrou dados, provisionou instâncias GPU e abusou do Amazon Bedrock para interagir com modelos alojados.
O tempo disponível para reagir é curto. Num incidente descrito pela Cloud Security Alliance, os atacantes descobriram chaves AWS num bucket S3 acessível publicamente e escalaram até ao controlo administrativo total da conta em menos de dez minutos.
A quarentena automática da AWS ajuda, mas não resolve
A AWS deteta chaves publicadas em repositórios públicos e aplica uma política gerida de contenção. Nas notificações enviadas aos clientes, a empresa explica que aplica a política gerida AWSCompromisedKeyQuarantineV2 ao utilizador IAM afetado, negando ações de alto risco como iam:CreateAccessKey e ec2:RunInstances. É uma rede de segurança útil, mas parcial: os investigadores da Clutch notaram que a quarentena apenas limita a capacidade de criar alguns recursos, não impedindo todo o abuso, e as chaves testadas permitiram na mesma iniciar sessão nos ambientes, fazer reconhecimento, escalar privilégios e movimentação lateral. A revogação continua a depender do cliente.
A posição da AWS em episódios semelhantes tem sido consistente. Sobre a campanha de ficheiros .env, um porta-voz afirmou que os serviços e a infraestrutura da AWS não foram afetados e que o problema resultou do abuso de aplicações web mal configuradas, alojadas na nuvem e fora dela, que permitiam acesso público a ficheiros de variáveis de ambiente contendo credenciais.
Sinais de alerta e passos concretos de mitigação
Do lado da deteção, a Wiz recomenda vigiar chaves inativas que subitamente ficam ativas, autenticações a partir de ASN invulgares e atividade a partir de vários países, começando por tratar as chaves de maior risco — as com permissões demasiado amplas ou há muito adormecidas — e monitorizar picos súbitos de utilização de serviços cloud.
| Indicador comportamental | Porque importa |
|---|---|
GetCallerIdentity a partir de origem desconhecida | Primeira chamada típica para validar uma chave roubada |
ListUsers, ListBuckets em sequência rápida | Reconhecimento de identidades e de dados acessíveis |
CreateAccessKey, AttachUserPolicy, CreateRole | Tentativa de escalada de privilégios e persistência |
RunInstances em regiões não utilizadas | Padrão associado a criptomineração |
| Envio massivo via Amazon SES | Abuso para phishing e fraude de e-mail empresarial |
- Inventariar todas as chaves de acesso IAM ativas e identificar as que estão adormecidas há meses.
- Substituir chaves de longa duração por papéis IAM e credenciais temporárias sempre que a arquitetura o permita.
- Aplicar privilégio mínimo: nenhuma credencial de aplicação deve ter
AdministratorAccesspor defeito. - Ativar proteção contra publicação de segredos e análise automática de repositórios, incluindo o histórico Git e artefactos de build.
- Garantir CloudTrail em todas as regiões, com retenção suficiente para investigação, e alertas sobre as chamadas de API da tabela acima.
- Em caso de exposição, desativar a chave imediatamente e só depois investigar; rodar credenciais associadas e verificar novos utilizadores, papéis e relações de confiança criados.
Porque é que isto importa em Portugal
Nenhuma organização está imune por ser pequena ou por ser pública. Em maio de 2026, a KrebsOnSecurity noticiou que um prestador de serviços da agência norte-americana CISA manteve um repositório público no GitHub que expôs credenciais de contas AWS GovCloud altamente privilegiadas e de um grande número de sistemas internos, num caso descrito por especialistas como uma das fugas governamentais mais graves dos últimos anos. Segundo análise posterior, o repositório existia desde novembro de 2025 e as chaves AWS expostas permaneceram válidas durante mais 48 horas após a remoção da conta.
Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de credenciais e o controlo de acessos deixaram de ser uma boa prática opcional para passarem a integrar as medidas de gestão de risco exigíveis, a par das obrigações de notificação de incidentes significativos ao CNCS/CERT.PT. E, quando as chaves comprometidas dão acesso a dados pessoais alojados em S3 ou em bases de dados geridas, aplica-se também o RGPD: cabe ao responsável pelo tratamento avaliar o risco para os titulares e, se aplicável, notificar a CNPD no prazo de 72 horas, mesmo que o incidente tenha origem num fornecedor ou num programador externo. A responsabilidade não se transfere por contrato.
Para as PME portuguesas que alojam faturação, lojas online ou aplicações móveis na nuvem, a lição prática é simples e barata de aplicar: uma chave esquecida num repositório antigo pode custar mais do que qualquer campanha de phishing. O inventário de credenciais é o controlo com melhor relação entre esforço e risco evitado.
Perguntas frequentes
Como sei se uma chave AWS da minha organização está exposta?
Comece por analisar os repositórios de código, incluindo todo o histórico Git, ficheiros de configuração, imagens de contentor e artefactos de build, com ferramentas de deteção de segredos. Cruze depois essa lista com o inventário de chaves ativas na consola IAM e verifique a data da última utilização de cada uma.
A AWS não bloqueia automaticamente as chaves expostas?
A AWS aplica uma política de quarentena que nega ações de alto risco, como a criação de novas chaves de acesso ou o arranque de instâncias EC2, mas essa medida é parcial. Investigadores demonstraram que os atacantes chegam frequentemente antes do alerta e que a quarentena não impede todo o abuso; a revogação continua a depender do cliente.
Que registos devo analisar após uma exposição?
O CloudTrail é o ponto de partida, procurando chamadas de validação e reconhecimento, criação de utilizadores, papéis e políticas, arranque de instâncias em regiões não habituais e envios massivos de e-mail. Vale a pena verificar também acessos a partir de ASN e países fora do padrão da organização.
Uma fuga de chaves obriga a notificar a CNPD ou o CNCS?
Depende do impacto. Se houver risco para os direitos e liberdades de titulares de dados pessoais, aplica-se o dever de notificação à CNPD no prazo de 72 horas. Se a organização estiver abrangida pelo Regime Jurídico da Cibersegurança e o incidente for significativo, acrescem as obrigações de comunicação ao CNCS/CERT.PT.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Truffle Security, Unit 42 (Palo Alto Networks), Wiz, Clutch Security, Qualys, Cloud Security Alliance e AWS.