Exploiting AWS IAM Eventual Consistency for Persistence

Deleted your compromised AWS access keys? Because of AWS IAM eventual consistency, they might still work. OFFENSAI's research reveals how AWS IAM eventual consistency creates a persistence window attackers can exploit, where updates such as access key deletion or policy changes do not take effect immediately.

We identified a pitfall when it comes to disabling AWS Access Keys that extends across other AWS IAM resources as well. The cause is eventual consistency in AWS Identity and Access Management and, if improperly handled, can be exploited by attackers to have access in your AWS environment, even after defenders believe credentials are revoked.

This adds a new layer of risk to traditional AWS access key rotation and revocation processes.

Understanding Eventual Consistency

Engineering global decentralized systems for a big user base is challenging. Handling the day-to-day compute load often requires scaling in multiple directions as described by the AKF Scale Cube:

• Horizontally (X-axis) by cloning/replicating identical instances across multiple servers or regions
• Functionally (Y-axis) by decomposing the system into separate services/microservices based on different functions
• Through data partitioning (Z-axis) by splitting similar data or users across different shards or partitions

While these scaling strategies improve system performance and availability, they introduce complexity around data consistency. When data is replicated across multiple regions or database replicas, updates don't propagate instantaneously. This creates windows where different parts of the system may have different views of the same data. Let's examine this generic example:

Scenario: Admin downgrades user from "admin" to "read-only". The users permissions database has read-only replicas across multiple regions.

• T+0s: Permission downgrade written to primary DB (US-East)
• T+1s: User (EU region) deletes critical data - EU replica still shows "admin" ✓
• T+2s: User modifies system settings - still has elevated access ✓
• T+4s: EU replica updates - user finally loses admin privileges ✗

While the system eventually reaches consistency, there is a 4-second window where the user retains unauthorized admin access. Eventual consistency is generally acceptable for many use cases, but as we will detail next, special security concerns arise when handling authorization in weakly consistent architectures.

Security Risks When Rotating AWS Access Keys

Consider this common scenario of improperly disabling AWS access keys:

A set of access keys are found to be compromised and the security team (the defenders) attempt to directly disable or delete the access key set. Let's assume that the user 'bob' was compromised, the attacker escalated privileges to administrator and that the following commands are executed on the defender's machine if the profile is 'defender' and on the attacker's machine when the profile is 'attacker'.

What do you think happens when the next two commands are executed one after another?

# Security team rotates compromised access keys
aws --profile defender iam delete-access-key --access-key-id AKIA3P... --user-name bob
 
# Attacker creates new set of access keys right after the keys are deleted
aws --profile attacker iam create-access-key --user-name bob

If the attacker executes their command immediately after the defender's command, because of the eventual consistency, the compromised keys are still considered valid after deletion. Very opportunistic, I know, but we can overcome that as we'll see later on.

The Security Window:

• T+0s: Security team deletes compromised AWS access key (AKIA3P...) for user bob
• T+1-3s: Attacker uses the same key that was deleted to create a new set of access keys
• T+4s: IAM propagation complete - old key fully invalidated

The Risk: The distributed nature of AWS infrastructure means that credential validation, caching layers, and edge services may create brief windows where revoked access keys remain temporarily valid. In short, the attacker can use a deleted set of access keys to create a new one, achieving persistence this way.

AWS IAM's Predictable "Eventual" Consistency

Eventual consistency in AWS is very consistent when it comes to the propagation time. In each of our tests, even when the region of the defender/attacker were us-east-1/eu-central-1 or both having the same region, the propagation time was always close to, but slightly less than 4 seconds.

Removing the Opportunistic Aspects

The scenario where the attacker would create a new set of AWS access keys in the ~4 seconds available after the defender deletes them is very opportunistic. It doesn't have to be that way. In those ~4 seconds, any request can be made, including listing the access keys of your user. Weirdly, when you list your access keys in those ~4 seconds after deletion, you will get an empty array, indicating that the keys were in fact deleted.

The attacker can check every 3 seconds if their keys were deleted via the IAM ListAccessKeys API call. When the response is an empty array, it means that the keys were deleted. At this point the attacker can create a new set of AWS access keys in the remaining time window before the eventual consistency is reached.

The Gaps In Current Incident Response Playbooks

Addressing AWS IAM eventual consistency during security incidents presents bigger challenges than expected. So challenging that traditional remediation approaches fail to properly handle.

Policy-Based Restrictions Are Ineffective

Attempting to restrict a compromised user through AWS IAM policies is susceptible to the same problem. Even if you add the AWSDenyAll or a Session policy to the user, the attacker has the same ~4 seconds time window to detect the new policy and remove it. The same goes for disabling the access credentials.

# This approach fails during the consistency window
aws --profile defender iam attach-user-policy \
    --user-name compromised-user --policy-arn arn:aws:iam::aws:policy/AWSDenyAll

Effective Mitigation Strategy

The most reliable approach involves leveraging AWS Organizations Service Control Policies (SCPs), which operate at the account level. Given that the attacker doesn't have control over the SCPs, this will prevent them from both detecting and modifying the SCP.

1. Apply an SCP that denies all actions for the compromised principal
2. Allow the full ~4 second propagation period to complete
3. Proceed with traditional key rotation and policy cleanup

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCompromisedUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:user/compromised-user"
        }
      }
    }
  ]
}

An alternative solution is to raise a ticket to AWS and allow them to quarantine the access credentials.

How Does CloudTrail Handle This?

An immediate question we had was how CloudTrail handled these events. It seems that CloudTrail works as expected even if the logs don't follow what you would think to be logically accurate.

In the image below, the user 'eduard' deleted a set of access keys, and then the same access keys were used to perform the API calls "ListAccessKeys" and "CreateAccessKeys".

While we were happy to see that CloudTrail is working as expected, we couldn't help ourselves but ask how many detection solutions and rules are covering cases like this one.

Going Beyond AWS Access Keys

Our research into AWS IAM's eventual consistency behavior revealed that this 4-second security window extends beyond AWS Access Keys and impacts multiple IAM operations. During our research, we systematically tested multiple IAM resources and identified similar vulnerabilities across the IAM ecosystem.

Through comprehensive testing, we discovered that the following IAM operations exhibit the same eventual consistency vulnerability:

• Policy attachment/detachment
• Role assumption permissions
• Role creation and deletion
• Login profile changes

This persistence window can be combined with other identity-based techniques we’ve documented, such as attacker-controlled OIDC providers enabling long-term AWS persistence via RogueOIDC.

Coordinated Disclosure Process

Following responsible disclosure practices, we reported these findings to the AWS Security Team through their vulnerability disclosure program.

AWS acknowledged the findings and confirmed that this behavior stems from their distributed architecture design. While not classified as a vulnerability per se, they recognized the security implications for incident response procedures and chose to address the issue both from a development perspective, and providing better documentation around the topic.

In response, AWS applied a fix and published a blog article that tackles the aspect of eventual consistency: Credential Cleanup Procedure

The AWS Public statement

IAM uses a distributed computing model called eventual consistency. This means any changes that you make in IAM (or other AWS services) take time to become visible across endpoints. Some delay results from the time it takes to send data from server to server, replication zone to replication zone, and Region to Region. IAM also uses caching to improve performance, but in some cases this can add time. The change might not be visible until the previously cached data times out. AWS recommends that customers implement security best practices and design their applications to account for these delays. For example, customers should avoid long-term IAM access keys because of their indefinite validity and potential for theft or accidental disclosure create risk. Instead, customers should use temporary credentials, generated via the AWS Security Token Service (STS), or leverage IAM roles and federation for programmatic access to AWS services, as these methods offer time-limited access that automatically expires. We recommend you follow the runbook we have published on re:Post to address this: Credential Cleanup Procedure.

Retesting

Is the issue fixed now? Kind of, but not really. The current fix prevents a set of deleted AWS access keys to create a new one.

However, there is still a time window while you can detect IAM data changes without the authorization controls to come into effect. Because of this, it is possible to detect if the AWS access keys are deleted and create a role assumable by an external account with AdministratorAccess attached to it.

Additionally, the recommendation proposed by AWS in the Credential Cleanup Procedure is inefficient. The compromised credentials can detect when a new policy was attached to their user and simply remove it before it comes into effect.

In the image below, the defender (right side) attaches an even more restrictive policy to the attacker user. The attacker can continuously look for new permissions attached to them, identify the new policy and simply remove it before it comes into effect. This renders the official recommended action inefficient.

How can OFFENSAI help

OFFENSAI is an AI-driven adversarial validation platform built to behave like the attacker you hope never shows up. Using proprietary generative adversarial models and unpublished attack vectors, it uncovers real, exploitable kill chains and pairs each finding with one-click remediation guidance, all through continuous, safe simulations that never disrupt production.

And when we uncover techniques like the persistence via AWS eventual consistency and similar vendor undisclosed vulnerabilities, we don't wait for the ecosystem to catch up. OFFENSAI deploys detection rules for undisclosed or unaddressed vulnerabilities. What this means:

• We don't disclose attack vectors until they're addressed by the vendor
• You get detection rules from day 1 on our discovery
• You stay protected during the weeks or months until official patches or mitigations are available

These scenarios highlight why organizations benefit from continuous red teaming for cloud security, ensuring that IAM weaknesses are surfaced long before attackers find them.

Why This AWS IAM Consistency Issue Matters

The issue remains present to a certain degree, and we expect this to become a known technique for achieving persistence. AWS received the results of our retest and confirmed that their initial assessment aligns with the findings. We recommend engineers adjust their AWS IAM detection rules and incident response playbooks accordingly.

No in-the-wild exploitation was identified during the detection period.

Disclosure timeline

• Initial discovery: Apr 18, 2025
• Reported to AWS Security Team: Apr 19, 2025
• Triage first response from AWS: Apr 20, 2025
• AWS first response and acknowledgment: Apr 28, 2025
• Meeting with AWS security team: Jul 28, 2025
• Fix confirmation meeting with AWS: Nov 20, 2025
• Retest results sharing and AWS acknowledgement: Dec 05, 2025