Uma técnica de persistência crítica no AWS Identity and Access Management (IAM) decorrente de seu modelo de consistência eventual, permitindo que invasores mantenham o acesso mesmo depois que os defensores excluam chaves de acesso comprometidas.
O AWS IAM, como muitos sistemas distribuídos, emprega consistência eventual para escalar entre regiões e réplicas. Atualizações de recursos como chaves de acesso ou políticas se propagam com um atraso previsível de aproximadamente 3 a 4 segundos, conforme confirmado pelos testes da OFFENSAI em regiões como us-east-1 e eu-central-1.
Durante esta janela, as chaves excluídas permanecem válidas para chamadas de API, permitindo que os invasores listem as chaves que recebem uma matriz vazia ou gerem novas antes que a invalidação seja concluída.
Chave de acesso usada após exclusão
A empresa de segurança OFFENSAI descobriu que, em um ataque simulado, um defensor executa aws iam delete-access-key –access-key-id AKIA… –user-name bob, enquanto o invasor segue rapidamente com aws iam create-access-key –user-name bob.
Os logs do CloudTrail registram com precisão a exclusão e as ações subsequentes, mas o atraso de consistência permite a persistência. Isso vai além de chaves para anexos de políticas, exclusões de funções e perfis de login, ampliando os riscos na resposta a incidentes.
Persistência dentro das chaves
Os manuais tradicionais falham aqui: anexar políticas de negação de tudo, como AWSDenyAll, gera a mesma janela, pois os invasores as detectam e desanexam por meio de pesquisa ListAccessKeys ou APIs semelhantes.
O próprio procedimento de limpeza de credenciais da AWS, publicado no re:Post, recomenda aguardar períodos completos de propagação, mas se mostra ineficiente contra invasores proativos que impedem a aplicação de políticas.
Os testes pós-divulgação revelaram correções parciais. Uma chave excluída agora bloqueia a criação de novas chaves, mas as lacunas persistem. Os invasores ainda podem detectar alterações e implantar funções assumidas com AdministratorAccess de contas externas.
A OFFENSAI recomenda políticas de controle de serviço (SCPs) em nível de conta por meio do AWS Organizations para negar todas as ações para entidades comprometidas, pois os invasores não têm controle de SCP.
Após a propagação, prossiga com a limpeza. A AWS reconheceu as descobertas em abril de 2025, aplicando correções de desenvolvimento e atualizações de documentação sem classificá-las como uma vulnerabilidade. Os retestes compartilhados em 5 de dezembro de 2025 estão alinhados com sua avaliação, solicitando revisões do manual.
Nenhuma exploração selvagem surgiu. As organizações devem integrar esses atrasos nas regras de detecção, favorecendo funções IAM e credenciais temporárias STS em vez de chaves de longo prazo para minimizar a exposição.
Siga-nos no Google News, LinkedIn e X para atualizações diárias de segurança cibernética. Contate-nos para apresentar suas histórias.
