GCP - Apigee Post Exploitation

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Apigee metadata SSRF -> Dataflow cross-tenant pivot

A single Apigee tenant project can be abused to reach the Message Processor metadata server, steal its service account, and pivot into a shared Dataflow analytics pipeline that reads/writes cross-tenant buckets.

Expose the metadata server through Apigee

  • Set an Apigee proxy target to http://169.254.169.254 and request tokens from /computeMetadata/v1/instance/service-accounts/default/token with Metadata-Flavor: Google.
  • GCP metadata rejects requests containing X-Forwarded-For; Apigee adds it by default. Strip it with AssignMessage before proxying:
<AssignMessage name="strip-xff">
  <Remove>
    <Headers>
      <Header name="X-Forwarded-For"/>
    </Headers>
  </Remove>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Enumerate the stolen Apigee service account

  • The leaked SA (Google-managed under gcp-sa-apigee) can be enumerated with tools like gcpwn to quickly test permissions.
  • Observed powerful permissions included Compute disk/snapshot admin, GCS read/write across tenant buckets, and Pub/Sub topic publish. Basic discovery:
gcloud compute disks list --project <tenant-project>

Snapshot exfiltration for opaque managed services

With disk/snapshot rights you can inspect managed runtimes offline even if you cannot log into the tenant project:

  1. Create a snapshot of a target disk in the tenant project.
  2. Copy/migrate the snapshot to your project.
  3. Recreate a disk from the snapshot and attach it to your VM.
  4. Mount and inspect logs/configs to recover internal bucket names, service accounts, and pipeline options.

Dataflow dependency replacement via writable staging bucket

  • Analytics workers pulled JARs from a GCS staging bucket on startup. Because the Apigee SA had bucket write, download and patch the JAR (e.g., with Recaf) to call http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token and steal the Dataflow worker token.
  • Dataflow workers lacked internet egress; exfiltrate by writing the token into an attacker-controlled GCS bucket using the in-cluster GCP APIs.

Force malicious JAR execution by abusing autoscaling

Existing workers will not reload replaced artifacts. Flood the pipeline input to trigger new workers:

for i in {1..5000}; do
  gcloud pubsub topics publish apigee-analytics-notifications \
    --message "flood-$i" --project <tenant-project>
done

Newly provisioned instances fetch the patched JARs and leak the Dataflow SA token.

Cross-tenant bucket design flaw

Decompiled Dataflow code showed cache paths like revenue/edge/<api|mint>/tenant2TenantGroupCacheDir under a shared metadata bucket, without any tenant-specific component. With the Dataflow token you can read/write:

  • tenantToTenantGroup caches exposing other tenants’ project+environment names.
  • customFields and datastores folders holding per-request analytics (including end-user IPs and plaintext access tokens) across all tenants.
  • Write access implies potential analytics tampering/poisoning.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks