← Back to Overview

ACT I — PART 1

Privilege Escalation via IAM PassRole — Offensive Lab Report with Remediation

Executive Summary

This report documents a hands‑on offensive security lab conducted in an AWS Free Tier account using console‑only access. The objective was to simulate a real-world attacker who gains access to a low‑privileged IAM user and attempts to escalate privileges through IAM trust and permission misconfigurations.

The lab successfully demonstrated a critical privilege-escalation path using the iam:PassRole permission combined with minimal EC2 permissions. Although the attacker identity never became an IAM administrator, they were able to cause AWS services to execute with full administrative privileges, representing a complete compromise in practice.

Scope & Constraints

Initial Conditions

Attack Narrative

  1. Reconnaissance: Enumerated IAM roles and discovered AdminEC2Role as a high-value target.
  2. Failed Direct Role Assumption: Switch Role attempts failed, confirming trust policy enforced indirect escalation.
  3. PassRole Exploitation via EC2: Using the EC2 launch workflow, the attacker successfully selected AdminEC2Role in the IAM instance profile dropdown and launched an instance with administrative privileges.
  4. Least-Privilege Friction: Attacker could not see EC2 instances (ec2:DescribeInstances denied) but impact was still achieved.
  5. Console vs Role Identity: Attempts to create IAM policies failed because the attacker identity in the console did not inherit EC2 role credentials.

Impact Assessment

Root Cause Analysis

Remediation & Hardening Checklist

1. Restrict iam:PassRole Usage

"Condition": {
  "StringEquals": {
    "iam:PassedToService": "ec2.amazonaws.com"
  }
}

Only allow roles to be passed to specific services that require them. Audit all users and policies with iam:PassRole privileges.

2. Enforce Permission Boundaries

Apply IAM permission boundaries to high-privilege roles to prevent roles from exceeding intended access even if PassRole is abused.

3. Harden Trust Policies

Restrict service principals to only what is necessary. Avoid overly broad * trust relationships.

4. Implement Monitoring & Detection

Enable CloudTrail logging for all iam:PassRole, RunInstances, and sensitive actions. Set up alerts for unusual role attachment or privilege escalation patterns.

5. Periodic IAM Graph Analysis

Regularly analyze combined permissions across users, roles, and services. Identify risky compositions before they are exploited.

6. Security Awareness & Least-Privilege Enforcement

Conclusion

This lab demonstrates that least-privilege enforcement must consider cross-service interactions, not just individual IAM policies. Even when visibility and console actions are restricted, iam:PassRole can be exploited for full administrative compromise. Implementing the remediation checklist above will significantly reduce the risk of privilege escalation.

Lab Outcome:

Remediation Checklist & IAM Redesign

This section translates the offensive lab into actionable defensive controls. The goal is not to patch a single bug, but to eliminate the entire class of IAM privilege‑escalation failures.

1. Immediate Containment Actions (High Priority)

1.1 Restrict iam:PassRole

Action: Inventory all principals with iam:PassRole. Remove wildcard role resources.

Secure Pattern:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam:::role/SpecificRole",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ecs-tasks.amazonaws.com"
    }
  }
}

Security Lesson: iam:PassRole without iam:PassedToService is equivalent to administrator access by proxy.

1.2 Rotate or Disable Abused Roles

Action: Detach admin policies temporarily. Review CloudTrail for recent AssumeRole.

Why: STS credentials remain valid after abuse unless explicitly mitigated.

2. Role Trust Policy Hardening

2.1 Scope Service Trusts

Insecure:

{"Principal": {"Service": "ec2.amazonaws.com"}}

Hardened:

{
  "Principal": {"Service": "ec2.amazonaws.com"},
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": ""
    }
  }
}

2.2 Separate Human vs Service Roles

Rule: Humans assume roles. Services execute roles. Never both. This blocks lateral trust abuse.

3. Permission Boundaries (Critical Control)

Apply permission boundaries to all execution roles.

{
  "Effect": "Deny",
  "Action": ["iam:*", "organizations:*"],
  "Resource": "*"
}

Even if a role is misused, IAM remains protected.

4. IAM Policy Redesign

4.1 Avoid Broad Read Permissions

Replace:

"iam:Get*", "iam:List*"

With resource‑scoped reads where possible.

4.2 Review Permission Composition

Ask: What happens if this identity gains one more permission?
IAM failures occur at policy intersections.

5. Monitoring & Detection

Alert on:

Correlate events — not single actions.

6. Organizational IAM Design Principles

Final Takeaway

AWS services will faithfully execute whatever IAM allows. Security failures happen when trust boundaries blur — not when attackers are clever.

Screenshots from the Lab