AWS Secrets Manager Overpermission: From List to Leak

AWS Secrets Manager Overpermission: From List to Leak

Secrets Manager findings fail when the reporter only shows secretsmanager:ListSecrets on a role nobody can assume. They succeed when a reachable identity can GetSecretValue on secrets that unlock something real—or when the list itself exposes naming patterns that unlock another attack.

Start from an identity you already have: SSRF-stolen task role, CI OIDC role, or a least-privilege researcher role in a cloud pentest.

Read the policy like an attacker

Dangerous shapes:

• Resource: "*" on secretsmanager:*
• GetSecretValue on arn:aws:secretsmanager:*:ACCOUNT:secret:*
• Wildcard suffixes that were meant to match app/prod/* but match everything
• Missing KMS constraints when the secret uses a customer key

DescribeSecret and ListSecrets alone can still be medium if secret names include customer ids, partner API targets, or staging credentials that invite phishing of internal tools. Say what the names reveal. Do not paste live secret strings into public trackers; use a canary secret or a truncated hash.

Watch for resource policies on the secret itself. A tight IAM role still loses if the secret resource policy allows a broad principal. Pull both documents when you can. Managed policies named like SecretsManagerReadWrite attached to a web tier role are a giveaway during GetRolePolicy / ListAttachedRolePolicies recon.

Tag-based conditions (secretsmanager:ResourceTag/Environment=dev) look precise until every secret shares the same tag. Test whether prod secrets carry the same tags as staging before trusting that gate.

Proof steps that stay polite

1. Call ListSecrets and identify one non-production or clearly in-scope secret, ideally one you created with permission.
2. Call GetSecretValue only on that canary or on a secret the program pre-authorized.
3. Show GetCallerIdentity so the role ARN is unambiguous.
4. Note whether binary or string secret types came back, and whether staging versions exist.

If production read is explicitly out of scope, stop at policy analysis plus a dry-run explanation of which ARNs match. Some programs accept that with code references. Others demand a live GetSecretValue. Match their rules.

Cross-account secret shares deserve a special look. A secret shared to an entire OU "for convenience" expands blast radius past the app team.

Application-layer angles

Apps sometimes expose secret names in error messages or admin GraphQL fields, then rely on IAM to save them. Pair an IDOR that returns secretArn with a role that can read it. That chain is stronger than either bug alone.

Rotation configuration matters for remediation text. A readable secret that never rotates is worse than one with automatic rotation and short TTLs—mention what you observed. Lambda rotation failures that leave the previous version active are worth a sentence if you can see version stages.

Remediation that engineers accept

Scope Resource to exact ARNs or prefixes per environment. Split roles so the web tier can read only the secrets it needs. Use resource policies on sensitive secrets as a second gate. Prefer IAM condition keys for VPC or organization boundaries where appropriate. After any exposure, rotate and invalidate old versions.

Overpermission is boring until GetSecretValue works. Make that the headline when you have it.