Article Title:
Exploiting AWS IAM’s Eventual Consistency: A New Persistence Threat
In the ever-evolving landscape of cloud security, a recent discovery has unveiled a critical persistence technique within Amazon Web Services’ (AWS) Identity and Access Management (IAM) system. This technique exploits the eventual consistency model of IAM, allowing attackers to maintain unauthorized access even after defenders have deleted compromised access keys.
Understanding Eventual Consistency in AWS IAM
AWS IAM, like many distributed systems, employs an eventual consistency model to ensure scalability across various regions and replicas. In this model, updates to resources such as access keys or policies do not propagate instantaneously but instead have a predictable delay. Testing by security firm OFFENSAI has confirmed that this delay is approximately 3 to 4 seconds across regions like us-east-1 and eu-central-1.
During this brief window, deleted access keys remain valid for API calls. This means that an attacker, upon detecting the deletion of a compromised key, can quickly list existing keys (receiving an empty array) or generate new ones before the invalidation process completes.
Exploitation Scenario
Consider a scenario where a defender executes the command:
“`bash
aws iam delete-access-key –access-key-id AKIA… –user-name bob
“`
In response, an attacker, monitoring for such changes, rapidly follows with:
“`bash
aws iam create-access-key –user-name bob
“`
While AWS CloudTrail logs accurately record both the deletion and subsequent actions, the consistency lag permits the attacker to re-establish access before the deletion fully propagates. This vulnerability extends beyond access keys to policy attachments, role deletions, and login profiles, amplifying risks during incident response efforts.
Challenges with Traditional Mitigation Strategies
Traditional security playbooks may fall short in addressing this issue. For instance, attaching deny-all policies like `AWSDenyAll` during an incident response might not be effective. Attackers can detect such changes and detach them by continuously polling APIs like `ListAccessKeys`.
AWS’s own Credential Cleanup Procedure, as published on re:Post, advises waiting for full propagation periods. However, this approach proves inefficient against proactive attackers who can preempt policy enforcement during the consistency delay.
AWS’s Response and Recommendations
Following the disclosure of this issue, AWS acknowledged the findings in April 2025. They have since applied development fixes and updated documentation, though they did not classify it as a vulnerability. Subsequent testing revealed partial fixes; for example, a deleted key now blocks the creation of new keys. However, gaps persist, as attackers can still detect changes and deploy assumable roles with `AdministratorAccess` from external accounts.
OFFENSAI recommends implementing account-level Service Control Policies (SCPs) via AWS Organizations to deny all actions for compromised principals. This approach is effective because attackers typically lack control over SCPs. After the propagation period, defenders can proceed with cleanup operations.
Proactive Measures for Organizations
While no in-the-wild exploits have been reported, organizations should integrate awareness of these delays into their detection rules. Favoring IAM roles and Security Token Service (STS) temporary credentials over long-term keys can also minimize exposure.
In conclusion, understanding and mitigating the implications of AWS IAM’s eventual consistency model is crucial for maintaining robust cloud security. By revising incident response playbooks and implementing recommended strategies, organizations can better defend against this emerging persistence threat.
