Pass-the-Role Attack - From Legit to Lethal

Introduction

In AWS, the iam:PassRole permission plays a critical role in enabling services like EC2, Lambda, and Glue to assume IAM roles on behalf of a user. This capability is foundational to automation, infrastructure-as-code, and operational scalability, allowing AWS services to perform actions with specific permissions.

However, this same mechanism, if not carefully controlled, introduces a potent privilege escalation path. When users are granted overly broad iam:PassRole permissions or allowed to pass roles with greater privileges than their own, they can effectively operate outside their intended access boundaries by assigning those roles to service identities they control. This turns iam:PassRole from a benign feature into an exploitable misconfiguration.

In this blog, we explore how attackers abuse the iam:PassRole permission in real-world scenarios to escalate privileges and move laterally within AWS environments. We’ll examine the API calls that can be used to mask such activity, the limitations of detection through traditional logging (e.g., CloudTrail), and why organizations must go beyond basic monitoring. Finally, we present actionable strategies to detect, investigate, and mitigate this threat before it leads to broader compromise.

What is iam:PassRole?

iam:PassRole allows a user to assign an IAM role to an AWS service, such as EC2, Lambda, ECS, or Step Functions. Common operations requiring iam:PassRole include:

• Associating an instance profile with an EC2 instance (ec2:RunInstances, ec2:AssociateIamInstanceProfile).
• Assigning a role to a Lambda function (lambda:CreateFunction, lambda:UpdateFunctionConfiguration).
• Creating ECS tasks with IAM roles.
• Attaching IAM roles to SageMaker notebooks, Glue jobs, and more.

Why is iam:PassRole Dangerous?

• Bypass of Least Privilege: Users can perform privileged actions indirectly. This permission allows an attacker to associate high permissions to AWS identity.
• Chained Escalation: Combined with permissions like ec2:RunInstances, it opens a path for full environment compromise.
• Stealthy Execution: iam:PassRole use hides inside higher-level service calls.
• Difficult to Monitor: Abuse happens through legitimate service invocations, not direct IAM actions.

Real-World Exploitation Workflows

EC2 Privilege Escalation

Scenario: An IAM user has the following permissions:

• iam:PassRole for a role with administrative permissions.
• ec2:RunInstances to launch EC2 instances.

Attack Steps:

1. Launch an EC2 instance and assign it the high-privilege role.
2. Access the instance (via SSH or user-data scripts).
3. Extract temporary credentials from the instance metadata.
4. Use the credentials to perform privileged API calls.

Code Example:

aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t2.micro --iam-instance-profile Name=AdminRole   --user-data file://bootstrap.sh

Within the instance:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole

Lambda Privilege Escalation

Scenario: A user has permissions to create or update Lambda functions, and to pass a high-privilege role.

Attack Steps:

1. Create or update a Lambda function and assign it the privileged role.
2. Upload arbitrary code to be executed.
3. Invoke the function to execute code under elevated privileges.

Code Example:

aws lambda create-function --function-name escalatedFunction

--runtime python3.9 

--role arn:aws:iam::123456789012:role/AdminRole 

--handler lambda_function.lambda_handler 

--zip-file fileb://lambda.zip

Glue Job Escalation

Scenario: A user has permissions to create Glue jobs and pass roles.

Attack Steps:

1. Create a Glue job that runs code with the assigned role.
2. Provide a script with arbitrary commands or AWS API calls.
3. Start the job and escalate privileges using the temporary credentials from the job’s environment.

Code Example:

aws glue create-job --name escalatedJob 

--role arn:aws:iam::123456789012:role/AdminRole 

--command '{"Name":"glueetl","ScriptLocation":"s3://bucket/script.py","PythonVersion":"3"}'

Is Detection Enough?

To detect and mitigate cloud threats, organizations first should implement logging and monitoring using AWS CloudTrail, which tracks API calls. However, this detection might not be enough, organizations must also consider using advanced approaches such as proactive threat hunting and investigation tools to uncover stealthy or complex attacks that evade basic detection mechanisms.

It's important to note: CloudTrail does not log iam:PassRole as a standalone event. Instead, it appears as part of the API call that uses it, making detection and analysis significantly harder.

This indirect logging model obscures visibility. Security teams must parse parameters like roleArn fields within various service events to infer when a role was passed. Moreover, CloudTrail does not indicate whether the passed role grants elevated or administrative permissions, requiring manual or automated follow-up investigation to:

• Retrieve the attached IAM policies on the role.
• Analyze their effective permissions.
• Determine whether the action created a privilege escalation path.

In addition, since roles can be attached to compute services that run arbitrary code (e.g., EC2, Lambda, Glue, SageMaker), even seemingly benign activity may introduce covert backdoors or lateral movement vectors. Passing a role to a cloud service identity may enable lateral movement, resulting in subsequent activity originating from a different identity than the initial caller.

Without correlating the role's trust policy, permissions policy, and the API action itself, defenders are blind to the true risk. Therefore, thorough investigation and enrichment are essential. This may involve:

• Analyzing the permissions and trust policy of the passed role
• Identifying activity associated with the role that may indicate malicious use
• Correlating events for attribution and anomaly detection

These limitations make iam:PassRole abuse particularly stealthy, demanding layered detection logic beyond standard rule-based alerts.

Detecting this attack involves hunting for API calls where an IAM role is assigned to an AWS service, signaling potential misuse of delegated privileges. These events don't explicitly show iam:PassRole as a separate action, so detection requires analyzing service-specific APIs that implicitly invoke it. Focus on calls where a role is attached to a resource, such as:

EC2 - RunInstances, AssociateIamInstanceProfile, ReplaceIamInstanceProfileAssociation

Lambda - CreateFunction, UpdateFunctionConfiguration

Glue - CreateJob, UpdateJob

Ecs - RunTask, StartTask

Sagemaker - CreateNotebookInstance, CreateProcessingJob, CreateTrainingJob

Mitigation Techniques

Mitigating the risk of privilege escalation via iam:PassRole requires enforcing strict control over who can delegate roles and under what conditions. Since this permission enables users to assign potentially more privileged roles to AWS services, it must be tightly scoped and continuously monitored. Below are effective techniques to reduce the attack surface and prevent misuse:

Mitigation Techniques

• Restrict iam:PassRole Scope: Use resource-level permissions to allow passing only approved roles.
• Use Permission Boundaries: Enforce maximum permissions a user can obtain, regardless of the role they assume.
• Tag-based Conditions: Use IAM policies with Condition elements based on tags to enforce contextual boundaries.
• Monitor Role Usage: Audit CloudTrail logs for sensitive services and IAM instance profile assignments to detect anomalies.
• Apply SCPs in Organizations: Use Service Control Policies to deny overly broad iam:PassRole usage or enforce tag-based constraints.

Example Policy Restriction:

{

  "Effect": "Allow",

  "Action": "iam:PassRole",

  "Resource": "arn:aws:iam::123456789012:role/SpecificAppRole"

}

Conclusion

While iam:PassRole is vital for enabling AWS services to function, misconfigured permissions open a hidden backdoor for attackers. By following the principle of least privilege, implementing granular controls, and monitoring IAM activity closely, organizations can significantly reduce the attack surface. Attackers frequently use enumeration to find privilege escalation paths like iam:PassRole. Pairing enumeration detection with abuse monitoring is critical. The battle isn’t only about stopping exploitation, it’s about spotting the groundwork.

Cyngular Security's CIRA Platform

By understanding these techniques and implementing proper monitoring and security controls, AWS administrators can detect, prevent, and mitigate such attacks before they escalate into full-scale breaches.

Therefore, investigation and enrichment are essential. This is where Cyngular’s CIRA platform plays a critical role, automating the enrichment of role usage, mapping privilege boundaries, and surfacing high-risk iam:PassRole events with full contextual insight.

By applying these strategies and leveraging Cyngular Security's CIRA platform, organizations can effectively protect their AWS environments and detect unauthorized operations, which may lead to extensive attacks.

The essence of cloud security lies in proactive measures, and Cyngular Security's Cloud Investigation and Response Automation (CIRA) platform incorporates this principle - automated, efficient cloud environment investigations. 

By integrating Cyngular Security's CIRA, you equip your team with the capability to quickly address and mitigate threats, ensuring robust protection for your cloud assets. Embrace Cyngular Security's CIRA for a deep, effective security strategy that keeps you ahead of threats.