Persistência explorando consistência eventual no IAM da AWS
Introdução
Relatório técnico divulgado pelo pesquisador OFFENSAI descreve uma técnica de persistência que explora a natureza de consistência eventual do AWS Identity and Access Management (IAM). Segundo o teste reproduzido pela equipe, atualizações em recursos como chaves de acesso e políticas levam alguns segundos para propagar entre réplicas, permitindo que atacantes mantenham acesso mesmo após ações de resposta.
Descoberta e escopo / O que mudou agora
OFFENSAI documentou que, durante um intervalo de aproximadamente 3–4 segundos, chaves e alterações podem continuar válidas para chamadas de API. Em um cenário de simulação descrito, um defensor executa o comando aws iam delete-access-key –access-key-id AKIA… –user-name bob enquanto o atacante rapidamente emite aws iam create-access-key –user-name bob; o atraso na propagação permite que o invasor realize ações antes da invalidação completa.
Vetor e exploração / Mitigações
A técnica não depende de vulnerabilidade clássica (CVE) mas do comportamento esperado do serviço em ambientes distribuídos — a consistência eventual. OFFENSAI reporta que isso se aplica não apenas a chaves de acesso, mas também a anexos de políticas, deleções de funções e perfis de login. Playbooks tradicionais que tentam anexar políticas de negação total (por exemplo, AWSDenyAll) sofrem da mesma janela, pois atores maliciosos podem detectar e reverter alterações por meio de consultas repetidas (ListAccessKeys e APIs correlatas).
OFFENSAI recomenda, como mitigação prática, uso de Service Control Policies (SCPs) a nível de conta via AWS Organizations para negar ações de um principal comprometido, já que atacantes normalmente não controlam SCPs de organização. A recomendação adicional é priorizar o uso de funções IAM e credenciais temporárias via STS em vez de chaves de longa duração.
Impacto e alcance / Setores afetados
O impacto descrito é operacional e tático: durante a janela de consistência os invasores podem restaurar ou recriar credenciais e assumir papéis. OFFENSAI não reportou exploração em larga escala na natureza (“no in-the-wild exploits surfaced”), mas demonstrou que times de resposta a incidentes precisam considerar atrasos de propagação em playbooks e regras de detecção.
Limites das informações / O que falta saber
O relato indica que, após divulgação, a AWS aplicou correções de desenvolvimento e atualizou documentação; em retestes de 5 de dezembro de 2025 houve melhorias, como bloqueio de recriação imediata de chaves deletadas em alguns cenários. Ainda assim, OFFENSAI aponta que lacunas persistem — por exemplo, a possibilidade dos atacantes detectarem mudanças e assumirem roles assumíveis com privilégios elevados a partir de contas externas. Não há métricas públicas sobre exploração ativa nem número de organizações afetadas.
Repercussão / Próximos passos
Para equipes de segurança cloud: integrar a janela de consistência eventual nas playbooks de contenção; aplicar SCPs onde possível; reduzir uso de chaves permanentes; reforçar monitoramento de CloudTrail com regras que correlacionem deleções de credenciais e atividade imediata subsequente. OFFENSAI e AWS mantêm diálogo técnico; a AWS não classificou o problema como vulnerabilidade, mas publicou procedimentos de limpeza e recomendações no re:Post.
Referências
- Relato técnico e recomendações de OFFENSAI e postagens da AWS citadas no artigo do Cyber Security News.