Hackers Exploit AWS IAM Eventual Consistency to Establish Persistence
A critical persistence technique has been identified in AWS Identity and Access Management (IAM), linked to its eventual consistency model. This allows attackers to maintain access even after compromised access keys are deleted.
A critical persistence technique has been identified in AWS Identity and Access Management (IAM), linked to its eventual consistency model. This allows attackers to maintain access even after compromised access keys are deleted.
AWS IAM utilizes eventual consistency across its distributed systems to ensure scalability across regions and replicas. Updates to resources such as access keys or policies propagate with a predictable delay of approximately 3-4 seconds, as confirmed through OFFENSAI’s testing in regions including us-east-1 and eu-central-1.
During this delay, deleted keys remain valid for API calls, enabling attackers to list keys receiving an empty array or generate new ones before invalidation completes.
A simulation by OFFENSAI demonstrated that when a defender executes aws iam delete-access-key --access-key-id AKIA... --user-name bob , an attacker can quickly follow with aws iam create-access-key --user-name bob . While CloudTrail logs record both actions, the consistency lag allows for persistence. This issue extends beyond keys to policy attachments, role deletions, and login profiles, increasing risks in incident response.
A critical persistence technique has been identified in AWS Identity and Access Management (IAM), linked to its eventual consistency model.
Traditional countermeasures, such as attaching deny-all policies like AWSDenyAll, face the same delay, as attackers can detect and detach them using polling APIs like ListAccessKeys.
AWS's Credential Cleanup Procedure advises waiting for full propagation periods, but this is ineffective against proactive attackers who preempt policy enforcement. Recent testing suggests partial fixes; a deleted key now prevents new key creation, but attackers can still detect changes and deploy assumable roles with AdministratorAccess from external accounts.
OFFENSAI recommends using account-level Service Control Policies (SCPs) via AWS Organizations to deny all actions for compromised principals, as attackers cannot control SCPs. Following propagation, proceed with cleanup. AWS acknowledged the issue in Apr 2025 and implemented development fixes and documentation updates without classifying it as a vulnerability. Retests shared on Dec 5, 2025, confirm their assessment, prompting revisions in standard playbooks.
No exploits have been identified in the wild. Organizations are advised to integrate delay considerations into detection rules and to prefer IAM roles and STS temporary credentials over long-term keys to reduce exposure.
Based on reporting by Cyber Security News.