Cloud Security

Thunder CTF Walkthrough: Part 1

Cloud Security
Mar 1, 2023
6 mins
Saumya Kasthuri

Thunder CTF is a fantastic opportunity to challenge your skills, expand your knowledge, and test your understanding of GCP security. The competition is designed to simulate real-world scenarios, so the challenges you’ll face will be similar to the types of security issues that you might encounter in a real-world environment.

In this blog series, I’ll be covering each of the challenges presented in the Thunder CTF, and providing step-by-step solutions to help you complete each challenge successfully.

In part 1, I’ll be covering the first 2 levels:

Level 1 : Find the secret from the file stored in storage bucket

Level 2 : Find the credit card details of the specified user

For set-up related details please have a look at

Ready? Let’s get started and dive into the world of GCP security with the Thunder CTF challenges!

Level 1: Find the secret from the file stored in storage bucket

Level 1 involves finding a secret that has been stored in a file in a Google Cloud Storage bucket. In this challenge, we have to access the contents of the storage bucket and locate the secret file within it.

This challenge provides a great introduction to working with Google Cloud Storage and the gsutil tool, and requires participants to use basic knowledge of file management and command-line tools.

For set-up related details please have a look at

  1. While creating the instance the bucket name is been mentioned in the message.
  2. List all storage buckets for a project using the command-line interface.
    gsutil ls gs://bucket_name
  3. Copy a secret file stored within a bucket left open
    gsutil cp gs://bucketname/secret.txt .

📌Google Storage Bucket

📌Google Cloud console endpoints

Level 2 : Find the credit card details of the specified user

Level 2 of the Thunder CTF challenges focuses on finding the credit card details of a specified user (Here it is EDWARD DUNCAN). To procced with this level we need to activate the service account given to us.

📌 Service Account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.

Typically, service accounts are used in scenarios such as:

  • Running workloads on virtual machines (VMs),
  • Running workload on-premises workstations or data centers that call Google APIs.
  • Running workloads which are not tied to the lifecycle of a human user.

Your application assumes the identity of the service account to call Google APIs , so that the users aren’t directly involved.

To authorize access to Google Cloud with a service account
gcloud auth activate-service-account [ACCOUNT] — key-file=KEY_FILE [ — password-file=PASSWORD_FILE | — prompt-for-password] [GCLOUD_WIDE_FLAG …]

1. Activate a service account credential:
gcloud auth activate-service-account — key-file=start/a2-access.json

Activated the service account

2. List permissions associated with a credential: In thunder ctf, in scritps, checks for the permissions associated with the role/accesstoken.

Listed the permissions usinf the

Via GCP console also we can check the role associated wit the service account

Roles associated with the project

Permissions associated with the a2-access role

3. Download the contents of an accessible bucket.
gsutil cp -r gs://bucketname/ .

4. Navigate a git repository that previously contained a sensitive ssh key.

5. Checkout repository version containing the initial commit of the key.(ssh_key retrieved)

6. List project’s VM instances to find one containing an ssh key in its Metadata.
gcloud compute instances list

7. Describe the instance
gcloud compute instances describe <instance_name>

8. ssh into the instance and use its role to access the project’s logging service.

📌 Access tokens are opaque tokens that conform to the OAuth 2.0 framework.
They contain authorization information, but not identity information.
They are used to authenticate and provide authorization information to Google APIs.
Which are opaque objects that cannot be inspected by the application
By default, access tokens are good for 1 hour (3,600 seconds). When the access token has expired, your token management code must get a new one.

📌I D tokens are JSON Web Tokens (JWTs) that conform to the OpenID Connect (OIDC) specification
ID tokens are meant to be inspected and used by the application
Information from the token, such as Who signed the token or the identity for whom the ID token was issued, is available for use by the application.
When your service or application uses a Google service such as Cloud Run, Cloud Functions, or Identity-Aware Proxy, Google validates ID tokens for you; in these cases, the ID tokens must be signed by Google.
ID tokens are valid for up to 1 hour (3,600 seconds). When an ID token expires, you must acquire a new one.

9. gcloud auth print-identity-token

10.gcloud auth print-access-token

11. Check the permissions associated with the access token. Loggnig permissions are there.

12. Find credit-card numbers in log entries that have not been properly sanitized.
gcloud logging logs list

📌 gcloud logging — manage Cloud Logging. gcloud logging that provide a command-line interface to the Logging API.

gcloud logging commands are controlled by Identity and Access Management (IAM) permissions.

To use any of the gcloud logging commands, you must have the permission. You must also have the IAM role that corresponds to the log's location, and to your use case:


Build a website that actually performs better.

Lorem ipsum dolor sit amet consectutar
Lorem ipsum dolor sit amet consectutar
Lorem ipsum dolor sit amet consectutar