No password needed: GCP metadata SSH keys and OS Login admin abuse
An attacker writes an SSH key to project-wide metadata and grants itself OS Login admin, getting a shell on every VM. The foothold lives in metadata and IAM, not the session.
In GCP you do not need a password to get a shell. You need the right to write metadata or be granted OS Login admin, and both are control-plane actions that apply across the fleet.
How the attack works
An attacker who has gained IAM rights over Compute resources runs SetCommonInstanceMetadata to add an SSH public key to project-wide metadata, propagating to every instance that honors metadata keys. They also run SetIamPolicy to grant their principal roles/compute.osAdminLogin, giving privileged SSH. They open an interactive shell on a production VM, then query the metadata server for the instance’s attached service account token to pivot to GCP APIs. Because the change is at the metadata and IAM layer, it persists across reboots and applies broadly. In ATT&CK terms this is T1098, Account Manipulation, paired with T1552, Unsecured Credentials.
Why it works
Metadata-write and OS Login-grant rights were too broad and project-wide keys were allowed. The access is established at the control plane, so it does not depend on any one host or session, and it reaches every VM that trusts metadata keys.
How to fix it
Killing one SSH session or rebooting is futile, because a reboot re-reads the poisoned metadata. Remove the injected key from project and instance metadata, revoke the OS Login admin grant, terminate active sessions, and rotate the attached service account token the attacker pulled from the metadata server plus any reachable secrets. For the root cause, restrict who can write metadata and grant OS Login roles, enforce OS Login and block project-wide SSH keys via org policy, and require bastion or IAP-based access with least privilege. Scope impact through the pulled token’s reach across data services, not just the host.
Practice it
We built this as a GraphLattice Range scenario so administrators can rehearse removing the metadata key and the IAM grant, then rotating the token, rather than just killing a session.