Git Tales: Part 2 - Demons in the Cloud

Part 2 of 3 in Git Tales Series

Introduction

In the previous part of this series, we explored the haunting reality of sensitive secrets buried within Git repositories lurking quietly, waiting to be discovered. This time, we dig deeper into the darkness. This is the tale of cloud credentials: specifically, AWS access keys and GCP service account keys — the demons that, when found, can open portals into your cloud infrastructure.

This is not fiction. These were real credentials found in public GitHub repositories. The implications? Full access to critical cloud resources, with barely any barriers.

The Credentials Purpose

AWS Access Keys - CLI/SDKs

What are they?

AWS Access Keys are used to programmatically interact with AWS resources via the AWS CLI or SDKs.

Typical Use Cases

• Deploying infrastructure via Terraform or CloudFormation
• Automating tasks e.g., S3 uploads, Lambda management
• Integrating CI/CD workflows

Risk When Exposed

If these keys are tied to an IAM user or role with broad permissions, an attacker can

• List and exfiltrate S3 buckets
• Spin up EC2 instances - for crypto mining or persistence
• Access RDS snapshots or EBS volumes
• Destroy resources or disable security services e.g., GuardDuty

GCP Service Account Keys

What are they?

A GCP service account key is a JSON file that authenticates as a service account. It allows full API access according to the permissions granted to that account.

Typical Use Cases

• Interacting with GCP services e.g., Cloud Storage, Pub/Sub, BigQuery
• Running automated workloads in CI/CD pipelines
• Backend services or microservices accessing GCP APIs

Risk When Exposed

With a leaked key, an attacker can:

• Authenticate with gcloud to your cloud project.
• Access or modify GCS buckets.
• Interact with APIs e.g., Cloud SQL, IAM, Compute Engine.
• Move laterally across projects and regions, depending on scope.

Real World Discovery: Resurrecting Cloud Credentials

While hunting for vulnerabilities in a bug bounty program, I focused on a company's public GitHub repositories. One of the most overlooked areas in such assessments is Git history — especially commits related to CI/CD automation.

In this case, I discovered that the organization had once committed credentials within test configuration files, likely used for automation purposes during development. These files were later deleted — a move that gives a false sense of security to many developers 😂. But as any experienced hunter knows, deleting a file doesn't erase its past from Git.

Using basic git log and git show commands, I located the commit hashes and recovered the deleted files.

git log --diff-filter=D --summary | grep delete
git show <commit_hash>:path/to/test-service-account.json

And there it was — the buried treasure.

Finding 1: AWS Key in a Test File

Inside a deleted test config file, I discovered exposed AWS Access key as shown in the example below

[test-s3-eu-central-1]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

I immediately knew this was credentials for Frankfurt region based on the profile setting of test-s3-eu-central-1 and I rushed to CLI to configure this and test the credentials

aws configure --profile orgName-test-s3-eu-central-1
aws sts get-caller-identity --profile orgName-test-s3-eu-central-1
aws s3 ls

The second command above gave the below output in my CLI after configuring the profile confirming the credentials are active.

It worked 😎. The credentials were still active, and the IAM user had access to several buckets and EC2 metadata 🤯. Some even contained staging environment snapshots — a serious data exposure.

Finding 2: GCP Service Account Key Recovered

Another deleted commit in a different organization's public GitHub repo revealed a __json_key used for automated GCP deployments.

I decoded the credentials from base64 encoding and then saved them to a file org-sa-creds.json for authentication via gcloud.

gcloud auth activate-service-account --key-file=org-sa-creds.json
gcloud projects list
gcloud projects get-iam-policy PROJECT-ID \ --filter="bindings.members:serviceAccount:[email protected]" \ --format="json

The final command above can be used to view GCP IAM policy of the service account. Please NOTE this can only be successful based on permissions given to the service account.

Below is the service account authentication via gcloud

The key was valid, and I was able to enumerate projects, enumerate permissions, list GCS buckets, view/download bucket objects, and access compute resources — all tied to the target organization.

Consequences of Exposure

Business Risk

• Data exfiltration and theft.
• Infrastructure hijack for crypto mining or botnets.
• Compliance violations e.g GDPR, HIPAA,etc..
• Reputation damage if incidents go public.

Attack Vector Expansion

• Persistence using created IAM users or service accounts.
• Privilege escalation via over-permissive roles.
• Lateral movement across multi-cloud or hybrid setups.

Lessons from the Shadows

1. Scan before you commit - use tools like git-secrets and Gitleaks.
2. Automate secrets detection - CI/CD pipelines should fail if secrets are detected.
3. Use short-lived credentials - prefer IAM roles and workload identity over static keys.
4. Audit and rotate - regularly audit credential usage and rotate keys periodically. But you know this rarely happens😁
5. Restrict and monitor - apply least privilege and set up anomaly detection using resources like AWS GuardDuty, GCP Security Command Center.

Final Thoughts

Cloud credentials are among the most powerful and dangerous secrets to leave in your Git history. In the wrong hands, they can become the demons that burn your cloud kingdom to the ground.

This is the second tale of our git tales 😁. In the final tale of the Git Tales series, we’ll dive into:

📝 Part 3: How committed Github tokens and Azure ACR creds can expose your private repos and container Images.

"Stay vigilant. Stay paranoid. Your cloud deserves it! 🫠🫠🫠" - @davisbug