Breaking free from the chains of fate - Bypassing AWSCompromisedKeyQuarantineV2 Policy

Breaking free from the chains of fate - Bypassing AWSCompromisedKeyQuarantineV2 Policy

Speakers: gl4ssesbo1; Opie

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=fYwG0s9uY0w

Overview

This talk, "Breaking free from the chains of fate - Bypassing AWSCompromisedKeyQuarantineV2 Policy," delivered by gl4ssesbo1 and Opie (with initial research collaboration from Andrew Kraut) at BSides NYC, delves into the critical shortcomings of AWS's automated response to leaked credentials. The speakers meticulously analyze the CompromisedKeyQuarantineV2 policy, which AWS attaches to identities suspected of compromise, and demonstrate numerous methods to bypass its intended protections. This research originated from a practical scenario involving honeypot configuration, highlighting a real-world problem.

The presentation reveals that despite AWS's claim of this policy protecting against financial fraud, it is far from a robust security measure. Attackers can still perform extensive enumeration, achieve privilege escalation, maintain persistence, gain management console access, execute ransomware attacks, and cause service availability disruptions. The findings underscore a significant gap in cloud security, where a seemingly protective measure can instill a false sense of security, leaving organizations vulnerable to sophisticated attacks even after a compromise is detected and "quarantined" by AWS.

The talk is crucial for cloud security professionals, incident responders, and developers working with AWS, as it exposes the limitations of default security mechanisms and provides actionable insights into detecting and mitigating threats from compromised credentials. Understanding these bypass techniques is essential for building more resilient AWS environments and developing custom, more effective incident response strategies for credential compromise.

Background

▶ Watch: Introduction and talk agenda overview (0:00)

In the realm of AWS security, the compromise of access keys or secret keys represents one of the most immediate and severe threats. When AWS detects that a set of credentials belonging to an IAM user or role has been leaked—for instance, found on public code repositories like GitHub—it takes an automated action. This action involves attaching a specific policy, known as CompromisedKeyQuarantineV2, to the compromised identity. The stated purpose of this policy, according to AWS, is to provide "small protection against financial fraud" that might result from leaked credentials. However, the speakers emphasize that many users, upon receiving the notification email from AWS, mistakenly perceive this as a comprehensive security measure, believing their account is now largely safe from further compromise.

The fundamental mechanism behind AWS policies relies on an evaluation logic where deny statements always take precedence over allow statements. If an identity has multiple policies attached, and one policy explicitly denies an action while another allows it, the deny action will always win. The CompromisedKeyQuarantineV2 policy operates purely on this principle: it contains a list of explicit Deny statements for specific actions across a limited set of AWS services. Crucially, this policy does not grant any Allow permissions; it merely prevents certain actions. This distinction is vital, as any action not explicitly denied by the quarantine policy, but allowed by other policies attached to the user or its groups, will still be executable by the compromised credentials.

The speakers highlight the critical flaw in this design: the quarantine policy is remarkably narrow in its scope. It targets only eight AWS services and, within those services, denies only five read-related privileges, alongside a few write-related ones. This leaves a vast surface area of AWS services and actions completely unrestricted by the quarantine policy. Consequently, if a compromised identity possesses broad permissions from other policies, and those permissions are not explicitly denied by CompromisedKeyQuarantineV2, an attacker can continue to operate with significant capabilities within the AWS environment, contrary to the common assumption of a "locked down" account. The talk effectively debunks the notion that this policy provides robust security, positioning it instead as a minimal, easily circumvented safeguard.

Key Findings

▶ Watch: What the quarantine policy doesn't prevent (4:00)

The central discovery of this research is the profound inadequacy of the AWS CompromisedKeyQuarantineV2 policy. The speakers conclusively demonstrate that this policy, rather than being a robust security measure, is easily bypassed, leaving AWS accounts highly vulnerable to a wide array of sophisticated attacks even after credentials have been flagged as compromised and "quarantined."

The primary findings can be summarized as follows:

• Extensive Enumeration Capabilities Remain: Despite the quarantine policy, attackers can still perform comprehensive enumeration of the AWS environment. Actions like iam:SimulatePrincipalPolicy, downloading Lambda function environment variables, and retrieving secrets from AWS Secrets Manager are not prevented, allowing attackers to map out the environment and discover further sensitive data or attack paths.
• Numerous Privilege Escalation Paths are Allowed: The research identified multiple, critical privilege escalation (PE) vectors that bypass the quarantine policy. Out of 28 known PE methods (referencing Rhinosec's research), 8 were found to be partially allowed and 4 fully allowed. This includes abusing service roles associated with Glue endpoints and SageMaker instances, and crucially, leveraging sts:AssumeRole actions to operate under the permissions of a different, potentially more privileged role, thereby escaping the quarantine policy's restrictions entirely.
• Persistence Mechanisms are Possible: Attackers can establish persistent access within the compromised account. A notable example involves modifying Lambda layers to inject malicious code, ensuring that new credentials or execution capabilities are gained every time the Lambda function is invoked. For older projects, CodeStar also offered persistence by adding team members.
• Direct Management Console Access is Attainable: While the policy prevents the creation or update of IAM login profiles, attackers can still obtain temporary federated tokens (sts:GetFederationToken). These tokens can be exchanged for a direct, authorized URL to the AWS Management Console, granting GUI access without needing a password, a technique observed in threat actors like GUIvil and ScatterSpider (Looker3).
• Data Exfiltration and Ransomware Scenarios: The policy does not prevent s3:GetObject or s3:PutObject actions. This enables attackers to download and upload objects to S3 buckets. Critically, combined with the ability to modify S3 bucket encryption configurations (s3:PutEncryptionConfiguration), attackers can implement a highly effective ransomware strategy. By configuring a bucket to use an attacker-controlled KMS key (even cross-account), they can re-encrypt legitimate data, rendering it inaccessible to the original owner without the attacker's key. Versioning can also be tampered with.
• Availability Attacks are Feasible: The policy fails to prevent ec2:TerminateInstances, allowing attackers to shut down or delete critical EC2 instances, leading to service disruption. Furthermore, ec2:ModifyInstanceAttribute is not prevented, opening a path to modify instance user data for code execution upon restart.
• Real-World Case Study: The speakers presented a chilling case study where threat actors exploited leaked credentials, specifically bypassing the quarantine policy, to gain access to Bedrock AI agents. These agents were then abused to run a "roleplay porn site" infrastructure, demonstrating the tangible and malicious impact of the policy's weaknesses.
• Flawed Policy Application and Detection Gaps: AWS attempts to attach the quarantine policy using the leaked credentials' own privileges. This means if the compromised key lacks iam:AttachUserPolicy permissions on itself, the quarantine policy will not be applied at all. Additionally, the CloudTrail logs for AWS-initiated iam:AttachUserPolicy events lack requestParameters and responseElements, providing a unique signature for detecting when AWS has applied the policy.

These findings collectively paint a picture of a default security measure that offers a false sense of protection, necessitating a proactive and comprehensive approach to credential compromise beyond relying on AWS's automated response.

Technical Deep Dive

▶ Watch: Downloading secrets from Secrets Manager despite quarantine (5:30)

The core of the bypasses hinges on a meticulous analysis of the CompromisedKeyQuarantineV2 policy's Deny statements. The policy is remarkably sparse, denying actions across only eight AWS services. Crucially, of these, only five are read-related privileges. This means that if an action is not explicitly denied by this policy, and the compromised identity has another attached policy that allows it, the action will succeed.

Quarantine Policy Scope

The policy explicitly denies actions like s3:ListAllMyBuckets and ec2:RunInstances. However, the vast majority of AWS actions, including many high-impact ones, remain outside its denial scope. This limited scope is the fundamental weakness exploited by attackers.

Enumeration Techniques

Even with the quarantine policy attached, an attacker can perform extensive reconnaissance:

1. Policy Simulation: The iam:SimulatePrincipalPolicy action is not prevented. An attacker can use this to accurately determine what actions the compromised identity can perform, effectively mapping out its full permission set without actually executing any potentially destructive actions. This is a powerful initial step for an attacker to plan subsequent moves.
2. Lambda Environment Variable Exfiltration: lambda:GetFunctionConfiguration and lambda:GetFunction (or similar read actions for Lambda) are not denied. This allows an attacker to download the environment variables of Lambda functions, which often contain sensitive information such as database credentials, API keys, or other secrets.
3. Secrets Manager Access: secretsmanager:GetSecretValue is not prevented. Attackers can directly retrieve secrets stored in AWS Secrets Manager, as demonstrated by the example of "Djakova" (a fictional secret). This can immediately yield high-value credentials or sensitive data.

Privilege Escalation Paths

The speakers identified several privilege escalation (PE) methods, building on the 28 known techniques cataloged by Rhinosec, that remain viable under the quarantine policy:

1. Abusing Glue Endpoints: AWS Glue environments can have associated instance profiles with specific roles. By default, these roles come with three policies, and users can optionally attach AmazonS3FullAccess. The key here is that actions performed via the Glue environment's role are outside the scope of the user's quarantine policy. This allows an attacker to execute actions like s3:ListAllMyBuckets and ec2:RunInstances (which are explicitly denied for the user) by leveraging the Glue role. This path is particularly attractive for crypto mining operations.
2. Assuming Roles: The sts:AssumeRole, sts:AssumeRoleWithSAML, and sts:AssumeRoleWithWebIdentity actions are not prevented by the quarantine policy. If the compromised user has permission to assume an existing role, they can effectively bypass the quarantine policy by operating under the permissions of that assumed role. While iam:UpdateAssumeRolePolicy (modifying the trust policy of a role) is prevented, simply assuming an already permissive role is sufficient.
3. Lambda Layer Modification for Persistence: Lambda functions rely on layers for libraries. The ability to modify these layers (lambda:UpdateFunctionConfiguration, lambda:PublishLayerVersion, etc., if allowed by other policies) is not prevented. An attacker can inject malicious code into a Lambda layer. When the function is invoked, this code executes, allowing the attacker to exfiltrate credentials from the Lambda's environment variables, establishing a robust persistence mechanism.
4. CodeStar Team Member Addition: For projects created before August 2024 (when CodeStar was deprecated), adding team members (codestar:AssociateTeamMember) is not prevented. This grants the attacker the privileges associated with the CodeStar project.
5. SageMaker Pre-signed URLs: Creating pre-signed URLs for SageMaker instances (sagemaker:CreatePresignedDomainUrl or similar) is not prevented. This can grant access to the SageMaker instance's underlying role and its associated privileges.

Infrastructure Impact (Non-PE)

Beyond privilege escalation, the quarantine policy fails to prevent actions that can cause significant damage or unauthorized access:

1. SSM Command Execution: ssm:SendCommand and ssm:StartSession are not prevented. These actions allow an attacker to execute commands with root privileges on EC2 instances or establish interactive SSH-like sessions, providing direct control over compromised hosts.
2. Management Console Access: While iam:CreateLoginProfile and iam:UpdateLoginProfile (for setting/changing user passwords) are prevented, sts:GetFederationToken is not. An attacker can obtain temporary federated credentials and then use a documented AWS feature to generate a signed URL for direct access to the AWS Management Console. This bypasses the need for a login profile and grants GUI access with the compromised user's permissions.

Object Access and Ransomware

The policy allows s3:PutObject and s3:GetObject (upload/download), but denies s3:DeleteObject. This seemingly limits damage, but combined with other capabilities, it enables potent attacks:

1. KMS Ransomware: The s3:PutEncryptionConfiguration action is not prevented. An attacker can configure an S3 bucket to encrypt objects using a KMS key controlled by the attacker (potentially in a different AWS account). By then downloading and re-uploading existing objects, or uploading new ones, all data becomes encrypted with the attacker's key. Since the legitimate account lacks access to this key, the data is effectively held for ransom. This technique was previously explored by Rhinosec in 2019/2020.
2. Versioning Tampering: If S3 bucket versioning is enabled, s3:DeleteObjectVersion is prevented. However, an attacker can disable versioning (s3:PutBucketVersioning is not denied) and then proceed with the KMS ransomware attack, preventing access to previous, unencrypted versions.

Availability Attacks

The policy's failure to deny ec2:TerminateInstances means an attacker can simply shut down or delete EC2 instances, causing significant service outages.

Furthermore, while ec2:StartInstances is prevented, ec2:ModifyInstanceAttribute is not. An attacker can terminate an instance, modify its user data (the startup script), and then wait for the legitimate user or an automated process to restart it. Upon restart, the attacker's injected script will execute with root privileges, providing code execution on the instance.

Policy Application and Detection

A critical vulnerability lies in how AWS applies the quarantine policy. It uses the leaked credentials' own permissions to attach the policy. If the compromised identity does not have iam:AttachUserPolicy permissions on itself, AWS cannot attach the quarantine policy. In such cases, the account owner receives an email stating the policy was not attached, but many might overlook this detail.

For detection, the speakers identified a unique CloudTrail signature: when AWS attaches the CompromisedKeyQuarantineV2 policy, the iam:AttachUserPolicy event will have both the requestParameters and responseElements fields set to null. This provides a specific indicator for security teams to identify when AWS has attempted to apply the policy.

Demo / Proof of Concept

▶ Watch: Bypassing quarantine using AWS Glue environment roles (7:00)

While the talk did not feature a live, interactive demonstration, gl4ssesbo1 and Opie provided several detailed conceptual walkthroughs and screenshots that served as compelling proof-of-concept for the described attack vectors. For instance, a screenshot depicted the successful modification of a Lambda function's layer, illustrating how an attacker could inject code to exfiltrate environment variables containing credentials.

The deep dive into each bypass method included specific AWS API actions and their implications, effectively demonstrating how an attacker could chain these actions together. The explanation of the KMS ransomware, for example, detailed the steps from modifying the S3 bucket's encryption configuration to downloading and re-uploading objects, thereby proving the feasibility of the attack. The mention of actual threat actors like GUIvil and ScatterSpider (Looker3) utilizing federated tokens for console access further validated the real-world applicability of these bypasses. The comprehensive detailing of each attack path, supported by clear reasoning about the policy's limitations, functioned as a robust technical demonstration of the findings.

Defensive Implications

▶ Watch: Unexpected vulnerability: assuming roles with compromised keys (8:10)

The findings presented in this talk necessitate a re-evaluation of how organizations respond to and mitigate compromised AWS credentials. Relying solely on AWS's CompromisedKeyQuarantineV2 policy is insufficient and creates a false sense of security.

Here are key defensive implications and recommended actions:

1. Do Not Rely on AWS's Default Quarantine Policy: The most critical takeaway is that the CompromisedKeyQuarantineV2 policy is not a comprehensive security solution. It leaves too many high-impact actions unprevented. Organizations must assume that a compromised key, even with the AWS policy attached, can still be used for significant malicious activity.
2. Implement Custom, Aggressive Quarantine Policies: Organizations should develop and be ready to deploy their own custom quarantine policies for compromised credentials. This custom policy should explicitly deny all the bypassable privileges identified in this talk (e.g., sts:AssumeRole, lambda:UpdateFunctionConfiguration, s3:PutEncryptionConfiguration, ec2:TerminateInstances, ssm:SendCommand, sts:GetFederationToken, and all other identified paths). The speakers specifically recommend creating a policy that prevents all these actions for any user with a leaked credential.
3. Detect Failed Policy Attachment: Monitor CloudTrail for iam:AttachUserPolicy events. Specifically, look for events where the requestParameters and responseElements fields are null. This unique signature indicates that AWS attempted to attach the quarantine policy but failed, likely because the compromised key lacked the iam:AttachUserPolicy permission on itself. This is a critical red flag indicating an unquarantined, active compromised key.
4. Proactive Credential Monitoring: Regularly scan for leaked credentials using services like AWS Access Analyzer, third-party dark web monitoring, or internal code repository scanning. Early detection is paramount.
5. Strict Least Privilege Principles: Enforce the principle of least privilege rigorously across all IAM users and roles. Even if a key is compromised, its blast radius should be minimal if it only has the permissions absolutely necessary for its function. This reduces the effectiveness of any bypass techniques.
6. Review sts:AssumeRole Permissions: Scrutinize all sts:AssumeRole permissions. Ensure that only trusted identities can assume roles, and that these roles themselves adhere to least privilege. The ability to assume a role is a primary bypass mechanism for the quarantine policy.
7. Monitor for Suspicious Activity from Quarantined Identities: Even if the AWS quarantine policy is attached, actively monitor CloudTrail logs for any activity originating from the compromised identity. Look for actions like iam:SimulatePrincipalPolicy, lambda:UpdateFunctionConfiguration, s3:PutEncryptionConfiguration, ssm:SendCommand, sts:GetFederationToken, or any sts:AssumeRole events. These are indicators of an active bypass attempt.
8. Enhance S3 Security:

• Implement S3 Object Lock in compliance mode to prevent deletion or modification of objects for a specified retention period, mitigating ransomware threats.
• Enable S3 Versioning and restrict s3:PutBucketVersioning and s3:DeleteObjectVersion permissions to authorized personnel only.
• Review KMS key policies associated with S3 buckets to ensure attacker-controlled keys cannot be introduced.

1. Strengthen EC2 and SSM Controls:

• Restrict ec2:TerminateInstances and ec2:ModifyInstanceAttribute to administrative roles.
• Carefully manage ssm:SendCommand and ssm:StartSession permissions, ensuring only necessary personnel can execute commands on instances.

1. Multi-Factor Authentication (MFA): While not directly preventing the use of compromised API keys, MFA is crucial for preventing initial compromise of user accounts and for protecting console access, especially for high-privilege users.
2. Incident Response Plan Review: Update incident response plans to specifically address the identified bypass methods. Ensure that remediation steps go beyond simply deactivating the compromised key and include a thorough forensic analysis of all activities performed by the key, both before and after AWS's quarantine attempt.

By proactively addressing these areas, organizations can significantly improve their resilience against sophisticated attacks leveraging compromised AWS credentials, moving beyond the inadequate protection offered by AWS's default quarantine policy.

Key Takeaways

• AWS's CompromisedKeyQuarantineV2 policy is not a comprehensive security solution. It provides minimal protection and should not be relied upon as the sole defense against leaked credentials.
• Numerous critical actions remain possible for attackers. This includes extensive enumeration, multiple privilege escalation paths (e.g., via sts:AssumeRole or abusing service roles), persistence mechanisms, and direct access to the AWS Management Console.
• Attackers can achieve high-impact outcomes such as ransomware (via S3 KMS encryption), data exfiltration (from Lambda or Secrets Manager), and service availability attacks (instance termination).
• The policy's application itself can fail. If a compromised key lacks iam:AttachUserPolicy permissions on itself, AWS will not be able to attach the quarantine policy, leaving the account completely unprotected.
• Organizations must implement their own robust remediation strategies. This involves deploying custom, aggressive quarantine policies that explicitly deny all identified bypass methods, rather than trusting AWS's default.
• Enhanced detection is crucial. Monitor CloudTrail for iam:AttachUserPolicy events with null requestParameters and responseElements to detect when AWS has applied the quarantine policy, and continuously monitor for any activity from compromised credentials thereafter.

About the Speaker(s)

The talk "Breaking free from the chains of fate - Bypassing AWSCompromisedKeyQuarantineV2 Policy" was presented by gl4ssesbo1 and Opie at BSides NYC. The research for this topic was initially started by gl4ssesbo1 and a colleague, Andrew Kraut, who both coincidentally began working on this issue separately while configuring a honeypot, eventually merging their findings. gl4ssesbo1 identified themselves as "the one in the right" during the presentation. The speakers are security researchers with expertise in AWS cloud security, dedicated to uncovering and publicizing critical vulnerabilities in cloud environments.