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", "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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/05/30"
  3integration = ["gcp"]
  4maturity = "production"
  5updated_date = "2026/05/30"
  6
  7[rule]
  8author = ["Elastic", "Aryu Zaw"]
  9description = """
 10Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a
 11SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator", "roles/iam.serviceAccountUser", and
 12"roles/iam.serviceAccountOpenIdTokenCreator" allow a principal to mint access or identity tokens for the target service
 13account, or to act as it when deploying resources. Adversaries who have obtained sufficient privileges may grant
 14themselves or an attacker-controlled principal one of these roles to impersonate a higher-privileged service account,
 15escalating privileges and establishing durable, key-less persistence that survives credential rotation. This is a New
 16Terms rule that alerts when the granting principal has not been observed performing this action in the last weeks.
 17"""
 18false_positives = [
 19    """
 20    Infrastructure-as-code tooling (e.g. Terraform), CI/CD pipelines, and platform automation routinely grant
 21    serviceAccountUser or serviceAccountTokenCreator when wiring up workloads, deployments, or impersonation chains.
 22    Identify the expected automation principals and target service accounts and add exceptions for them.
 23    """,
 24    """
 25    Administrators may grant impersonation roles when onboarding new applications or delegating access. Verify that the
 26    grant aligns with a known change and that both the granting principal and the added member are expected.
 27    """,
 28]
 29from = "now-9m"
 30index = ["logs-gcp.audit-*"]
 31language = "kuery"
 32license = "Elastic License v2"
 33name = "GCP IAM Service Account Impersonation Role Granted"
 34note = """## Triage and analysis
 35
 36### Investigating GCP IAM Service Account Impersonation Role Granted
 37
 38Granting an impersonation role on a service account lets the bound member obtain that service account's credentials
 39without creating a long-lived key. `roles/iam.serviceAccountTokenCreator` and `roles/iam.serviceAccountOpenIdTokenCreator`
 40allow minting OAuth2 access tokens and OpenID Connect identity tokens, while `roles/iam.serviceAccountUser` allows the
 41member to attach (actAs) the service account to new resources. Adversaries abuse these grants to pivot to a
 42higher-privileged identity, escalate privileges, and persist in a way that is unaffected by key rotation or password
 43resets.
 44
 45### Possible investigation steps
 46
 47- Identify the granting principal via `user.email` and `user.id` and confirm whether that identity is expected to modify
 48IAM policy on service accounts.
 49- Review the target service account in `gcp.audit.resource_name` and determine the permissions it holds. Impersonating a
 50service account with broad project or organization roles represents a significant escalation.
 51- Inspect the granted binding in `gcp.audit.request` / `gcp.audit.response` to identify the member that was added
 52(`user:`, `serviceAccount:`, `group:`, or an external domain). External or newly created members are higher risk.
 53- Examine `gcp.audit.request_metadata.caller_ip` and `gcp.audit.request_metadata.caller_supplied_user_agent` to assess
 54whether the change originated from an expected location or tool.
 55- Correlate with recent activity by the granting principal, such as service account key creation, custom role creation,
 56or `GenerateAccessToken` / `GenerateIdToken` calls that use the newly granted impersonation rights.
 57
 58### False positive analysis
 59
 60- Terraform, Deployment Manager, and CI/CD service accounts commonly grant serviceAccountUser and
 61serviceAccountTokenCreator as part of normal provisioning. Baseline these principals and exclude them with exceptions.
 62- One-time grants during application onboarding or delegation may be legitimate. Validate against change management
 63before escalating.
 64
 65### Response and remediation
 66
 67- If the grant is unauthorized, remove the impersonation binding from the service account's IAM policy.
 68- Revoke any access or identity tokens issued for the impacted service account and review its recent activity for abuse.
 69- Investigate the granting principal for compromise, rotate its credentials if necessary, and review what other IAM
 70changes it has made.
 71- Restrict who can set IAM policy on service accounts and require justification or approval for impersonation grants."""
 72references = [
 73    "https://securitylabs.datadoghq.com/cloud-security-atlas/attacks/backdooring-service-account/",
 74    "https://stratus-red-team.cloud/attack-techniques/GCP/gcp.persistence.backdoor-service-account-policy/",
 75    "https://cloud.google.com/iam/docs/service-account-impersonation",
 76    "https://cloud.google.com/iam/docs/audit-logging/examples-service-accounts",
 77]
 78risk_score = 47
 79rule_id = "197d2757-eea1-46f9-9ebd-84646d2b45fa"
 80severity = "medium"
 81tags = [
 82    "Domain: Cloud",
 83    "Data Source: GCP",
 84    "Data Source: GCP Audit Logs",
 85    "Data Source: Google Cloud Platform",
 86    "Use Case: Identity and Access Audit",
 87    "Use Case: Threat Detection",
 88    "Tactic: Persistence",
 89    "Tactic: Privilege Escalation",
 90    "Resources: Investigation Guide",
 91]
 92timestamp_override = "event.ingested"
 93type = "new_terms"
 94
 95query = '''
 96data_stream.dataset: "gcp.audit"
 97  and event.action: google.iam.admin.v*.SetIAMPolicy
 98  and event.outcome: "success"
 99  and gcp.audit.service_data.policy_delta.binding_deltas:{
100    action: "ADD" and
101    role: (
102      "roles/iam.serviceAccountTokenCreator" or
103      "roles/iam.serviceAccountUser" or
104      "roles/iam.serviceAccountOpenIdTokenCreator"
105    )
106  }
107'''
108
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112
113[[rule.threat.technique]]
114id = "T1098"
115name = "Account Manipulation"
116reference = "https://attack.mitre.org/techniques/T1098/"
117
118[[rule.threat.technique.subtechnique]]
119id = "T1098.003"
120name = "Additional Cloud Roles"
121reference = "https://attack.mitre.org/techniques/T1098/003/"
122
123[rule.threat.tactic]
124id = "TA0003"
125name = "Persistence"
126reference = "https://attack.mitre.org/tactics/TA0003/"
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[[rule.threat.technique]]
132id = "T1098"
133name = "Account Manipulation"
134reference = "https://attack.mitre.org/techniques/T1098/"
135
136[[rule.threat.technique.subtechnique]]
137id = "T1098.003"
138name = "Additional Cloud Roles"
139reference = "https://attack.mitre.org/techniques/T1098/003/"
140
141[rule.threat.tactic]
142id = "TA0004"
143name = "Privilege Escalation"
144reference = "https://attack.mitre.org/tactics/TA0004/"
145
146[rule.new_terms]
147field = "new_terms_fields"
148value = ["user.id"]
149[[rule.new_terms.history_window_start]]
150field = "history_window_start"
151value = "now-10d"

Triage and analysis

Investigating GCP IAM Service Account Impersonation Role Granted

Granting an impersonation role on a service account lets the bound member obtain that service account's credentials without creating a long-lived key. roles/iam.serviceAccountTokenCreator and roles/iam.serviceAccountOpenIdTokenCreator allow minting OAuth2 access tokens and OpenID Connect identity tokens, while roles/iam.serviceAccountUser allows the member to attach (actAs) the service account to new resources. Adversaries abuse these grants to pivot to a higher-privileged identity, escalate privileges, and persist in a way that is unaffected by key rotation or password resets.

Possible investigation steps

  • Identify the granting principal via user.email and user.id and confirm whether that identity is expected to modify IAM policy on service accounts.
  • Review the target service account in gcp.audit.resource_name and determine the permissions it holds. Impersonating a service account with broad project or organization roles represents a significant escalation.
  • Inspect the granted binding in gcp.audit.request / gcp.audit.response to identify the member that was added (user:, serviceAccount:, group:, or an external domain). External or newly created members are higher risk.
  • Examine gcp.audit.request_metadata.caller_ip and gcp.audit.request_metadata.caller_supplied_user_agent to assess whether the change originated from an expected location or tool.
  • Correlate with recent activity by the granting principal, such as service account key creation, custom role creation, or GenerateAccessToken / GenerateIdToken calls that use the newly granted impersonation rights.

False positive analysis

  • Terraform, Deployment Manager, and CI/CD service accounts commonly grant serviceAccountUser and serviceAccountTokenCreator as part of normal provisioning. Baseline these principals and exclude them with exceptions.
  • One-time grants during application onboarding or delegation may be legitimate. Validate against change management before escalating.

Response and remediation

  • If the grant is unauthorized, remove the impersonation binding from the service account's IAM policy.
  • Revoke any access or identity tokens issued for the impacted service account and review its recent activity for abuse.
  • Investigate the granting principal for compromise, rotate its credentials if necessary, and review what other IAM changes it has made.
  • Restrict who can set IAM policy on service accounts and require justification or approval for impersonation grants.

References

Related rules

to-top