Cloud vulnerability analysis 3 — lambda_privesc (high-level)

Public lab: CloudGoat scenario lambda_privesc (small / easy tier in the original post).

What the scenario is about

• Starting principal: limited IAM user Chris
• Resources in play: IAM users/roles, Lambda, and related assume-role paths
• Stated lab goal in the source: reach broader (admin-class) privileges

Vulnerability class / root cause (concept)

The interesting design pattern is trust chaining across Lambda and IAM:

• A principal that can assume a Lambda-manager style role may also hold iam:PassRole (or equivalent) toward a more powerful role.
• If that principal can create and invoke Lambda functions that run under the passed role, the function’s runtime identity can perform IAM changes the human user could not call directly.
• In abstract terms: PassRole + compute that assumes the passed role turns “I can launch a function” into “I can act as that role.”

This is a classic cloud privilege-escalation class, not a single CVE in the original writeup.

Impact (abstract)

If an environment grants the same combination of permissions to a low-trust identity, that identity could expand its own IAM footprint (for example attach stronger policies) and reach broad account control. In a real account that would mean loss of confidentiality/integrity across attached resources.

Mitigations / what to check

• Prefer least privilege: avoid pairing broad lambda:* / create-invoke rights with iam:PassRole to admin-equivalent roles.
• Constrain PassRole with resource ARNs and condition keys so only intended execution roles can be passed.
• Separate “deploy Lambda” from “attach user policies”; require break-glass / approval for policy attachment.
• Monitor CloudTrail for unexpected CreateFunction, Invoke, PassRole, and AttachUserPolicy / role-policy changes from unusual principals.
• In labs only: use disposable CloudGoat accounts; do not copy lab permission graphs into production.

Solve steps and PoC omitted.