Surfaced misconfigured IAM policies exposing internal services across AWS accounts. Remediation completed in 9 days.

Context

A growth-stage B2B SaaS company operated across roughly twenty AWS accounts organised under AWS Organizations, with a typical hub-and-spoke pattern — a shared services account, a deploy account, separate accounts per business unit, and isolated production accounts per customer tier. The platform team had been using a commercial CSPM tool for two years and was confident in their posture against single-policy misconfigurations.

The engagement scope was deliberately narrow: find what the CSPM had not.

Approach

The audit was structured around three layered analyses:

1. Static IAM review. Every role, every inline policy, every managed policy, every trust relationship — exported, parsed, and normalised. We treated IAM as a graph database problem, not a policy-by-policy compliance problem.
2. Cross-account trust analysis. Every sts:AssumeRole permission was traced across account boundaries to find role chains that crossed trust zones in ways the architecture diagram did not suggest.
3. Manual review of the federation layer. SSO permission sets, SAML attribute mappings, and STS session-tag handling — the parts of IAM that CSPM tools do not model well.

What we found

Three privilege-escalation chains spanning trust zones. Each chain individually consisted of two or three permissions that, in isolation, looked defensible. Combined, they let a low-privilege principal in one account reach administrator-equivalent access in another.

The chain that mattered most:

1. A developer role in the shared services account had iam:PassRole on a specific deploy role.
2. The deploy role had lambda:UpdateFunctionCode on a function in the production account.
3. The function’s execution role had iam:AttachRolePolicy on principals in the production account.

A developer who could assume-role into the deploy role could update the Lambda to attach AdministratorAccess to themselves on production. The CSPM had flagged each policy as compliant in isolation; the chain was invisible to it.

Remediation

The platform team picked up the report on a Friday and had all three chains broken by the following Sunday week. They chose to break the chains at the cross-account sts:AssumeRole boundary rather than re-engineer individual policies, which closed the chains and reduced overall complexity at the same time.

Attack-path diagrams were handed over as long-lived artefacts the platform team could reference when adding new accounts or roles.

Appendix work

A small appendix mapped each finding to relevant SOC 2 Trust Service Criteria and ISO 27001 Annex A controls, on the client’s request — they were preparing both audits and wanted the cloud-security findings to slot directly into the existing control matrix.