Skip to content

AoC3 Day 17: Cloud Misconfigs

    If you are new to TryHackMe, I recommend checking out their Tutorial room to see how the platform works and how you can access the target machine(s). I also highly recommend using your own “attack box”, be it a Kali, Parrot, or some other pentesting oriented Linux distro (in the form of a VM), as opposed to the browser based solution TryHackMe provides. I’ve found that the browser based VM is a lot slower, though others seem to have no issues with it. The only thing using your own attack VM entails is connecting it to THM’s network through VPN, but this is incredibly easy as TryHackMe will supply you with your own OpenVPN configuration file and is outlined below.

    Types of Challenges

    The TryHackMe platform has multiple types of challenges, each potentially having its own requirements for accessing and completing it. You can identify the type of challenge by looking at the icon on the right-hand side of the collapsible bar for that particular challenge:

    Challenges using the “server rack” icon include the use of a deployable machine, and are the most common. Pressing the “Start Machine” button will launch a virtual machine that you have two ways of accessing: using THM’s “attack box”, found at the top of your browser window:

    Or, you can instead opt to use your own virtual machine connected to the THM network, which is done (on Linux) by clicking your user icon, “Access”, and then “Download My Configuration File”.

    Clicking “Save File”

    And by running the following command in a terminal (I might suggest you move the download to another folder, such as “Documents”):

    Once you see “Initialization Sequence Completed”, you’ll know you’ve successfully connected to THM’s network. Keep this terminal window open (you can minimize it, however). Return to it and press “Ctrl” + “C” twice once you are ready to disconnect.

    After you’ve chosen between THM’s attack box or your own virtual machine, you’ll need the IP address of the target machine, which is what was deployed earlier with the green “Start Machine” button. That information can be seen in a banner at the top of your browser window, or in more detail at the top of the page:

    In many cases you’ll be copying that IP address into your attack box/VM’s browser’s address bar, but in other cases you might be accessing it through SSH, RDP, etc. You’ll notice that you can add time to it if needed, or terminate it if you finish early – opening up more resources for other THM users.

    Challenges using the “browser” icon will require interaction with a simulated website that can be accessed by pressing the “View Site” seen after expanding the challenge. These challenges will need to be completed from within your browser, and cannot be accessed through a VPN on your own machine due to the fact that they are not true websites.

    Challenges with the “download” icon include files – in many cases packet captures (pcaps) or log files to be parsed through using a specific type of software. Where you would like to do this examining is up to you, but you will not be able to use one of TryHackMe’s machines. For examining something like a .pcap file, you will want to install Wireshark on one of your own computers or VMs.

    Challenges without an icon focus on either reading material and answering questions, or will include a link to a publicly accessible website that doesn’t require connection to THM’s network, and therefore can be completed from any computer you choose.

    Day 17 of AoC 3 is directed at the identification of misconfigurations of cloud resources in AWS and how they can be leveraged by an attacker or red teamer.

    Because this lab will require the use of AWS CLI to interact with real cloud resources, you will be unable to use the TryHackMe attack box if you are not on a paid subscription, since you won’t have internet connectivity from THM’s network. The link to install the AWS CLI tool is linked to in the challenge description, or can be acccessed here.

    On Linux, it can be installed with the following three commands:

    curl "" -o ""
    sudo ./aws/install

    To find the name of the S3 bucket that the image in the challenge is hosted on, right-click it and choose “Copy Image Link” and paste it into a text editor of your choice.

    We’ll now pivot over to using the AWS CLI interface to see what else is publicly accessible on the bucket. Two files will come in to play in the upcoming questions, including identifying the interesting file.

    To see the message left in flag.txt, download it and print the contents to the terminal with “cat”.

    We’ll want to look deeper into the publicly accessible WordPress backup, so we’ll download “” and unzip it.

    To find the AWS Access Key stored in this backup, we’ll grep its contents searching for a string that starts with “AKIA”. It’s stored in “wp-config.php”, which we’ll look more in depth at.

    To find the AWS Account ID associated with this access key, we’ll want to use the AWS “configure” command to set up a profile using the gathered key and secret

    Validate the creation of the profile by navigating to the hidden .aws directory and printing the config file.

    Using the “sts” (Security Token Service) API, we can reveal the user’s Account ID.

    The same API allows us to find the username associated with our access key.

    To find the EC2 Instance owned by this account, we will interact with EC2 (AWS computing resource) using the profile we created previously.

    aws ec2 describe-instances --output text --profile <profile name>

    Finding the database password stored in Secrets Manager will require us to interact with the Secrets Manager service, also using AWS CLI. We will need to sign our requests with the profile we created earlier for these queries as well. Run the following command in order to get a list of the names of secrets stored under our target account:

    aws secretsmanager list-secrets --profile <profile name>

    In order to retrieve the value, run the following command:

    aws secretsmanager get-secret-value --secret-id HR-Password --version-stage AWSCURRENT --profile <profile name>

    The “SecretString” has a message for us: “The Secret you’re looking for is not in this **REGION**. Santa wants to have low latency to his databases. Look closer to where he lives.” To remedy this and retrieve the database password, we can use the same command, this time using the “–region” argument and the value of which AWS region we think might be the furthest north.