GCP service account impersonation chain → project owner

§ Context

Assumed environment: target uses GCP with several service accounts and 'impersonation' permissions granted transitively (common pattern when teams mirror AWS role-assumption).

§ Steps

1. 01
   Foothold SA credentialsInitial Access

   T1078— Valid Accounts
2. 02
   Enumerate impersonation graphDiscovery

   T1087— Account Discovery
3. 03
   Impersonate higher-priv SAPrivilege Escalation

   C-GCP-SA-IMPERSONATE— GCP Service Account Impersonation
4. 04
   Impersonate intermediate SAPrivilege Escalation

   C-GCP-SA-IMPERSONATE— GCP Service Account Impersonation
5. 05
   Create a long-lived JSON key on the Owner SAPrivilege Escalation

   C-GCP-SA-KEY-CREATE— GCP iam.serviceAccountKeys.create
6. 06
   Backdoor low-noise SA for re-entryPersistence

   C-GCP-IAM-BACKDOOR— GCP Service Account Backdoor Key

§ References

• T1078Valid Accounts
• T1087Account Discovery

§ Frequently asked

What is the "GCP service account impersonation chain → project owner" attack path?

Compromised low-priv SA has iam.serviceAccounts.getAccessToken on an intermediate SA; hop through 2-3 impersonations until you reach a project Owner. It chains 6 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Foothold SA credentials (T1078) — a initial access primitive. Assumed environment: target uses GCP with several service accounts and 'impersonation' permissions granted transitively (common pattern when teams mirror AWS role-assumption).

What is the final impact of this kill-chain?

The final step lands on Backdoor low-noise SA for re-entry (C-GCP-IAM-BACKDOOR), which falls under Persistence. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques2

  z/OS TN3270 → RACF userID brute → mainframe shell

  Internet-/intranet-exposed TN3270 mainframe terminal. Userids follow predictable HR scheme. Brute-force passwords; many environments allow short / dictionary passwords for legacy reasons.

• Shared techniques2

  Slack token in CI log → DM history → vendor mailbox compromise

  A CI run echoed a Slack xoxb-/xoxp- token. Use it to read DMs, harvest password-reset links and vendor invitations, pivot into the corporate mailbox.

• Shared techniques2

  Open MQTT broker → smart-estate takeover

  Shodan-indexed MQTT broker on TCP/1883 with no auth. Subscribe to '#' to harvest every device topic; publish to relays/locks/lights/thermostats.

• Shared techniques2

  TCC bypass → access Photos / Camera without consent

  Inject into a process that already has Full Disk Access (e.g. backup utility, Terminal). Inherited TCC entitlement lets the attacker code read TCC-gated data — Photos, iMessage DB, Documents.

• Shared techniques2

  Service account → SYSTEM via named-pipe impersonation

  Service-context shell has SeImpersonatePrivilege. Use Potato-family tools (Juicy / Rogue / Print / God) to coerce SYSTEM to authenticate to an attacker-controlled named pipe, then impersonate the token.

• Shared techniques2

  Secret echoed to public build log → cloud takeover

  A workflow accidentally runs `env` or `set -x` during debugging — the AWS access key is now in public CI logs and indexed by Google Cache / GitHub search.