AWS Incident Response: IAM Containment That Survives Eventual Consistency

In a previous article, we demonstrated how AWS IAM eventual consistency creates a ~4-second window that attackers can exploit to achieve persistence, even after defenders believe a compromised identity has been locked down. We showed that the official AWS recommendation and current Incident Response playbooks are ineffective, because the attacker can revert the containment during the ~4 seconds propagation window, including removing a DenyAll policy that was just attached.

This article offers an alternative to the account-level isolation that closes the policy detachment gap: using AWS Service Control Policies (SCPs) to make a quarantine policy irremovable by anyone except a designated incident response role.

The Current State of AWS Incident Response Playbooks

When a cloud identity is compromised, the standard response is well understood: revoke credentials, restrict permissions, investigate, remediate. The main containment approaches documented across AWS IR guidance, CISA joint advisories, and practitioner playbooks fall into two categories:

1. Account-level isolation

Involves moving the compromised AWS account into a quarantine Organizational Unit (OU) with a restrictive SCP attached. This is the approach favored by the AWS Customer Incident Response Team (CIRT) and is well-documented. Here the entire account is locked down, all workloads are affected, and the action is highly visible and disruptive.

2. Identity-level isolation

Involves attaching a deny-all policy directly to the compromised IAM user or role, disabling access keys, and revoking active sessions. This is more surgical, but as our previous research showed, it is susceptible to the eventual consistency window where the attacker can race the defender and remove the policy before it takes effect. AWS published a Credential Cleanup Procedure on re:Post in response to our disclosure. We will examine it in detail in the next section.

Quarantine OUs vs. Identity-Level Containment

Both quarantine OU isolation and identity-level containment are valid IR strategies. Each comes with tradeoffs, and the right choice depends on the specifics of the incident.

Moving a compromised account to a quarantine OU is highly effective. SCPs at the OU level apply immediately and cannot be modified by any principal within the member account. The tradeoff is scope: it affects every workload, service, and identity in the account simultaneously. In a production environment this means customer-facing services, background jobs, and internal tooling are all impacted. It also requires management account access and careful coordination, which introduces operational risk if executed during an active incident without a mature runbook.

Identity-level containment is more surgical and it targets only the compromised principal without disrupting the rest of the account. The tradeoff is enforcement: as we demonstrated in our previous research, managed policy attachments can be raced and removed by an attacker within the eventual consistency window, making this approach unreliable on its own.

We do not recommend one approach over the other. The right call depends on the blast radius of the incident, the criticality of workloads in the account, and the maturity of your Organizations runbook. What we do provide is a way to make identity-level containment reliable when that is the approach your team chooses, closing the enforcement gap that currently makes it fall short against an active attacker.

The AWS Official Recommendation (And Why It Falls Short)

Following our responsible disclosure, AWS published a Credential Cleanup Procedure on re:Post. The runbook is thorough in several respects, and it walks through a structured sequence: attach a deny policy scoped to credential management actions, nullify active sessions using a time-conditioned policy, rotate access keys, and clean up after confirmation.

The credential management deny policy recommended by AWS looks like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
 
                "iam:ChangePassword",
                "iam:CreateLoginProfile",
                "iam:UpdateLoginProfile",
                "iam:DeleteLoginProfile",
 
                "iam:CreateVirtualMFADevice",
                "iam:DeactivateMFADevice",
                "iam:DeleteVirtrualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice",
 
                "iam:CreateServiceSpecificCredential",
                "iam:DeleteServiceSpecificCredential",
                "iam:ResetServiceSpecificCredential",
                "iam:UpdateServiceSpecificCredential",
 
                "iam:DeleteSigningCertificate",
                "iam:UpdateSigningCertificate",
                "iam:UploadSigningCertificate",
 
                "iam:DeleteSSHPublicKey",
                "iam:GetSSHPublicKey",
                "iam:UpdateSSHPublicKey",
                "iam:UploadSSHPublicKey",
                
                "iam:PassRole",
                
                "sts:AssumeRole",
                "sts:GetFederationToken"
            ],
            "Resource": "*"
        }
    ]
}

For session revocation, the runbook additionally recommends a time-conditioned policy to nullify any active sts:GetSessionToken sessions by denying requests where aws:TokenIssueTime predates the current timestamp.

This is good guidance, and the intent is right. However, an attacker who has already escalated to administrator retains iam:DetachUserPolicy even after the credential management deny policy is attached. They can poll for new policy attachments and detach them within the eventual consistency window before lockout takes effect. Our monitor script demonstrated exactly this, successfully detaching IR-QuarantinePolicy milliseconds after it was attached, before propagation completed.

In the image below we can see that the attacker runs a script that checks for new policies and removes them as they are attached. In the right terminal the defender applies an Incident Response policy that is denying all actions against all resources:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAll",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

The session revocation policy has the same problem. It is itself a managed policy attachment, subject to the same detachment race. An active attacker who detaches both the credential deny policy and the session revocation policy before propagation retains their live sessions and their persistence.

What is needed is an enforcement layer that is entirely outside the attacker's reach.

The Fix: SCP-Enforced Quarantine Policy Protection

The solution is to use a Service Control Policy to make the quarantine policy irremovable by anyone except a designated IR role. SCPs operate at the AWS Organizations level, outside the control of any principal within the member account. An attacker who has compromised an IAM identity, regardless of their privilege level within the account, cannot modify, detach, or circumvent an SCP.

The SCP OFFENSAI team developed protects three specific attack surfaces:

Policy detachment — prevents iam:DetachUserPolicy and iam:DetachRolePolicy when the policy being detached is IR-QuarantinePolicy, for any principal that is not the IR role.

Policy deletion — prevents iam:DeletePolicy directly on the IR-QuarantinePolicy ARN, closing the path where an attacker deletes the policy object entirely.

Policy overwrite — prevents iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion on the quarantine policy ARN, closing the path where an attacker replaces the deny-all content with an allow-all without detaching it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectQuarantinePolicyDetachment",
      "Effect": "Deny",
      "Action": [
        "iam:DetachUserPolicy",
        "iam:DetachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "ArnEquals": {
          "iam:PolicyArn": "arn:aws:iam::*:policy/IR-QuarantinePolicy"
        },
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_IR-Engineer_*"
        }
      }
    },
    {
      "Sid": "ProtectQuarantinePolicyFromDeletion",
      "Effect": "Deny",
      "Action": [
        "iam:DeletePolicy"
      ],
      "Resource": "arn:aws:iam::*:policy/IR-QuarantinePolicy",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_IR-Engineer_*"
        }
      }
    },
    {
      "Sid": "ProtectQuarantinePolicyFromOverwrite",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:SetDefaultPolicyVersion"
      ],
      "Resource": "arn:aws:iam::*:policy/IR-QuarantinePolicy",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_IR-Engineer_*"
        }
      }
    }
  ]
}

The key technical detail in Statement 1 is the use of the iam:PolicyArn condition key. Unlike Resource, which for iam:DetachUserPolicy refers to the user being modified rather than the policy being detached, iam:PolicyArn specifically captures which managed policy is the subject of the operation. This allows the SCP to be scoped precisely to the quarantine policy without blocking any other IAM operations across the account.

The Incident Response Role

The exemption in the SCP is built around the concept of a break-glass role, a highly privileged IAM role that is never used during normal operations and whose assumption is itself a signal that an incident is underway.

The security guarantee of this entire technique depends on the break-glass role being unreachable by the attacker. If they can assume or modify it, they can use it to detach the quarantine policy and the protection fails.

When using IAM Identity Center, the break-glass role is implemented as a dedicated permission set — in our example, IR-Engineer. Access to this permission set should be restricted to a small number of named individuals in your identity provider, with MFA enforced, and should generate an immediate alert when assumed.

Additionally, ensure that the IR-Engineer permission set itself cannot be modified by identities within the member account. Permission set definitions live in the IAM Identity Center management account. As long as your management account access is properly secured, a compromised identity in a member account has no path to alter the permission set or its trust boundaries.

Every assumption of the break-glass role should be treated as a high-severity event in your SIEM regardless of who initiated it.

Why This Only Works With AWS Organizations

This technique has a hard prerequisite: the target account must be a member of an AWS Organization as SCPs are available only within them.

Note that SCPs do not apply to the management account itself, only to member accounts. If the compromised identity is in the management account, this technique does not apply and account-level isolation or direct AWS support engagement is the appropriate path.

For organizations that are not yet using AWS Organizations, this technique is not available. This is an additional argument for adopting a multi-account Organizations structure as it provides IR capabilities that are simply not possible in a single-account setup.

Validation

To validate the technique, we set up a test environment with:

• An IAM user (attacker) with AdministratorAccess
• A managed policy (IR-QuarantinePolicy) containing a deny-all statement
• The SCP above applied to the member account via AWS Organizations
• A monitoring script running as the attacker that continuously polls for new policy attachments and attempts to detach them

The sequence of events:

[11:46:58] [S3 CHECK] ✔ s3:ListBuckets succeeded — permissions still active

[11:46:59] [ALERT] New managed policy detected: arn:aws:iam::[REDACTED]:policy/IR-QuarantinePolicy
[11:46:59] [ACTION] ✘ Failed to detach: arn:aws:iam::[REDACTED]:policy/IR-QuarantinePolicy — Error: AccessDenied

[11:47:05] [S3 CHECK] ✘ s3:ListBuckets failed — quarantine is effective
[11:47:10] [S3 CHECK] ✘ s3:ListBuckets failed — quarantine is effective

Without the SCP applied, the attacker monitor successfully detaches the policy within the eventual consistency window and retains access. With the SCP applied, the detachment attempt is blocked by an explicit deny, the quarantine policy propagates fully, and the attacker loses access within seconds.

How This Relates to Quarantine OU Isolation

Moving a compromised account to a quarantine OU remains the most thorough containment option when the blast radius is account-wide or the threat actor has management-level access within the account.

The SCP-enforced quarantine policy technique occupies a different point on the response spectrum: it is faster to apply, more surgical in scope, and does not require disrupting other workloads in the account. It is particularly well-suited for the first minutes of an incident, while the IR team assesses whether full account isolation is warranted.

Think of it as the difference between evacuating a building and locking a specific room. Both are valid responses depending on what you know about the threat.

Recommendations for IR Playbook Changes

Before an incident occurs, the following should be pre-deployed as standing controls:

• Create the IR-QuarantinePolicy in every member account
  • The policy content is up to your threat model.
  • A full deny-all is the most restrictive option, but a targeted deny scoped to specific actions may be preferable in some environments.
• Create the IR permission set in IAM Identity Center
  • This is the break-glass role that will be exempted from the SCP.
  • If you use automation for IR workflows, ensure the automation role is also included in the exemption.
• Deploy the IRQuarantinePolicyGuard SCP and attach it to the target accounts or OUs.

Once the prerequisites are in place, the containment step reduces to a single action: attach IR-QuarantinePolicy to the compromised identity. The IRQuarantinePolicyGuard SCP ensures it cannot be removed by the attacker regardless of their privilege level within the account.

From this point, your existing AWS IR playbook takes over as normal. The standard phases apply: containment, evidence preservation, investigation, eradication, recovery, and post-incident review. For a comprehensive AWS-specific IR sequence, we recommend the AWS Security Incident Response Guide.

This technique directly addresses the eventual consistency persistence gap documented in our previous research, a gap that remains present in AWS and is not covered by existing IR guidance.

Conclusion

AWS IAM eventual consistency created a gap in incident response that we documented in our previous research. The official AWS remediation recommendation does not close this gap. Account-level quarantine OU isolation closes it but at a high operational cost.

OFFENSAI presented in this article an identity-level containment method that works against the exploitation of eventual consistency in AWS. It involves using an SCP-enforced protection of a quarantine policy through the iam:PolicyArn condition key.

We recommend that cloud security teams adopt this pattern and update their IR playbooks accordingly.