TL;DR: IAM:PassRole can turn a low-privilege AWS identity into an escalation path when broad resource scope, permissive trust policies, or standing NHI permissions let attackers attach higher roles to workloads, according to Apono. The real failure is assuming delegation is harmless when it can outlive review windows and bypass human-paced IAM controls.
NHIMG editorial — based on content published by Apono: 7 Pitfalls to Consider When Configuring IAM:PassRole
By the numbers:
- 22% of analyzed breaches used credential abuse as the top initial attack vector.
Questions worth separating out
Q: How should security teams restrict IAM:PassRole in AWS environments?
A: Security teams should restrict PassRole to explicit role ARNs, pair it with service-specific conditions, and keep the target role trust policy narrow.
Q: Why do standing NHI permissions make PassRole abuse more dangerous?
A: Standing NHI permissions make PassRole abuse more dangerous because the access path stays available after the workflow that justified it has changed.
Q: What breaks when AWS trust policies are too permissive?
A: When AWS trust policies are too permissive, the role’s receiving side no longer controls who can assume it.
Practitioner guidance
- Tighten PassRole to named role ARNs Replace wildcard resource scope with explicit role ARNs and separate staging from production delegation so a compromised identity cannot attach high-value roles by default.
- Bind roles to specific services Use iam:PassedToService conditions so a role created for Lambda cannot be reused on EC2 or another more interactive service that gives an attacker a richer control surface.
- Review trust policies with the same rigor as PassRole policies Check the role trust boundary for broad account IDs, wildcard principals, and over-permissive service trusts because the receiving side can undo an apparently strict pass policy.
What's in the full article
Apono's full analysis covers the operational detail this post intentionally leaves for the source:
- Specific PassRole policy examples showing how broad resource scope creates escalation paths in AWS.
- Practical guidance on using iam:PassedToService to keep delegation tied to the intended workload type.
- Examples of how trust policies and PassRole policies can fail together in confused deputy scenarios.
- Discussion of how automation accounts and standing credentials turn PassRole into a persistent risk.
👉 Read Apono's analysis of IAM:PassRole pitfalls in AWS →
IAM:PassRole and hidden escalation paths in AWS environments?
Explore further