Hackers Abuse AWS IAM Eventual Consistency To Maintain Persistent Access

Attackers can keep access to AWS accounts even after admins delete compromised keys.

New research from OffensAI shows how AWS Identity and Access Management (IAM) eventual consistency creates a 4-second window for persistence.

During this gap, deleted access keys still work, letting hackers create new credentials or detect changes before defenses kick in.

This flaw challenges standard incident response and key rotation practices.

How Attackers Exploit The 4-Second Window

AWS IAM relies on eventual consistency to scale across regions. Updates such as key deletions or policy changes can take up to 4 seconds to fully propagate.

Tests across regions like us-east-1 and eu-central-1 confirm this predictable delay.

Consider a compromise: Admins delete keys for user “bob” with this command:

aws iam delete-access-key --access-key-id AKIA3P... --user-name bob

In the next 1-3 seconds, the attacker still using the “deleted” key runs:

aws iam create-access-key --user-name bob

The old key works, generating new ones before invalidation at T+4s. Attackers can poll ListAccessKeys every 3 seconds; an empty array signals deletion, leaving time to act.

Policy tweaks fail, too. Attaching a deny-all policy:

aws iam attach-user-policy --user-name compromised-user --policy-arn arn:aws:iam::aws:policy/AWSDenyAll

Gives attackers the same Window to detect and detach it via DetachUserPolicy. CloudTrail logs these events correctly, but many detection rules miss them.

The issue hits more IAM ops: policy attach/detach, role assumptions, creations, and login profiles.

Mitigation Steps and Disclosure Timeline

Block actions at the account level with AWS Organizations Service Control Policies (SCPs), which attackers can’t touch:

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

Wait 4+ seconds, then rotate keys and clean up. Alternatives: Use temporary STS credentials or IAM roles, or raise an AWS support ticket for quarantine.

AWS fixed new key creation after deletion, but left the detection windows open.

OffensAI disclosed responsibly:

• Discovery: Apr 18, 2025
• Reported: Apr 19, 2025
• AWS triage: Apr 20, 2025
• Acknowledgment: Apr 28, 2025
• Fix meeting: Nov 20, 2025
• Retest: Dec 5, 2025

Follow us on Google News , LinkedIn and X to Get More Instant Updates, Set Cyberpress as a Preferred Source in Google.