Executive summary
- What broke: Overly-broad role passing allowed unintended privilege escalation.
- Why it matters: escalation chains often look legitimate in logs.
- How to catch it: alert on role passing + correlate assume-role activity.
- How to prevent it: least privilege + scoped trust + org guardrails.
Architecture
Minimal lab roles:
- DevRole: limited expected permissions.
- HighPrivRole: tightly controlled administrative role.
- Service surface: managed service that assumes execution roles.
Diagram placeholder: DevRole → Service → HighPrivRole.
The misconfiguration
- Role passing scoped to wildcard resources.
- Deployment roles reused for runtime execution.
- Temporary elevated permissions never removed.
Why this is dangerous
- Privilege jump: low-priv identity gains high-impact permissions.
- Stealth factor: appears as service activity, not direct login.
- Blast radius: determined by high-priv role scope.
Exploitation simulation (isolated lab)
- Attempt escalation in a dedicated lab account.
- Capture CloudTrail sequence: configure → assume → action.
- Revert immediately after evidence capture.
Detection strategy
- Primitive alerts: role passing and policy changes.
- Correlation: config change followed by assume-role.
- Sensitive action monitoring: IAM, KMS, data access APIs.
Remediation
- Scope role passing to specific roles and services.
- Use permission boundaries.
- Separate deployment and execution roles.
Hardening checklist
- Org-level guardrails blocking unsafe patterns.
- Reduce permissions on high-priv roles.
- Require review for trust/policy changes.
- Keep correlation-based alerts active.
Lessons learned
- Most IAM incidents are chains of reasonable permissions.
- Prevention first, detection second.
- Correlation across time and identity is critical.