Listen to this Post
Introduction:
The propagation delay in IAM changes is not a theoretical edge case—it’s a weapon for post-exploitation engineers. Eduard Agavriloae’s research demonstrates how the eventual consistency window (often 5–30 seconds) enables automated, self-healing administrator persistence that resists standard incident response playbooks.
Learning Objectives:
- Understand AWS IAM’s eventual consistency and its exploitation window for persistence.
- Deploy
notyet, a tool that automatically escalates privileges and defends against containment. - Implement a multi-layered containment strategy—including SCPs, permission boundaries, and automated runbooks—that actually works.
You Should Know:
1. Weaponizing the Propagation Window
IAM changes in AWS are not instantly applied. When an IAM policy is attached, detached, or modified, the new permissions propagate across AWS’s internal systems over a period of typically 3 to 10 seconds (though it can occasionally extend to 30 seconds or more). During this window, an attacker who already holds some level of access can detect and reverse any defensive actions taken against them.
The open-source tool `notyet` (developed by OffensAI) operationalizes this race condition. Once provided with any set of valid credentials (a user access key or a role session token), `notyet` enters a tight loop:
1. It attempts to escalate itself to `AdministratorAccess`.
2. It continuously monitors its own privileges.
- If a containment action (e.g., detaching a policy, deleting an inline policy, or disabling an access key) is detected, it immediately re-applies the `AdministratorAccess` policy.
- Because its monitoring is aggressive and its own API calls are fast, it often wins the race against the defender’s containment operations.
Step-by-step guide to simulate and test:
This guide assumes you have a dedicated, non-production AWS account for testing. Do not run this in a production environment.
1. Setup:
Clone the notyet repository git clone https://github.com/OffensAI/notyet.git cd notyet Install dependencies (Python 3.8+) pip install -r requirements.txt Configure AWS CLI with a set of IAM user credentials that have at least the "PowerUserAccess" policy attached aws configure
2. Run the Persistence Loop:
Execute the tool; it will immediately start escalating and defending its privileges python notyet.py
The output will show the tool’s activity, including attempts to attach AdministratorAccess, log entries showing the attached policy ARN, and a real-time counter of its “defense” actions.
3. Attempt to Contain (and Watch It Fail):
Open another terminal. Use the AWS CLI to try to revoke the access:
List the policies attached to your IAM user aws iam list-attached-user-policies --user-name <YOUR_USER_NAME> Try to detach the AdministratorAccess policy aws iam detach-user-policy --user-name <YOUR_USER_NAME> --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
Within seconds, check the policy again. The `notyet` tool in the other terminal will likely have re-attached it, nullifying your action.
2. The “Safe” Policy That Isn’t Safe: PowerUserAccess
A common “best practice” is to grant users the `PowerUserAccess` managed policy, which explicitly denies all IAM actions ("iam:"). However, as Agavriloae’s analysis shows, this is often a false sense of security. Attackers rarely need direct IAM privileges to become administrators.
`PowerUserAccess` allows a wide range of actions on other services, which can be chained together for privilege escalation. For example:
– Modify and Invoke Lambda: An attacker can modify a Lambda function’s code to include privilege escalation and then invoke it. If the Lambda function’s execution role has AdministratorAccess, the attacker now has admin rights.
– Exploit SSM Run Command: An attacker can use `ssm:SendCommand` on an EC2 instance that has a highly privileged IAM instance profile. By running a command that retrieves the instance’s metadata credentials, the attacker can obtain those elevated privileges.
– Alter CloudFormation: An attacker with `PowerUserAccess` can modify a CloudFormation stack to create a new IAM user with admin rights as part of its next update.
Step-by-step guide for mitigation:
The only truly effective remediation is to eliminate `PowerUserAccess` entirely.
1. Inventory and Replace:
- Use AWS IAM Access Analyzer to generate a list of actual permissions used by each identity that currently has
PowerUserAccess. - Create a new, custom IAM policy that grants only those specific actions (the principle of least privilege).
2. Implement Strict Permission Boundaries:
- A permission boundary is an advanced feature that sets the maximum permissions an IAM user or role can ever be granted.
- The following command attaches a boundary that completely blocks the creation of any new IAM resources, which would stop most escalation paths from
PowerUserAccess. - Command:
aws iam put-user-permissions-boundary --user-name <USER_NAME> --permissions-boundary arn:aws:iam::aws:policy/PowerUserAccess
Note: Using `PowerUserAccess` as a boundary for a user who also has `PowerUserAccess` creates a more restrictive set, but for true prevention, a custom, tightly scoped boundary is recommended.
- The CloudQuarry Blind Spot: Public Images Across Clouds
The research that started many of these threads, “AWS CloudQuarry,” found hundreds of valid, live secrets in public Amazon Machine Images (AMIs). Developers unknowingly made their VM snapshots public, and these images contained hardcoded API keys, SSH private keys, and even full Git repositories with sensitive data.
The scale is staggering: over 3 million public AMIs on AWS, compared to just over 8,000 public images on GCP. In one real-world case, researchers found a public AMI containing a private Git repository that held a Stripe API key with access to over $30,000.
The disparity is due to policy. AWS allows any user to make an AMI public. GCP restricts public image publishing to marketplace vendors and approved publishers. This fundamental difference in governance creates a massive, and largely overlooked, attack surface.
Tutorial: How to scan your own (or a public) AMI for secrets using TruffleHog:
This process is manual but provides the most thorough analysis.
- Identify the target AMI ID (e.g.,
ami-0abcdef1234567890) and the region it resides in.
2. Launch a temporary analysis EC2 instance:
aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.micro --subnet-id <YOUR_SUBNET_ID>
Note the Instance ID of the launched instance.
- For an instance that is already running, create a disk snapshot of its root volume:
aws ec2 create-snapshot --volume-id <VOLUME_ID> --description "For secret scanning"
-
Create a new volume from the snapshot and attach it to a trusted, your own analysis instance:
aws ec2 create-volume --snapshot-id <SNAPSHOT_ID> --availability-zone <ANALYSIS_INSTANCE_AZ> aws ec2 attach-volume --volume-id <NEW_VOLUME_ID> --instance-id <ANALYSIS_INSTANCE_ID> --device /dev/sdf
-
On the analysis instance, mount the volume and run TruffleHog:
Mount the volume sudo mkdir /mnt/target sudo mount /dev/sdf1 /mnt/target Run TruffleHog on the mounted directory trufflehog filesystem --directory /mnt/target
-
Hardening Detection and Response for Cloud Race Conditions
Defending against notyet-style, consistency-abusing persistence requires moving beyond standard IR playbooks. Manual revocation attempts will likely fail.
Command-Based, Resilient Containment Strategy:
The `AWSSupport-ContainIAMPrincipal` SSM automation runbook is a good start, but it is not sufficient against notyet. A multi-layered, programmatic approach is required:
- Step 1 – Apply a Denying SCP (Fastest, Most Reliable):
If the compromised identity is in an AWS Organization, attach a Service Control Policy (SCP) that explicitly denies all actions for that principal. SCPs are evaluated outside of IAM and are not subject to the same consistency delays.
– SCP JSON block:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCompromisedPrincipal",
"Effect": "Deny",
"Action": "",
"Resource": "",
"Condition": {
"StringEquals": {
"aws:PrincipalARN": "arn:aws:iam::<ACCOUNT_ID>:user/<COMPROMISED_USER>"
}
}
}
]
}
- Step 2 – Nuke the Keys and Change the Password:
While SCPs are applying, execute these commands in rapid succession. Their effectiveness is secondary to the SCP.Disable the access key aws iam update-access-key --access-key-id <KEY_ID> --status Inactive Change the password for the IAM user (force a logout) aws iam create-login-profile --user-name <USER_NAME> --password <NEW_STRONG_PASSWORD> --password-reset-required
-
Step 3 – The “Nuclear” Option: Delete the IAM User:
If the identity is disposable, delete it. This action is very fast.aws iam delete-user --user-name <COMPROMISED_USER>
Note: Deleting a user will irrevocably delete all associated keys and credentials.
-
Future-Proofing: A Lesson in Cloud’s Shared Fate Model
These vulnerabilities are not “bugs” but features of how AWS was built for availability and scale. The eventuality in eventual consistency is a deliberate design trade-off, and `notyet` shows us exactly where the fault line lies for security. Attackers have the same 5–10 second window that every AWS API call experiences; they simply choose to use it for defense rather than offense.
The ultimate lesson is that in cloud environments, the defender is no longer the sole player in the “race” for containment. The adversary can now run automated scripts that react to your IR actions in real-time, leveraging their own consistent view of the control plane. The path forward is to build an IR strategy that operates at machine speed, uses SCPs for near-instant containment, and assumes that any remediation that goes through the IAM service is a step the attacker can see and counter.
What Undercode Say:
- Eventual consistency is a double-edged sword. It is a foundational cloud concept for availability, but Agavriloae’s `notyet` proves it’s a first-class vector for offensive persistence.
- The IAM control plane is not an instant “off switch.” Traditional IR playbooks that rely on policy detachment or key revocation need to be revised and augmented with SCPs and automated tooling.
Prediction:
Within 18 months, major cloud providers will release “emergency containment” API endpoints that bypass standard IAM propagation, creating a new, faster pathway for defenders. Concurrently, we will see an explosion of “race condition” exploitation tools for cloud environments, moving these tactics from esoteric research into standard C2 frameworks. The market for automated, runtime-based detection and response for cloud infrastructure will triple as organizations wake up to the fact that their identity containment processes are fundamentally broken.
▶️ 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 ✅
