GCP IAM Service Account Impersonation Role Granted
Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator",…
Description
Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator", "roles/iam.serviceAccountUser", and "roles/iam.serviceAccountOpenIdTokenCreator" allow a principal to mint access or identity tokens for the target service account, or to act as it when deploying resources. Adversaries who have obtained sufficient privileges may grant themselves or an attacker-controlled principal one of these roles to impersonate a higher-privileged service account, escalating privileges and establishing durable, key-less persistence that survives credential rotation. This is a New Terms rule that alerts when the granting principal has not been observed performing this action in the last weeks.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersESXiIaaSIdentity ProviderLinuxmacOSNetwork DevicesOffice SuiteSaaSWindows
The rule states no platform. This is derived from the ATT&CK technique it maps to.
- Log source category
- event_index
Known benign triggers
- Administrators may grant impersonation roles when onboarding new applications or delegating access. Verify that the grant aligns with a known change and that both the granting principal and the added member are expected.
- Infrastructure-as-code tooling (e.g. Terraform), CI/CD pipelines, and platform automation routinely grant serviceAccountUser or serviceAccountTokenCreator when wiring up workloads, deployments, or impersonation chains. Identify the expected automation principals and target service accounts and add exceptions for them.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| cloud.google.com/iam/docs/audit-logging/examples-service-accounts | Only this detection cites it |
| cloud.google.com/iam/docs/service-account-impersonation | Only this detection cites it |
| securitylabs.datadoghq.com/cloud-security-atlas/attacks/backdooring-service-account/ | Only this detection cites it |
| stratus-red-team.cloud/attack-techniques/GCP/gcp.persistence.backdoor-service-account-policy/ | Only this detection cites it |
From the source
- At source
- Open at source
- Upstream identifier
- 197d2757-eea1-46f9-9ebd-84646d2b45fa
- Tagged by the source as
- Data Source: GCPData Source: GCP Audit LogsData Source: Google Cloud PlatformDomain: CloudNoise: UnknownPerformance: NormalPlatform: GCPResources: Investigation GuideRule Type: New TermsTactic: PersistenceTactic: Privilege EscalationUse Case: Identity and Access AuditUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Published
- Sep 20, 2026
- Version
- 3