Data Secrets
Challenge Lab (Medium) - by Tyler Ramsbey
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
Objective / Scope
The Hack Smarter Red Team started offering AWS Pentesting. The client's primary concern is whether an attacker is able to gain access to their Secrets Manager.
Your task is to begin with the starting credentials, and see if you're able to perform lateral movement & privilege escalation to gain access to their AWS Secrets Manager. This is where the final flag is located.
AWS Pentesting Course
If you are new to AWS Pentesting, we have a full course available: Intro to AWS Pentesting. Use this voucher to get an exclusive 10% discount on the course: 638b012a7510.
Summary
Summary
In Data Secrets we begin with limited AWS IAM credentials and enumerate accessible services within the target cloud environment. Discovering an EC2 instance through describe-instances, we extract its user-data, revealing base64-encoded initialization scripts that expose SSH credentials. Using these, we gain shell access as ec2-user on the instance and harvest temporary IAM credentials from the instance metadata service, assuming the attached cg-ec2-role. With expanded permissions, we enumerate Lambda functions and extract embedded environment variables containing additional IAM keys for a lambda-user account. Leveraging this higher-privilege identity, we access AWS Secrets Manager and retrieve the cg-final-flag secret.
Setup
Whitelist IP & Creation Of The Scenario
We access the lab environment via the provided web interface to ensure our IP is whitelisted and the scenario is properly initialized.
From the Command Output we can retrieve the access_key and secret_access_key to configure our aws profile to access the lab environment.
Configure Profile
We configure a dedicated AWS CLI profile using the provided credentials.
Verify Access
We confirm that the credentials are valid and identify the AWS account and IAM principal we are operating as.
Recon
The focus of this scenario is solely on AWS. We have credentials and are trying to extend our privileges to gain access to the AWS Secrets Manager, where the final flag is hidden.
While solving the scenario, I found the following resource very helpful, as it provides us with a checklist that we can use to test.
During the reconnaissance phase, we attempt to identify and locate various key resources in the AWS environment.
Including EC2 instances, S3 buckets, lambda functions.
The scenario is generous, and with the credentials available, we only have limited access.
We list the running EC2 instances and find one, but nothing else, so we focus on this for now.
Amazon EC2 (Elastic Compute Cloud) instances are virtual servers provided by Amazon Web Services that run applications in the cloud.
Our IAM user is allowed to describe the EC2 instance. This allows us to view information about EC2 instances in the account, including instance IDs, public/private IPs, security groups, IAM instance profiles, and metadata settings. It is read-only access, meaning we can enumerate infrastructure but cannot start, stop, modify, or access the instance itself - for now.
From our enumeration we note down the following public ip of the instance:
Furthermore the id:
Next, we perform a simple port scan on the instance. We see SSH is available.
Shell as ec2-user
We try to dump the user-data and find a base64 string ...
.. .it's a script that sets the password for the ec2-user and enables password authentication.
We use the credentials to log in to the EC2 instance, and are able to connect.
Access as cg-ec2
EC2 Instance Profile Exploitation
We check our identity and see we have the following role cg-ec2-role-cgidu3qlm2sdqf available.
We reuse our following resource and re-iterate the steps for another recon phase with the new permissions attached to the EC2 instance.
We can query the metadata service like the following.
If we attach the role to the query we are also able to retrieve the credentials for that role.
Access as lambda-user
We continue on the instance and the perform the other actions from the checklist. While attempting to list lambda functions, we find the credentials of a so-called DB user.
We configure another profile on our attacker machine with the credentials found...
... and have access. We are actually lambda-user.
Retrieve the secrets
We use this user to try to access the Secrets Manager. The former checklist recommends checking these as final recommendations in a pentest, but how to access them is not explained.
We look at the official documentation:
We found the following resource: cg-final-flag-cgidu3qlm2sdqf.
We query the value of that and retrieve the flag.
Last updated
Was this helpful?