Zero-permission IAM user reads Secrets Manager via SNS-to-API-Gateway credential chain

The scenario

An article on dev.to walks through a 2025 CloudGoat scenario, credited to VirajMathpati, in which an IAM user holds no permissions that touch Secrets Manager at all. Checked with IAM Access Analyzer, the identity comes back clean: no access. PMapper, a tool built specifically for finding privilege-escalation paths in AWS, returns the same answer. Any policy-based review would conclude that this principal cannot read a single secret in the account.

The user retrieves a secret anyway, in seven API calls.

The four-service chain

According to the write-up, the connection between the user and Secrets Manager is not a permission grant but a credential value moving through four services:

• An SNS topic publishes messages containing an API Gateway key. The user's policy allows sns:Subscribe and sns:ListTopics on all resources, and because the topic has no resource policy of its own, the IAM identity policy is the only gate — and it lets the subscription through.
• The key lands in the subscriber's inbox as message payload.
• The key authenticates to an API Gateway configured for key-only auth, with no IAM signing, no Cognito, and no Lambda authorizer.
• The gateway's Lambda integration reads the target secret from Secrets Manager under its execution role and returns it in the HTTP response body.

Each hop is individually authorized, and each configuration looks fine against a per-service checklist: a broad-but-unrelated IAM policy, a topic using the default owner-only posture, a documented authentication mode on the gateway, and a Lambda following the standard pattern for secret access. The flaw sits in how the pieces join, not in any one of them — and no single policy links SNS to Secrets Manager.

The deny list that fell short

The scenario's author did anticipate exposure. The user's policy grants apigateway:GET broadly but explicitly denies seven paths covering API key listings, method bodies, and integration internals. The dev.to analysis calls this a careful deny by the standards of an ordinary review.

The write-up then encoded 24 known API Gateway management paths as Z3 solver queries, in an examples directory for a tool called stave, and found 21 of them still reachable. An attacker does not need the blocked endpoints: listing the REST APIs yields every API ID, the stages listing yields stage names, and the resources listing yields the paths — enough to reconstruct the full invoke URL and call it with the leaked key. The conclusion the article draws is that deny lists cannot keep pace with the size of a service's management surface.

Modeling the chain

The analysis runs four Z3 queries against the configuration from the walkthrough, plus four more against a remediated version. The findings build on each other:

1. The topic is both subscribable by this principal and publishes a credential — a combination of the identity policy, the absence of a topic policy, and a data-flow fact about the topic's payload.
2. The API Gateway deny list leaves most management paths open, including the three needed to reconstruct the invoke URL.
3. A five-hop data-flow chain holds: the principal can subscribe; the topic publishes a credential; the gateway accepts that credential without IAM auth; the gateway integrates with a function; and that function reads Secrets Manager. Each hop is a fact observed in a different service's configuration, and their conjunction is satisfiable.
4. Combining the findings yields the working escalation: list topics, subscribe, extract the key, enumerate the gateway, then invoke it and receive the secret in the response body.

The article's key modeling point is that no single-asset check can express this. The facts are spread across four separate observations plus one cross-asset claim, so detecting this class of issue requires reasoning over multiple services at once.

Why it matters

Permission scanners — IAM Access Analyzer, PMapper, and policy review tooling in general — evaluate identities one policy at a time. This scenario demonstrates an escalation path that is structurally invisible to that entire class of tooling, because it is carried by a secret value flowing through legitimate integrations rather than by a permission grant. Any environment where credentials ride through message topics or key-authenticated gateways has the same exposure.

The practical mitigations are unglamorous: never publish credentials in SNS payloads, attach resource policies to topics, prefer IAM or Cognito authorization over key-only auth on gateways that front privileged functions, and treat broad sns:Subscribe on all resources as a finding in its own right. The deeper implication is for tooling: cloud security analysis needs data-flow-aware, cross-service reasoning, of which the solver-encoded conjunction in this write-up is a sketch — otherwise a principal with no Secrets Manager permissions can still end up holding the secrets.