The backdoor your password reset never touched
An attacker with the right permission mints a long-lived key for a privileged GCP service account. It survives password resets, session revocation, and works from anywhere. Here is the persistence, and how to remove it.
You kicked the attacker out, revoked the sessions, reset the passwords. They walked right back in minutes later. Something you did not touch let them.
What it is
In GCP, an identity that can create service-account keys can mint a long-lived JSON key for a privileged service account. That key is a standalone credential: it works from anywhere, survives password changes and session revocation, and is easy to overlook because it is not tied to a human login. An attacker who briefly holds such access creates a key for a powerful account and keeps a durable backdoor even after their original foothold is closed. This is T1098 (account manipulation, additional cloud credentials).
Why it works
It is not a session and not a password, so the usual response, resetting and revoking, does nothing to it. Long-lived keys often go unmonitored, so the backdoor can sit quietly until it is used.
How to detect it
In Cloud Audit Logs, look for a CreateServiceAccountKey event for a privileged service account from a principal that does not normally manage it, and the new key authenticating from an unexpected origin.
The fix that holds
Disable service-account key creation org-wide with org policy, and use short-lived credentials such as Workload Identity Federation or service-account impersonation instead of keys. Restrict the serviceAccountKeyAdmin role tightly, and alert on any key creation. When you respond, find and delete every key the attacker may have minted, not just the first one.
Practice it
We built a service-account key persistence scenario in GraphLattice Range so teams learn why the incident is not over when the foothold is closed, and how to clear standalone keys for good.