Hackers Exploit AWS IAM Eventual Consistency for Persistence

Hackers Exploit AWS IAM Eventual Consistency for Persistence

A critical persistence technique in AWS Identity and Access Management (IAM) stemming from its eventual consistency model, allowing attackers to retain access even after defenders delete compromised access keys.

AWS IAM, like many distributed systems, employs eventual consistency to scale 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 across regions like us-east-1 and eu-central-1.

During this window, deleted keys remain valid for API calls, enabling attackers to list keys receiving an empty array or generate new ones before invalidation completes.​

Access key used after deletion
Access key used after deletion

Security firm OFFENSAI has uncovered that in a simulated attack, a defender executes aws iam delete-access-key –access-key-id AKIA… –user-name bob, while the attacker rapidly follows with aws iam create-access-key –user-name bob.

CloudTrail logs accurately record both the deletion and subsequent actions, yet the consistency lag permits persistence. This extends beyond keys to policy attachments, role deletions, and login profiles, amplifying risks in incident response.​

Persistence within keys
Persistence within keys

Traditional playbooks fail here: attaching deny-all policies like AWSDenyAll yields the same window, as attackers detect and detach them via polling ListAccessKeys or similar APIs.

google

AWS’s own Credential Cleanup Procedure, published on re:Post, advises waiting full propagation periods but proves inefficient against proactive attackers who preempt policy enforcement.

Post-disclosure testing revealed partial fixes. A deleted key now blocks new key creation, but gaps persist. Attackers can still detect changes and deploy assumable roles with AdministratorAccess from external accounts.

OFFENSAI recommends account-level Service Control Policies (SCPs) via AWS Organizations to deny all actions for compromised principals, as attackers lack SCP control.

After propagation, proceed with cleanup. AWS acknowledged the findings in April 2025, applying development fixes and documentation updates without classifying it as a vulnerability. Retests shared on December 5, 2025, align with their assessment, urging playbook revisions.​

No in-the-wild exploits surfaced. Organizations should integrate such delays into detection rules, favoring IAM roles and STS temporary credentials over long-term keys to minimize exposure.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.

googlenews



Source link