AWS Privilege Escalation Techniques

AWS privilege escalation isn’t static: it’s an arms race. Enumeration frameworks like Pacu, PMapper, ScoutSuite, and CloudFox quickly find new privilege paths as AWS releases new services and expands existing ones. The result is an ecosystem where old assumptions break quickly, and new attack surfaces appear faster than defenders can catalog them.

CTF platforms such as CloudGoat, IAM-Vulnerable, and CloudFoxable have become essential tools for understanding this shifting landscape. But as AWS introduces AI-driven services with code execution capabilities, traditional scenarios no longer capture the full range of modern escalation vectors — especially in areas like Bedrock and Bedrock AgentCore.

Software Secured partnered with Sonrai Security to research privilege escalation scenarios across controlled lab environments:

• Classic IAM and service-based CTF challenges (CloudGoat, CloudFoxable, IAM-Vulnerable)
• New AI-era scenarios in Bedrock and Bedrock AgentCore
• Two parallel environments were used: one unrestricted, and one with block rules applied via resource policies and service control policies (SCPs),implemented through Sonrai’s Cloud Permissions Firewall

This article is not a product review. It summarizes the technical insights from that work, focusing on:

1. How AWS privilege escalation has evolved, moving from IAM primitives to service-based code execution to AI-driven orchestration.‍

‍
2. Why some AWS actions can be blocked with policies while others are inherently difficult  to constrain.‍

‍
3. A general framework for evaluating whether a permission is relevant to privilege-escalation: especially useful when dealing with new services like Bedrock.

1. The Evolution of AWS Privilege Escalation

Privilege escalation in AWS has evolved through distinct eras, each driven by changes in how AWS services behave and how attackers can chain them together.

‍1.1 Era 1: Classic IAM-Based Escalations

For a long time, AWS privilege escalation was mostly about IAM misconfigurations:

‍Modifying identity permissions

• iam:AttachUserPolicy
• iam:PutUserPolicy
• iam:CreatePolicyVersion

Changing trust relationships

• iam:UpdateAssumeRolePolicy

Creating credentials for yourself

• iam:CreateAccessKey
• iam:CreateLoginProfile

Most CTF challenges revolve around these well-understood patterns. If a user or role can write to its own permissions (or any role that has more privilege) it's game over.
These still matter because IAM is extremely powerful, and organizations frequently over-permission identities.

‍1.2 Era 2: Service-Centric Escalations

Over time, AWS added more services with the ability to run code or orchestrate workflows. This expanded privilege escalation into new dimensions such as:

• Lambda code updates
  
  • lambda:UpdateFunctionCode lets attackers push their own code
• EventBridge routing attacks
  
  • Attackers create events that trigger privileged functions
• ECR supply-chain poisoning
  
  • Malicious containers run under privileged roles
• Step Functions to AssumeRole chaining
  
  • Indirect privilege routing through orchestrators
    

A common enabling primitive across many of these patterns is iam:PassRole, which allows an attacker to attach a privileged role to newly created compute or orchestration resources, even if no vulnerable service already exists. These escalations no longer rely on IAM mutations alone. Instead, attackers compromise execution surfaces and inherit privileges indirectly, either by abusing existing privileged services or by creating new ones using iam:PassRole.

‍1.3 Era 3: AI and Orchestration Services (Bedrock, AgentCore)

The newest class of privilege escalation comes from AI-powered orchestration services. Modern Bedrock systems, especially Bedrock Agents and Bedrock AgentCore, act as automated "orchestrators" that can:

• Run code (via Code Interpreter)
• Make AWS API calls
• Chain actions across multiple services
• Execute logic on behalf of a role
• Interact with user-provided prompts and tools

Entirely new attack paths emerge from these new permissions:

• bedrock-agentcore-control:CreateCodeInterpreter
• bedrock:InvokeModel
• lambda:UpdateFunctionCode (used as an escalation step from AgentCore)

In other words: Privilege escalation is no longer just about identity. It now lives at the intersection of service logic, orchestration, and AI.

2. Why Some AWS Actions Are Blockable, and Others Aren’t

Security team soften assume they can solve escalation by "denying dangerous actions." The reality is much more complex. AWS has multiple layers of policy enforcement, and not all services participate equally.

‍2.1 Identity Policies

Identity policies (attached to users, roles, or groups) are intended to determine what an identity is allowed to do.

They evaluate first, so a broad permission like:
‍

{  "Effect":"Allow",  "Action":"lambda:*",  "Resource": "*"}

will fully enable service-based privilege escalation. You can’t override this with a resource policy for many Lambda update actions because not all of them support resource-level Amazon Resource Names (ARNs).

‍2.2 Resource Policies

Some services let you attach resource policies with explicit denies.  
Examples with strong resource-policy surfaces:

• S3
• Lambda
• Secrets Manager

Examples with partial support for resource-level control (some resources support policies, but key actions do not):

• Bedrock Agents resource-based policies for Agent Runtime resources, but Code Interpreters and other execution-related actions still cannot be fully constrained with resource policies.
• EventBridge event buses support policies, but rules and targets do not.
• SNS topics support policies, but subscription and delivery actions often bypass them.
• Step Functions state machines support policies, but executions and integrations lack full resource-policy enforcement.

Examples with no resource policies at all:

• IAM: users, groups, and roles do not support general resource-based policies; permissions can only be expressed through identity-based policies.  
• STS: aside from the role trust policy (which governs who may assume a role via sts:AssumeRole), STS itself does not support resource-based policies for controlling token issuance or session behavior
• Access key creation
• Policy version creation

‍This is why actions like iam:CreatePolicyVersion remain high-risk and hard to control. There is simply no "resource" for a resource policy to attach to.

‍2.3 Service Control Policies (SCPs) and Permission Boundaries

SCPs are extremely effective, but only for actions that support:

• Clear resource ARNs
• Relevant condition keys

For actions that do not support ARNs or treat Resource as "*", SCPs behave inconsistently.

• Blocking lambda:UpdateFunctionCode is straightforward.
• Blocking iam:UpdateAssumeRolePolicy or iam:PutGroupPolicy is not.

We will examine why this is in the next section.

2.4 AWS  IAM Policies vs. Service Policies

Some AWS actions appear frequently in privilege escalation chains because AWS-native policy mechanisms cannot constrain them granularly. This is due to how these APIs are designed.
‍

‍Why AWS IAM controls struggle (architectural reasons)

AWS documents that many IAM and compute actions:

• Do not support resource-level permissions
• Expose no resource ARNs at all
• Support only "Resource": "*", meaning:
  
  • Cannot be targeted to specific users, roles, policies, or resources
  • Cannot be narrowed using resource policies
  • Cannot be filtered with granular SCP conditions

 Examples include:

• iam:CreateAccessKey
• iam:CreateLoginProfile
• iam:PutRolePolicy
• iam:CreatePolicyVersion

These APIs provide no mechanism to express constraints like:

> Allow only for specific principals,
> Allow only when certain tags match,
> Deny only for certain IAM entities.

Similarly, compute actions such as lambda:UpdateFunctionCode inconsistently support resource scoping, making fine-grained SCP enforcement unreliable across service sub-actions.

What this means for AWS IAM governance

SCPs, permission boundaries, and resource policies:

• Can deny the action completely, but
• Cannot deny it conditionally, because:
  
  
  • No ARNs exist
  • No relevant condition keys exist
  • IAM itself does not support resource-based policies

That is to say:

> AWS-native controls can only allow or block these APIs globally, not contextually.

‍‍3. A Framework for Evaluating Whether a Permission Is Privilege-Escalation-Relevant

When AWS introduces a new service (like an AI orchestration service) the question becomes: Does granting this permission allow someone to become more privileged than they are now? Here’s one way to answer that.

‍3.1 Does it allow code execution?

This is the most direct escalation path.

Examples:

• lambda:UpdateFunctionCode then upload attacker code
• glue:CreateJob then run arbitrary Python/Spark workloads  
• ecs:RunTask then deploy containers with privileged roles  
• bedrock-agentcore-control: CreateCodeInterpreter then run arbitrary code via interpreter  

If an action lets attackers execute code under a privileged role, it's an escalation.

‍3.2 Can it create or modify credentials?

• iam:CreateAccessKey
• iam:CreateLoginProfile
• sts:AssumeRole without meaningful conditions

These are nearly always high-risk.

3.3 Can it modify permissions?

• Inline policies
• Adding new managed policy versions
• Editing trust policies

This is the central theme of the challenges in IAM-Vulnerable.

‍3.4 Does it allow cross-service privilege routing?

Attackers may not escalate directly, but can force a privileged service to act on their behalf.

Classic examples:

• EventBridge to Lambda
• Step Functions to privileged role assumption
• SQS to Lambda fan-out

Newer example:

• Bedrock Agents orchestrating AWS calls
• Agents can use AWS API tools, execute plans, and run code under the agent’s role

3.5 Can the permission move attackers laterally into compute services?

Even if you cannot run code directly, you may be able to control something that does.

Examples:

• Reading Lambda environment variables containing secrets  
• Creating a Glue Dev Endpoint  
• Updating EC2 user-data and triggering a reboot
• Modifying a bedrock agent’s configuration to call untrusted functions

4. Case Studies: Classic vs. Modern Escalation Paths

Privilege escalation techniques fall into two broad categories: well-established IAM-centric patterns found in classic training platforms, and newer escalation vectors emerging in AI-driven orchestration services such as Bedrock AgentCore. Together, these illustrate how the AWS privilege landscape has expanded from identity manipulation to service-level execution and orchestration.

‍4.1 Classic IAM-Vulnerable, CloudGoat, and CloudFoxable Scenarios

Across these platforms, several escalation patterns appear repeatedly. They form the foundation of most traditional AWS privilege escalation paths:

• Creating new policy versions that grant attacker-controlled privileges
  
  • Using actions like iam:CreatePolicyVersion to inject an elevated version of an existing policy.
• Attaching a high-privilege or administrative policy to one’s own identity
  
  • For example, iam:AttachUserPolicyor iam:AttachRolePolicy.
• Updating trust policies to impersonate privileged roles
  
  • Abusing iam:UpdateAssumeRolePolicy to allow a low-privilege principal to assume a high-privilege role.
• Modifying Lambda functions to run attacker-controlled code
  
  • Using lambda:UpdateFunctionCode to execute under the function’s IAM role.
• Supplying malicious container images through ECR
  
  • Substituting an image used by ECS/EKS/Lambda so that a more privileged execution environment runs attacker code.

These represent the classical escalation chains: identity mutation, trust relationship abuse, and code execution surfaces that indirectly grant elevated permissions.

4.2 Modern Bedrock & AgentCore Scenarios

Newer AWS services, especially AI orchestration systems, introduce escalation patterns not captured in classic training platforms. To explore these, we examine new Bedrock-based challenges that highlight how execution and orchestration layers change the escalation model.

‍4.2.1 Code Interpreter Escalation

• A role with minimal Bedrock permissions can still create a Code Interpreter via AgentCore.
• The interpreter runs Python code under the agent’s IAM role, not the caller’s identity.
• Once created, the interpreter can invoke AWS SDK operations without restriction, unless guardrails are explicitly enforced.
• This enables full escalation: the attacker moves from a low-privilege principal to an AI execution environment leading to arbitrary AWS API calls.

This pattern reflects a new escalation class: AI-managed compute that executes code on behalf of a privileged service role.

4.2.2 Agent Tool Hijacking via Lambda (Second-Stage Escalation)

Based on this new challenge

• A role with:
  
  • Limited Lambda management APIs, including lambda:UpdateFunctionCode
  • Read-only Bedrock permissions
  • Authorization to invoke a Bedrockagent
• Inspecting the agent reveals that its action groups rely on a Lambda function  to perform real-time cloud inventory tasks.
  
• Using the function ARN provided in the agent’s tool configuration, the attacker retrieves the Lambda details and confirms:
  
  • The function has broad read access across AWS resources
  • Only the Bedrock service may invoke it
• The attacker prepares a malicious replacement Lambda payload (one that conforms to Bedrock’s expected response schema) capable of:
  
  • Enumerating S3 buckets and objects, or
  • Exfiltrating the Lambda execution role’s credentials
• With lambda:UpdateFunctionCode, the attacker uploads the modified function code.
• The attacker then interacts with the agent, prompting it to trigger the now-compromised Lambda function. The agent faithfully returns the Lambda output.
• Using either the exfiltrated credentials or repeated agent-driven enumeration, the attacker exfiltrates data from S3.

This can be seen in the diagram:‍

‍

This scenario highlights a key escalation pattern:
> When an AI agent delegates work to downstream tools, those tools become part of the agent’s attack surface. Compromising the tool means compromising the orchestration layer.

It also demonstrates a multi-stage privilege chain:  
>Limited IAM user to Lambda code execution to Bedrock-mediated invocation to privileged resource access.

4.2.3 Role Pivoting via Code Interpreters

Based on this new challenge:

• A role with:
  
  • Read-only access to IAM and Bedrock resources
  • iam:PassRole permissions for multiple AgentCore roles
  • Full management permissions for AgentCore Code Interpreters
• The attacker inspects the two roles they are allowed to pass:
  
  • a role with access to an S3bucket
  • a role with broader privileges, including:
    
    • Foundation model access
    • Ability to invoke code interpreters
    • Read permissions on a Bedrock Knowledge Base
• (Optional reconnaissance) The attacker first creates a code interpreter using one of the roles and tests access to the S3 bucket to validate role behavior.
• The attacker then creates a second code interpreter, this time passing the more privileged role.
• Once the interpreter is created, the attacker initiates a code interpreter session and executes Python directly within the AgentCore environment.
• Because the interpreter runs using the agent runtime role’s permissions, the attacker can now access foundation model tools and read from the AgentCore Knowledge Base.
• Finally, the attacker exfiltrates sensitive data directly from the Knowledge Base using the interpreter session.
     
  This can be seen in the diagram:
‍

‍

This scenario illustrates a distinct escalation pattern:

> When attackers can pass AgentCore roles and create code interpreters, the execution environment becomes a pivot point into higher-privilege context seven without invoking a full agent.

It also highlights an important emerging risk:

• Agent runtime roles and code interpreter roles often share similar service trust relationships, meaning a user who can create interpreters may be able to execute code as any role in that trust domain.
• Knowledge Bases, foundation models, and orchestration tools effectively become data sources exposed via compute permissions.

‍This escalation chain demonstrates modern privilege pivoting:  
> Low-privilege user to interpreter creation to privileged execution environment to knowledgebase exfiltration.

Why These Matter

These Bedrock and AgentCore scenarios highlight an important trend:

• AI services increasingly function as orchestration layers that bridge multiple AWS services.
• Any service that runs code on your behalf becomes a potential privilege escalation hub.‍

Classic IAM-centric escalation still matters, but modern attacker workflows increasingly leverage execution surfaces, orchestration behavior, and cross-service toolchains, especially in AI-enabled platforms.

‍5. Results: Parallel Testing Across Escalation Eras

Two environments: The escalation patterns described in this article are not flaws in isolation.  They are consequences of AWS service design choices. These mechanisms remain just as effective today as when the services were originally released. To validate their real-world viability and defensive coverage, each scenario was tested in two environments:

• An unrestricted AWS account, representing a typical development or research environment
• A restricted account protected by SCP-based guardrails via the Cloud Permissions Firewall (CPF)

Era 1: Classic IAM Escalation (IAM-Vulnerable)

12 of 12 classic IAM-based escalation scenarios from IAM-Vulnerable were successfully exploited in the unrestricted environment.    

These included:

• Policy version injection
• Inline policy attachment
• Trust policy abuse
• Credential creation

All of these were effectively prevented in the CPF-restricted environment using SCP-based controls.  These results confirm that traditional IAM mutation paths remain fully viable for attackers when not explicitly constrained, but can be systematically blocked when permission boundaries are correctly enforced

‍Era 2 & 3 Results: Service-Centric and AI-Orchestrated Escalation

Four modern, service-centric scenarios were tested:

• Two Bedrock/AgentCore scenarios (Code Interpreter escalation and AgentTool hijacking)
• One Elastic Beanstalk secrets exposure scenario from CloudGoat
• One Bastion host lateral-movement scenario from CloudFoxable

Results

• 4 of 4 scenarios were successfully exploited in the unrestricted environment
• 4 of 4 were prevented in the CPF-restricted environment using SCP-based enforcement

These scenarios span both traditional service-centric execution paths (Era 2) and AI-driven orchestration paths (Era 3), demonstrating that modern privilege escalation increasingly depends on cross-service execution and delegation, not only IAM mutation.

Key Takeaway From the Parallel Testing

Across all 16 tested scenarios:

• 100% were exploitable in unrestricted environments  
• 100% were prevented when appropriate SCP-based guardrails were enforced

This reinforces two important technical conclusions:

• Privilege escalation paths across all eras remain viable without explicit guardrails
• SCP-based controls (when aligned to known escalation primitives) can effectively disrupt both classic IAM abuse and modern service-centric escalation chains, without requiring changes to AWS service behavior

Conclusion

AWS privilege escalation is no longer defined solely by IAM misconfigurations. Modern escalation chains now flow through managed compute, serverless runtimes, event orchestration, supply-chain pathways, and increasingly, AI-driven agent systems. As more services execute code or perform actions on behalf of identities, privilege becomes an emergent property of service behavior: not just policy documents.  

Security teams can stay ahead by:

• Knowing which AWS actions can be constrained with native controls—and which fundamentally cannot
• Applying a consistent framework to evaluate new services and execution surfaces
• Treating AI agents and interpreters as compute workloads with real privilege impact
• Recognizing how identity, execution, and orchestration combine into multi-hop escalation paths

Because many high-impact IAM and compute actions lack ARNs or condition keys, AWS-native mechanisms like SCPs cannot always restrict them precisely. Service Policies help fill this gap by enforcing guardrails at the service boundary, reliably blocking actions that native controls can only allow or deny wholesale.  All the privilege escalation paths discussed can be blocked by properly crafted and managed service policies.

The classic and Bedrock scenarios highlight a central truth:

> In the cloud, privilege isn’t just what your IAM policy grants: it’s what your permissions can make the platform do on your behalf.

‍

‍