AWS Penetration Testing Case Study: Deployment Permissions Created an Indirect Path to Secrets

This white box AWS penetration test of a serverless SaaS application checked whether a deployment role with no direct permission to read secrets could still reach them. It could, indirectly: the role could update the code of functions outside its intended module, and one of those functions ran under an execution role with access to unrelated secrets.

Engagement	Details
Scope	AWS IAM, Lambda, secrets access, and deployment permissions
Approach	White box with controlled exploitation
Effort	8 tester-days, plus 1 tester-day for retesting
Retest	After nine business days: confirmed the original path was closed and that a legitimate deployment still completed

Key takeaways

• A direct attempt to retrieve the protected secret was correctly denied.
• The deployment identity could modify code that would run under an identity permitted to retrieve secrets, creating an indirect route around the expected restriction.
• The demonstration used a dedicated test function and a control secret, introduced no additional permissions, and retrieved no real production passwords.
• After nine business days, the retest confirmed the original path was closed, with one temporary migration exception documented with an owner and an expiry date.

What did the client need tested?

A SaaS provider operated a serverless application in AWS. Test and production resources were logically separated within the same account, and an automated deployment process used a dedicated IAM role.

The engineering team believed the deployment identity could not access sensitive information because it had no direct permission to retrieve application secrets or read production databases.

The assessment examined whether that restriction remained effective when indirect access through application deployment was considered.

The tester received an audit identity for reviewing configuration and a separate identity representing the deployment process. Audit permissions were used only for inspection; the attack-path validation used the deployment identity.

What did the AWS penetration test find?

A direct attempt to retrieve the protected secret was correctly denied.

However, the deployment role could update the code of functions outside its intended application module. One of those functions used an execution role with broader access than its current purpose required, including access to unrelated secrets.

This created an indirect route around the expected restriction.

The deployment identity could not retrieve a secret itself, but it could modify code that would run under an identity permitted to retrieve it.

The effective security boundary depended on who could change executable code, not only on who could call the secrets service directly.

The demonstration used a dedicated test function and a control secret covered by the existing permission structure. No additional permissions were introduced to make the test succeed.

The test confirmed access to the control marker without retrieving real production passwords. The report separated that demonstrated capability from the production resources identified through configuration analysis.

Why didn’t the previous IAM review catch it?

The previous review concentrated on the deployment identity’s direct permissions. It did not fully assess the privileges of workloads that identity could modify.

Configuration-analysis tools could flag the broad permissions involved. The penetration test connected those permissions to the actual deployment process and demonstrated why the intended separation of responsibilities did not hold.

How was the indirect path to secrets fixed and retested?

The deployment role was restricted to explicitly assigned functions, and separate deployment identities were introduced for different environments.

Function execution roles were also reviewed. The affected function lost access to secrets unrelated to its operation, while other functions using shared roles were assessed for similar exposure.

One temporary exception remained necessary during migration. It was documented with an owner and an expiry date rather than being marked as resolved simply because it had been acknowledged.

After nine business days, retesting confirmed that the original path was closed. The deployment identity could no longer modify the unrelated function, and the function’s execution role no longer had access to the unrelated secret.

A legitimate deployment was completed successfully to verify that the restrictions had not broken the release process.

Each finding’s retest status is recorded in the report, as in section 7 of our sample penetration test report.

Key takeaway

Denying direct access to secrets is not sufficient when the same identity can modify code executed with more powerful permissions.

Need the same test for your AWS environment?

This engagement was a white box test of AWS IAM, Lambda, secrets access, and deployment permissions, with controlled exploitation: 8 tester-days, plus 1 tester-day for retesting. For a black box view of the same cloud, our Black Friday readiness case study describes a public S3 bucket whose backup logs held internal API keys.

Infrastructure and cloud tests at Pentestica run $5,000–$12,000+; see how tester-days translate into a fixed price, or request a pentest quote with your accounts, identities, and deployment pipeline in scope.