CISOs e times de resposta a incidentes em nuvem precisam revisar urgentemente seus playbooks para lidar com janelas de consistência eventual no AWS IAM, que podem ser exploradas para manter persistência mesmo após a “revogação” de chaves.
A técnica de persistência no AWS IAM
O AWS IAM adota um modelo de consistência eventual: alterações em chaves de acesso, políticas, roles e perfis de login levam em média 3–4 segundos para se propagar entre regiões e réplicas, como us-east-1 e eu-central-1. Nos testes da OFFENSAI, durante esse intervalo, chaves marcadas como deletadas ainda são aceitas para chamadas de API, permitindo que um invasor execute ações adicionais antes que o bloqueio se torne efetivo.
Em um cenário simulado, o defensor executa aws iam delete-access-key para o usuário comprometido, enquanto o atacante, usando a mesma chave, rapidamente chama aws iam create-access-key para o mesmo usuário, conseguindo criar novas credenciais dentro da janela de atraso. O mesmo raciocínio se aplica a anexos de política, exclusão de roles e login profiles, ampliando o risco para todo o fluxo de resposta a incidentes baseado apenas em “revogar e deletar”.
Por que playbooks tradicionais falham
Playbooks que recomendam anexar uma política de deny-all (como AWSDenyAll ou AWSCompromisedKeyQuarantine) sofrem do mesmo problema: a política leva alguns segundos para surtir efeito, tempo em que o atacante pode detectar a mudança via chamadas como ListAccessKeys e removê-la. A própria “Credential Cleanup Procedure” da AWS, publicada em re:Post, orienta esperar a propagação completa antes de prosseguir, mas isso é ineficaz contra adversários que atuam proativamente nesse intervalo.
Após a divulgação, a AWS aplicou correções parciais: hoje uma chave deletada bloqueia imediatamente a criação de uma nova chave para o mesmo usuário, mitigando um vetor específico. No entanto, retestes mostraram que atacantes ainda conseguem, a partir do contexto existente, detectar as mudanças e criar/usar roles assumíveis com AdministratorAccess a partir de contas externas, mantendo acesso mesmo depois da “limpeza” inicial.
Recomendações da OFFENSAI e da AWS
- Usar SCPs em nível de conta para contenção: aplicar Service Control Policies via AWS Organizations negando todas as ações para o principal comprometido (usuário/role), já que o atacante não controla SCPs. Depois da propagação da SCP, executar a limpeza de chaves, roles e políticas com risco muito menor de corrida.
- Favorecer roles e credenciais temporárias (STS): reduzir o uso de chaves de longo prazo para que qualquer comprometimento seja limitado em tempo e menos sensível a nuances de consistência eventual.
- Ajustar monitoramento e IR: incorporar atrasos de propagação nas regras de detecção (observando atividade suspeita logo após ações administrativas de bloqueio) e reescrever runbooks para que containment comece por mecanismos que o atacante não pode alterar, como SCPs em nível de organização.
AWS reconheceu os achados em abril de 2025, aplicando mudanças de implementação e documentação, mas sem classificar o comportamento como vulnerabilidade, reforçando que se trata de uma característica de sistemas distribuídos que precisa ser considerada explicitamente no design de segurança e nos processos de resposta.
