'Prove It or We Won't Fix It': Validating an IAM Escalation Path Without Modifying IAM
A logistics company hires you for a 5-day cloud security review of an AWS organization. The rules of engagement permit read-only API calls only: 'No creation, modification, or deletion of IAM, compute, storage, or network resources.' You are given an auditor role with SecurityAudit and ViewOnlyAccess.
From policy documents you identify an escalation path: a developer role has iam:CreatePolicyVersion on a managed policy attached to a CI role, plus iam:AttachRolePolicy on that same role. In principle, a compromised developer credential could publish a new default policy version granting AdministratorAccess, attach it, and then use the CI role's ec2:RunInstances and iam:PassRole permissions to operate in production. You have not executed anything. The security lead says: 'Prove it or we won't fix it - just create the policy version and roll it back, nobody will notice.' Your report deadline is in 48 hours.
1. Do you execute the escalation to satisfy the client? Justify, and describe what you do instead.
Read the worked answer
No. Three reasons, in order of weight.
The RoE is explicit and you do not have authority to waive it. The security lead is not necessarily the signatory, and verbal permission does not amend a written rules-of-engagement document. 'Roll it back' is still a modification: for a period, a production CI role holds AdministratorAccess, and if the pipeline runs during that window it inherits it.
Rollback is not clean. Creating a policy version and setting it as default, then reverting, leaves CloudTrail and Config history that your own report will have to explain. If the CI role's trust or the pipeline's behavior changes, you may break deployments and spend the remaining days on incident response rather than assessment.
The claim 'nobody will notice' is false and signals the client has not thought about their own detection coverage - which is itself worth reporting.
Instead: deliver configuration-based validation. Show the exact policy statements and the principal-to-policy-to-resource chain, run iam:SimulatePrincipalPolicy where the API allows, and enumerate the conditions that would block the path - SCPs, permission boundaries, resource policies, MFA conditions, session policies. Then offer a controlled validation in a dedicated sandbox account or a named change window with an approved change ticket, a rollback owner, and a defined time box.
2. How do you express confidence and severity in the report without having exploited the path?
Read the worked answer
Separate the evidence class from the conclusion, and say which one you are giving.
Evidence class: 'Validated by configuration analysis; not exploited. The escalation path was derived from IAM policy documents retrieved on and, where supported, from policy simulation. No IAM resources were created or modified.'
Confidence: High that the permissions exist as described, because the policy documents are the ground truth. Medium-high that the full chain is exploitable, because it depends on SCPs, permission boundaries and the CI role's trust policy, which you should list explicitly with what you found for each.
Disconfirming conditions: add a short section listing what would break the chain. This is what turns a theoretical finding into something an engineer can verify, and it protects you if a condition you could not see blocks the path.
Severity: High to Critical based on blast radius, not on exploitation status. Reaching AdministratorAccess from a developer credential, with PassRole into a CI role that can launch production instances, is a full-account compromise path. Note that impact does not require a novel exploit - it requires one phished developer credential.
Also report the absence of detection: no alerting on CreatePolicyVersion or AttachRolePolicy in an account where those actions are rare is a separate, actionable gap.
3. Write the remediation recommendation so it fixes the root cause rather than this one path.
Read the worked answer
Immediate (days):
- Remove iam:CreatePolicyVersion and iam:AttachRolePolicy from the developer role. Neither belongs in a role used for application development.
- Detach any policy granting those actions broadly across the organization; enumerate every principal that holds them and reduce to a break-glass role.
- Alert on CreatePolicyVersion, AttachRolePolicy, PutRolePolicy and PassRole to sensitive roles; these should be near-zero events.
Structural (weeks): 4. Apply a permissions boundary to the CI role and to all roles with PassRole reach, capping effective permissions regardless of attached policy. 5. Add an SCP denying iam:CreatePolicyVersion and iam:AttachRolePolicy organization-wide, with a documented exception path for the break-glass role only. 6. Restrict iam:PassRole with a condition limiting it to a named set of roles, and split the CI role into build and deploy roles with different trust. 7. Replace long-lived developer credentials with federated, short-lived sessions so a leaked key is not a durable escalation primitive.
Verification: re-run the permission graph after the change and confirm the path no longer resolves; provide the client a one-page retest checklist they can run themselves in the console, since your engagement ends Friday.