AWS Security — S3cret Santa | Advent of Cyber 2025 Day 23 | Writeup

 Access the room: https://tryhackme.com/room/cloudenum-aoc2025-y4u7i0o3p6

Press enter or click to view image in full size


One of our stealthiest infiltrated elves managed to hop their way into Sir Carrotbane’s office and, lo and behold, discovered a bundle of cloud credentials just lying around on his desktop like forgotten carrots. The agent suspects these could be the key to regaining access to TBFC’s cloud network. If only the poor hare had the faintest clue what “the cloud” is, he’d burrow in himself. Let’s help the elf utilise these credentials to try to regain access to TBFC’s cloud network.

Learning Objectives

  • Learn the basics of AWS accounts.
  • Enumerate the privileges granted to an account, from an attacker’s perspective.
  • Familiarise yourself with the AWS CLI.

Step by Step Walkthrough

Initial Setup

Start the target machine as instructed to access the lab environment.

Allow 3–5 minutes for the VM to fully load and the AWS environment to set up. You can check the AWS version in the terminal, and if it returns the correct version number, you’re ready to proceed.

aws --version
Press enter or click to view image in full size

Fetching Credentials using AWS CLI

You can access AWS accounts programmatically with an Access Key ID and a Secret Access Key. In this setup, both will be automatically configured for you. The AWS CLI checks for credentials in ~/.aws/credentials, where you’ll find something like this:

aws_access_key_id = AKIAU2VYTBGYOYXYZXYZ
aws_secret_access_key = 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

Amazon Security Token Service (STS) lets us use the credentials of a user saved during our AWS CLI setup. With the get-caller-identity command, we can fetch details about the user configured for the AWS CLI. Let’s run this command:

aws sts get-caller-identity
Press enter or click to view image in full size

Here we found the the UserID and the Account parameter!

IAM Overview

Amazon Web Services utilises the Identity and Access Management (IAM) service to manage users and their access to various resources, including the actions that can be performed against those resources. Therefore, it is crucial to ensure that the correct access is assigned to each user according to the requirements. Misconfiguring IAM has led to several high-profile security incidents in the past, giving attackers access to resources they were not supposed to access. Companies like Toyota, Accenture and Verizon have been victims of such attacks in the past, often exposing customer data or sensitive documents. Below, we will discuss the different aspects of IAM that can lead to sensitive data exposure if misconfigured.

IAM Users

A user represents a single identity in AWS. Each user has a set of credentials, such as passwords or access keys, that can be used to access resources. Furthermore, permissions can be granted at a user level, defining the level of access a user might have.

IAM Groups

Multiple users can be combined into a group. This can be done to ease the access management for multiple users. For example, in an organisation employing hundreds of thousands of people, there might be a handful of people who need write access to a certain database. Instead of granting access to each user individually, the admin can grant access to a group and add all users who require write access to that group. When a user no longer needs access, they can be removed from the group.

IAM Roles

Press enter or click to view image in full size

An IAM Role is a temporary identity that can be assumed by a user, as well as by services or external accounts, to get certain permissions. Think of Sir Carrotbane, and how, depending on the battle ahead, he might need to assume the role of an attacker or a defender. When becoming an attacker, he will get permission to wield his shiny swords, but when assuming the role of a defender, he will instead get permission to carry a shield to better defend King Malhare.

IAM Policies

Access provided to any user, group or role is controlled through IAM policies. A policy is a JSON document that defines the following:

  • What action is allowed (Action)
  • On which resources (Resource)
  • Under which conditions (Condition)
  • For whom (Principal)

Consider the following hypothetical policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificUserReadAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/Alice"
},
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::my-private-bucket/*"
}
]
}

This policy lets the AWS user Alice (Principal) retrieve an object (Action) from the S3 bucket called my-private-bucket (Resource).

Enumerating Users through AWS CLI

Alright, let’s see what we can do with the credentials we got from Sir Carrotbane’s office, since we have already configured them in our environment.

Let’s start exploring the AWS CLI to gather more details. First, we’ll list the users by running the following command in the terminal:

aws iam list-users
Press enter or click to view image in full size

We’ll see an output that lists all the users, along with other useful details like their creation date. For now, we only have one user sir.carrotbane.

Let’s see what inline policies are assigned to sir.carrotbane by running the following command:

aws iam list-user-policies --user-name sir.carrotbane
Press enter or click to view image in full size

We found a inline policy named as SirCarrotbanePolicy.

Maybe sir.carrotbane has some policies linked to their account. We can check by running this command:

aws iam list-attached-user-policies --user-name sir.carrotbane
Press enter or click to view image in full size

We didn’t find any attached policies when we ran the command. Maybe we can check if Sir Carrotbane is part of a group by running this command:

aws iam list-groups-for-user --user-name sir.carrotbane
Press enter or click to view image in full size

Looks like sir.carrotbane isn’t a member of any group.

Let’s go back to the inline policy we discovered for Sir Carrotbane’s account and check what permissions it grants by running this command:

aws iam get-user-policy --policy-name "SirCarrotbanePolicy" --user-name sir.carrotbane
Press enter or click to view image in full size

It seems Sir Carrotbane can only list the various users, groups, roles, and policies (IAM entities), which doesn’t really help in restoring TBFC’s access. We might need to try a different approach. On the bright side, if you look closely, sir.carrotbane does have permission to perform the sts:AssumeRole action.

Enumerating Roles through AWS CLI

The sts:AssumeRole action we previously found allows sir.carrotbane to assume roles. Perhaps we can try to see if there's any interesting ones available. Let's start by listing the existing roles in the account using this command:

aws iam list-roles
Press enter or click to view image in full size

Here the role called bucketmaster can be taken on by sir.carrotbane.


Let’s see which policies are assigned to this role. Similar to users, roles can have both inline and attached policies. To view the inline policies, run the following command:

aws iam list-role-policies --role-name bucketmaster
Press enter or click to view image in full size

The role has a single policy assigned to it, called BucketMasterPolicy.

Let’s check if there are any policies attached to the role by running the following command:

aws iam list-attached-role-policies --role-name bucketmaster
Press enter or click to view image in full size

There is no other Attache policies here, it looks like we only have the inline policy assigned.

Let’s see what permissions we can get from the policy BucketMasterPolicy by using the following command:

aws iam get-role-policy --role-name bucketmaster --policy-name BucketMasterPolicy
Press enter or click to view image in full size

It looks like the bucketmaster role can perform three actions — ListAllBucketsListBucket, and GetObjecton certain resources in a service called S3. This could be the breakthrough we’ve been hoping for.

Assuming Role using Security Tokens

To gain privileges assigned by the bucketmaster role, we need to assume it. We can use AWS STS to obtain the temporary credentials that enable us to assume this role.

This command tells STS, the AWS service for managing security tokens, to create temporary credentials for assuming the bucketmaster role. These credentials will be tied to the session name "TBFC" (though you can choose any name you like). Now, let’s run the command:

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/bucketmaster --role-session-name TBFC

The output will provide us the credentials we need to assume this role, specifically the AccessKeyIDSecretAccessKey and SessionToken.

To be able to use these, run the following commands in the terminal, replacing with the exact credentials that you received on running the assume-role command.

export AWS_ACCESS_KEY_ID="ASIARZPUZDIKOZD2EG4X"
export AWS_SECRET_ACCESS_KEY="6AP7p1ZYwQoYkIyvLxX9a4YMOQU31QOYYg63E2t/"
export AWS_SESSION_TOKEN="FQoGZXIvYXdzEBYaDYZCm5+rK/XHLsTGv2P3Tek2cghTZ+3v5E+UtDEf7CGTZV0qNRIB+jGspdyzGhMLUKRKN7io4aFEq3EJUxyDz1xDXRuimFugylcbMSJY8r0nVLyReJxrDjDeWzMAGx3MdKJJW+z3+/zXED8ShpIUyRl9whY61U62hhEfF3s0SAViychnTqj2HcXqoU1i8nwZhirs7A+n6QU/rHNllXMotKAl0lAmp3Uu7B1My0nNhE6JGqbNVnAvvaOvck9uip1Vfo1Qe2Srj0iyWenV/O8hdeXDdG76rSA+OonvFZBuoMhuXzbKzXxMpyZAkIsoWb4Vye/tNDL9A6JWh8gkSts="
Press enter or click to view image in full size

Once we have done that, we can officially use the permissions granted by the bucketmaster role. To check if you have correctly assumed the role, you can once again run:

aws sts get-caller-identity
Press enter or click to view image in full size

This time, it should show you are now using the bucketmaster role.

What Is S3?

Amazon S3, short for Simple Storage Service, is an object storage service from Amazon Web Services that can hold any kind of data, like images, documents, logs, or backup files. Businesses often use it to store things like website reference images, client-shared documents, or files used by internal systems. Everything stored in S3 goes into a “Bucket,” which you can think of as a cloud-based folder for your files.

Now, let’s see what our newly gained access to Sir Carrotbane’s S3 bucket provides us.


Listing Contents from a Bucket

Since our profile has permission to ListAllBuckets, we can list the available S3 buckets by running the following command:

aws s3api list-buckets

There is one interesting bucket in there that references easter. Let’s check out the contents of this directory:

aws s3api list-objects --bucket easter-secrets-123145
Press enter or click to view image in full size

let’s copy the cloud_password file in this directory to our local machine. This might have a secret message:

aws s3api get-object --bucket easter-secrets-123145 --key cloud_password.txt cloud_password.txt
Press enter or click to view image in full size
Press enter or click to view image in full size

Let's open the extracted text file we retrieved from the S3 bucket

Hooray! We have successfully infiltrated Sir Carrotbane’s S3 bucket and exfiltrated some sensitive data.

Lab Answers

Run aws sts get-caller-identity. What is the number shown for the "Account" parameter?

123456789012.

— — — — — — — — — — — — — — —

What IAM component is used to describe the permissions to be assigned to a user or a group?

policy.

— — — — — — — — — — — — — — —

What is the name of the policy assigned to sir.carrotbane?

SirCarrotbanePolicy.

— — — — — — — — — — — — — — —

Apart from GetObject and ListBucket, what other action can be taken by assuming the bucketmaster role?

ListAllMyBuckets.

— — — — — — — — — — — — — — —

What are the contents of the cloud_password.txt file?

THM{more_like_sir_cloudbane}

أحدث أقدم