Listen to this Post
Introduction:
A little-known architectural feature of AWS IAM called “eventual consistency” creates a 3-to-4-second propagation window when changes like policy detachments or access key deletions are not yet effective across the entire global infrastructure. Researchers at OFFENSAI have developed notyet, an open‑source tool that weaponizes this window, allowing a compromised identity to automatically detect and reverse any defensive action in real time, effectively “vaporizing” standard incident response playbooks.
Learning Objectives:
- Understand the mechanics of AWS IAM eventual consistency and how it creates an exploitable persistence window for attackers.
- Learn how to deploy the open‑source `notyet` tool to stress‑test the resilience of your AWS containment playbooks.
- Master step‑by‑step defensive commands and Service Control Policy (SCP) strategies to harden your cloud environment against eventual consistency abuse.
You Should Know:
1. Weaponizing the Propagation Window
AWS IAM changes do not take effect instantly. When you detach a policy, delete an access key, or remove an IAM user, those updates are written to a primary database and then replicated across read‑only replicas and edge caches. During this propagation window—typically 3 to 4 seconds—the old permissions remain valid. An automated attacker operating within that window can detect the defender’s action and surgically reverse it before it ever applies.
Step‑by‑step guide – Simulating the attack (for defensive understanding):
1. Gain initial access to an IAM user or role with at least PowerUserAccess.
2. Clone and run notyet (Python 3.8+ required):
git clone https://github.com/OffensAI/notyet.git cd notyet pip install -r requirements.txt aws configure Use credentials with PowerUserAccess python notyet.py
The tool immediately enters a tight loop: it escalates to `AdministratorAccess` and monitors the identity’s status every 0.5 seconds. It will re‑attach its admin policy the moment it detects any revocation attempt.
3. Attempt containment from another terminal and watch it fail:
List attached policies aws iam list-attached-user-policies --user-name <YOUR_USER_NAME> Try to detach the admin policy aws iam detach-user-policy --user-name <YOUR_USER_NAME> --policy-arn arn:aws:iam::aws:policy/AdministratorAccess Try to delete the access key aws iam delete-access-key --user-name <YOUR_USER_NAME> --access-key-id <KEY_ID>
Within the propagation window, `notyet` recreates the access key or re‑attaches the policy, rendering your actions ineffective.
2. Why Standard “Revoke and Delete” Playbooks Fail
Traditional IR guidance tells you to revoke sessions, delete access keys, and attach a deny‑all policy. Against an eventual‑consistency attacker, these steps are not atomic. The table below, extracted from notyet’s documentation, shows which defender actions the tool survives:
| Defender Action | Access Keys (AKIA) | Role Session (ASIA) |
|-|–|–|
| Disable/delete access key | Survives | N/A |
| Delete user | Survives | N/A |
| Delete role | N/A | Survives |
| Session expiry | N/A | Survives (proactive refresh) |
| Add inline/managed deny policy | Survives | Survives |
| Add permission boundary | Survives | Survives |
| Modify/delete the tool’s own policy | Survives | Survives |
| Add user to a group with deny | Survives | N/A |
| Service Control Policy (SCP) | Blocked | Blocked |
As shown, only SCPs—applied at the AWS Organizations level—are reliable against this persistence technique. IAM‑native deny policies, access key deletion, and even identity deletion are all evaded within the 3‑second window.
- Defensive Hardening: The SCP is Your Only Reliable Weapon
Because SCPs are evaluated before any IAM policy and are enforced across all accounts in an organization, they are not subject to eventual consistency delays. Once an SCP is attached, it takes effect immediately, blocking the compromised identity’s API calls regardless of what the `notyet` loop does.
Step‑by‑step guide – Implementing an emergency SCP:
- Navigate to AWS Organizations → Policies → Service Control Policies.
- Create a new policy with the following JSON to block all actions for a specific IAM principal:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "", "Resource": "", "Condition": { "StringEquals": { "aws:PrincipalArn": "arn:aws:iam::123456789012:user/compromised_user" } } } ] } - Attach this SCP to the organizational unit (OU) or to the root of the affected account.
- Warning: SCPs affect all identities in the account. Use them judiciously and have a break‑glass procedure ready.
After applying the SCP, the `notyet` loop will receive `AccessDenied` on every API call, including its policy monitoring and credential rotation attempts. The tool’s own persistence matrix confirms that SCP is the only mechanism that blocks it.
4. Emergency Local Account Lockdown (Temporary Mitigation)
If you cannot immediately deploy an SCP, a multi‑layered shutdown can slow the attacker down. Combine several actions to increase the chance that one of them propagates before the tool reacts:
1. Detach all managed policies aws iam detach-user-policy --user-name <USER> --policy-arn <POLICY_ARN> 2. Delete all inline policies aws iam delete-user-policy --user-name <USER> --policy-name <INLINE_NAME> 3. Delete the user’s access keys aws iam delete-access-key --user-name <USER> --access-key-id <KEY_ID> 4. Delete the IAM user itself (this is often the most disruptive) aws iam delete-user --user-name <USER> 5. Enable a permission boundary that denies everything aws iam put-user-permissions-boundary --user-name <USER> --permissions-boundary arn:aws:iam::aws:policy/DenyAll
Execute these commands simultaneously (e.g., using parallel SSH sessions) to increase the probability that one of them takes effect outside the tool’s monitoring loop. Then immediately proceed with an SCP.
5. Building a Resilient Incident Response Workflow
The existence of `notyet` proves that your IR playbooks must include SCP‑based emergency containment as the first step, not the last. OFFENSAI’s collaboration with Sonrai Security showed that even sophisticated automated playbooks like the `AWSSupport-ContainIAMPrincipal` SSM runbook can be evaded if they rely solely on IAM‑level changes. The only reliable two‑step process is:
1. Detect the compromise (e.g., via GuardDuty or CloudTrail).
2. Contain immediately by applying a blocking SCP at the Organization level.
3. Investigate the root cause while the identity is effectively dead.
4. Recover by rotating all credentials, removing the SCP, and rebuilding the identity from a trusted baseline.
Integrate this into your existing AWS Systems Manager Incident Manager runbooks and test regularly using `notyet` in a non‑production environment.
6. Training and Certification for Cloud IR Teams
To prepare your team for this attack class, consider the following AWS‑focused training offerings that cover advanced Incident Response and IAM hardening:
– DFIR in AWS (W63) – covers digital forensics, incident response, and automation in AWS environments.
– AWS Certified Security – Specialty (SCS-C02): Threat Detection and Incident Response – teaches detection, containment, and recovery strategies using native AWS tools.
– Security Engineering on AWS with AWS Jam – hands‑on labs that include building resilient, security‑focused architectures.
– AWS Incident Response (DCTAC2025) – a deep‑dive course focusing on real‑world IR scenarios and advanced persistence.
Combine these with practical, offensive‑minded tools like `notyet` to conduct regular red‑blue team exercises that stress‑test your actual playbooks.
7. Extending the Attack Surface Beyond IAM
While `notyet` focuses on IAM, eventual consistency affects many AWS services. EC2 security group updates, S3 bucket policies, and VPC route table changes also experience propagation delays. In the future, attackers may generalise this technique to maintain persistence in compute, storage, and networking layers. Defenders must therefore apply the same SCP‑first containment to any suspicious resource, not just IAM identities.
What Undercode Says:
- Key Takeaway 1: AWS IAM eventual consistency is not a theoretical edge case – it is a weaponisable persistence primitive. Tools like `notyet` demonstrate that attackers can automatically defeat standard “revoke and delete” playbooks by operating inside the 3‑to‑4‑second propagation window.
- Key Takeaway 2: The only reliable mitigation against this attack is the immediate application of a Service Control Policy at the AWS Organizations level. IAM‑native deny policies, key deletion, and even user deletion are all evadable. Your incident response playbooks must include SCP‑based containment as the first, not the last, line of defence.
Prediction:
As more security teams adopt infrastructure‑as‑code and automated IR runbooks, attackers will increasingly shift toward exploiting foundational distributed‑systems properties like eventual consistency, rather than individual misconfigurations. We anticipate a wave of “consistency‑attacks” across major cloud providers – not just AWS – as researchers reverse‑engineer propagation delays in Azure AD, GCP IAM, and Kubernetes RBAC. In the short term, AWS will need to accelerate its long‑standing effort to make IAM changes strongly consistent, or at least provide a synchronous “confirm propagation” API for security operations. Until then, enterprises must treat eventual consistency as a critical risk and redesign their cloud IR strategies around organisational‑level controls that bypass the IAM replication delay entirely. The `notyet` tool is a wake‑up call: your incident response is only as strong as the weakest consistency model.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Eduard K – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
