Infiltrate GCP via WebApp Exploitation

What this lab covers

You exploit an application flaw to reach command execution, take the service account credentials available from instance metadata, and use them to understand the project and find the permissions that let you go further.

The lab is a full chain rather than a single technique, which is why it is rated intermediate. Each stage is ordinary, and the combination is what a real compromise looks like.

It suits application security practitioners moving into cloud and Google Cloud engineers who have not traced what a compromised workload actually reaches.

How web compromise becomes GCP compromise

SQL injection can lead to command execution depending on the database and its configuration, and once commands run on the instance, the cloud environment becomes reachable. The application flaw is the entry and the workload's identity is the objective.

Compute Engine instances obtain credentials from a metadata server on a link-local address, reachable from the instance without any stored secret. Anything running on the host can request a token for the attached service account, so execution is equivalent to holding that identity.

Cloud Asset Inventory then accelerates everything. It exists so operators can inventory resources across an organization, and an identity permitted to query it gets a comprehensive answer in one request rather than enumerating service by service. Broad viewer roles are commonly granted for observability and quietly include this.

How to detect this in your own environment

Alert on metadata server access from unexpected processes. Legitimate access comes from SDKs and agents, so a request originating from a web application process or a shell is anomalous and is the earliest reliable host signal.

Watch for service account tokens used from outside the instance. This is theft regardless of how it occurred and does not require recognizing the exploit that produced it.

Treat broad Asset Inventory queries as reconnaissance. Legitimate use is periodic and predictable, so an identity suddenly enumerating organization-wide assets is behaving nothing like the tooling that normally does.

How to prevent it

Scope workload service accounts to the minimum. The instance identity is what an attacker inherits, so its permissions define the impact of every application vulnerability on that host, and default service accounts with editor-level access are the common failing.

Restrict metadata access at the instance level where the workload does not require it, and use parameterised queries so the injection does not occur in the first place.

Review who holds Cloud Asset Inventory and broad viewer permissions. Read access across an organization is not harmless, because it is what converts a foothold into a plan.

Real-world context

Exploitation of internet-facing applications is a leading route into cloud environments, and the pattern of application flaw leading to workload identity leading to broad access is consistent across providers.

Google Cloud's default service account behavior has historically contributed to this. Instances created without an explicitly chosen identity may run with a default account holding wide project permissions, which means the blast radius is set by a default rather than a decision.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1552.005 Cloud Instance Metadata API and T1526 Cloud Service Discovery.

Applying this at work

• Audit which of your instances run with default service accounts and replace them with narrowly scoped identities.
• Review who and what can query Cloud Asset Inventory across your organization.
• Add detection for metadata access from application processes.
• Confirm database access in your applications uses parameterised queries throughout.
• Alert on service account tokens used from outside the instances they belong to.

Frequently asked questions

Why is instance metadata such a common target?

Because it issues credentials for the attached service account to anything that can request them from the host. Code execution on the instance therefore becomes authenticated cloud access without any stored credential being stolen.

What makes Cloud Asset Inventory useful to an attacker?

It returns a comprehensive view of resources across the organization in one query. That replaces slow service-by-service enumeration with a single request, and access to it is often included in broad viewer roles granted for observability.

How do I limit the impact of a compromised workload?

Scope the service account attached to it to the minimum required. That identity is exactly what an attacker inherits, so its permissions determine the consequence of any application vulnerability on that host.

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.