Impersonate GCP Service Account for Privileged Access

What this lab covers

You discover a version control directory reachable over the web, reconstruct the repository from it, recover a service account key file, and use that identity to enumerate the project and escalate through impersonation.

Two distinct mistakes combine here. Initialising a repository inside the web root exposes history, and committing a credential puts something worth finding in that history. Either alone is survivable.

It assumes no prior GCP experience and is a good demonstration of why source control hygiene is a cloud security concern.

How exposed repositories lead to cloud compromise

A .git directory contains the complete object database for a repository. If it is served by a web server, its contents can be retrieved and the repository reconstructed, including branches and commits that were never intended to be published.

Service account key files are the target. In Google Cloud these are JSON files containing a private key that authenticates as the service account, they do not expire by default, and they are frequently committed during early development because they make local testing convenient.

Once authenticated, the escalation path is the familiar Google Cloud one. The recovered identity is enumerated for its permissions, and any token creation rights over other service accounts allow movement to identities with broader access, which is why a low-privilege key is often not the end of the story.

How to detect this in your own environment

Monitor for requests to version control paths in your web logs. Requests for .git paths are almost always reconnaissance and rarely have a legitimate explanation, which makes this a clean detection.

Watch for service account key usage from unfamiliar locations. Keys used by applications authenticate from predictable infrastructure, so authentication from elsewhere is a strong signal that the key has left the environment.

Alert on service account key creation. Keys are the durable credential in Google Cloud, so their creation is worth knowing about, and most environments should be creating very few.

How to prevent it

Disable service account key creation with an organization policy and use workload identity federation instead. This removes the class of credential entirely rather than trying to keep it safe, and it is the single highest-impact control here.

Ensure web servers do not serve dotfiles and directories, and keep repositories out of document roots. Both are one-line configuration changes.

Rotate rather than delete. A key that has ever been committed should be considered compromised, so disabling it is the remediation and cleaning history is housekeeping.

Real-world context

Exposed .git directories remain a common finding in external assessments and are trivially discoverable at scale. The consequence ranges from source disclosure to full credential compromise depending on what the history contains.

Service account keys are the Google Cloud credential most often found in repositories, and they are long-lived by default. That combination is why Google's own guidance now emphasises avoiding key creation in favour of federation.

The pattern maps to MITRE ATT&CK T1552.001 Credentials In Files, T1078.004 Cloud Accounts and T1548 Abuse Elevation Control Mechanism.

Applying this at work

• Check your own web servers for reachable .git directories. It takes one request per host.
• Apply an organization policy disabling service account key creation, and migrate existing users of keys to workload identity federation.
• Inventory existing service account keys and their age, then disable those nobody can account for.
• Scan repository history, not just working trees, for credential files.
• Add web log detection for requests to version control paths.

Frequently asked questions

What can an attacker do with an exposed .git directory?

Reconstruct the entire repository including full commit history. That reveals source code and any credential ever committed, even if it was removed from the current version of the files.

Why are GCP service account keys particularly risky?

They are long-lived JSON files that authenticate as the service account and do not expire by default. Once one leaves the environment it remains valid until someone explicitly disables it.

What should be used instead of service account keys?

Workload identity federation, which issues short-lived credentials through a trust relationship. Google's own guidance recommends avoiding key creation, and an organization policy can prevent it entirely.

Do I need my own Google Cloud account to practice this?

No. The lab runs in a live Google Cloud environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own project.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.