← Back to Overview

ACT I — PART 3

AWS IAM Privilege Escalation Case Study


Social Engineering + CLI‑Based PassRole Abuse

Executive Summary

This case study documents a controlled AWS lab exercise demonstrating how IAM misconfigurations involving iam:PassRole can lead to privilege escalation, even when traditional console‑based protections are in place.

The lab highlights a realistic attacker progression:

  1. Initial access via low‑privileged automation credentials
  2. Console‑based escalation attempts blocked by IAM hardening
  3. Pivot to AWS CLI (PowerShell)
  4. Successful privilege escalation through EC2 role attachment
  5. Creation of persistent administrator‑privileged infrastructure without lifecycle control

A key outcome is the distinction between browser‑based security controls and programmatic/API threat models — console guardrails alone are insufficient when automation permissions are misaligned.

Lab Objectives

Environment Overview

IAM Users

UserIntended Role
ops-juniorJunior operations, EC2 via console
ci-helperCI / automation user (CLI access)
dev-automationLambda automation experiments
dev-readonly / security-auditorIAM read-only visibility
guest-contractorMinimal / no permissions

IAM Roles

Context from LAB 2 — Social Engineering & Access Modeling

LAB 2 focused on human trust boundaries, not technical exploitation. Key observations:

This laid the groundwork for LAB 3.

Threat Model

The attacker (ci-helper) did not possess full automation credentials or independent infrastructure design capability. Instead, the attacker relied on social engineering of a junior operations user to obtain a valid EC2 launch blueprint, including the AMI ID, instance type, region, and knowledge of a privileged IAM role.

While console-based IAM controls prevented role discovery and selection, this human trust boundary bridged the remaining gaps. Once the attacker obtained a known-good configuration, iam:PassRole enabled privilege escalation through the AWS CLI without requiring any IAM visibility or administrative permissions.

Phase 1 — Console-Based Escalation (Blocked)

Observed behavior:

Privilege escalation via PassRole was blocked at the console layer due to missing role enumeration permissions, demonstrating effective IAM hardening against browser‑based abuse.

Phase 2 — Initial EC2 Activity by ops‑junior (Console)

Phase 3 — Attacker Pivot to CLI (ci‑helper)

With console escalation blocked, ci-helper pivoted to AWS CLI (PowerShell) using existing automation access keys.

The attacker did not need role listing, IAM visibility, or role creation — only the name of a privileged role, iam:PassRole, and ec2:RunInstances.

Phase 4 — CLI Exploitation (Confirmed Escalation)

Command Executed (AWS CLI):

aws ec2 run-instances \
  --image-id ami-0c02fb55956c7d316 \
  --instance-type t3.micro \
  --iam-instance-profile Name=AdminEC2Role \
  --region us-east-1 \
  --profile ci-helper

Result:

This proves that ci-helper, a non‑privileged user, socially engineered information to launch persistent administrator‑privileged EC2 infrastructure.

Phase 5 — Asymmetric Control (Critical Finding)

Despite creating the instance, ci-helper could NOT:

All lifecycle actions failed with AccessDenied.

ci-helper, a non‑privileged user, socially engineered information to launch persistent administrator‑privileged infrastructure, which they could not later manage. This is a serious operational and security risk.

CloudTrail Verification

CloudTrail RunInstances events confirmed:

AMI Clarification

Privilege escalation occurred via role attachment, not AMI reuse.

Security Impact Analysis

What Went Wrong

What Went Right

Key Lessons Learned

  1. iam:PassRole is privilege escalation when combined with compute
  2. Console protections ≠ API protections
  3. Role name secrecy is not a security boundary
  4. Automation users are high‑risk principals
  5. Creation permissions must align with lifecycle permissions

Defensive Recommendations

Final Conclusion

Even when IAM role visibility, listing, and creation are restricted, a user with iam:PassRole and workload execution permissions can escalate privileges through automation interfaces. Console‑based guardrails do not prevent CLI‑based role abuse.

This lab demonstrates a realistic, defensible, and commonly overlooked AWS privilege escalation path, combining technical misconfiguration with human trust failures — exactly how real incidents occur.

Screenshots from the Lab