Last reviewed:
How to detect Google Cloud service-account key creation, impersonation, broad IAM grants and suspicious service-account creation without treating every administrative change as an incident.
A Google Cloud service account is a workload identity. It can call Google Cloud APIs, hold IAM roles and appear as both a principal and a resource. That dual nature is why service-account abuse can be messy in a SOC queue. The same object can be the thing that changed, the identity that later accessed data and the resource that someone else gained permission to use.
Attackers do not need a novel exploit if they can create a service account, add a key to an existing account or grant themselves the right to impersonate a privileged account. Those actions fit T1078.004 Valid Accounts, T1098 Account Manipulation and T1136.003 Create Account: Cloud Account when the tenant context shows unexpected access or persistence. The audit record proves the change. Asset ownership, normal automation and role scope decide whether it deserves an alert.
Separate the abuse paths before writing rules. Key creation gives an external credential. Impersonation gives short-lived credentials through the Service Account Credentials API or through a role that lets a user attach the service account to a resource. Broad IAM grants change what the account can reach. New service accounts add persistence only when the account receives useful permissions or a route to later credential creation.
Service account keys are public and private key pairs used to authenticate as a service account, often from outside Google Cloud. Google warns that keys are a security risk when they are not managed correctly and recommends avoiding them where a safer option exists. By default, a service-account key does not expire, although organisation policy can change that behaviour.
The detection starting point is the Admin Activity event for 'google.iam.admin.v1.CreateServiceAccountKey'. Review the creator, target service account, project, caller IP, user agent where present and whether the key count changed for an account that should not have user-managed keys. A key created by a release pipeline for a known legacy integration is different from a key created by a human user against a production service account after hours.
Do not call later API use impersonation when the actor used a key. Google distinguishes key-based authentication from service account impersonation because only one identity is involved. That difference matters in the case note: key creation is the durable credential event, while later resource access may show only the service account unless the surrounding logs preserve the original creator path.
Service account impersonation means an authenticated principal gets credentials for a target service account and then acts with that service account's permissions. Google documents short-lived credentials as lower risk than long-lived keys, but the lower credential risk does not make every impersonation safe. A user who can mint access tokens for a highly privileged service account can cross a project boundary very quickly.
Start with IAM Credentials API methods such as 'google.iam.credentials.v1.GenerateAccessToken', 'google.iam.credentials.v1.GenerateIdToken', 'google.iam.credentials.v1.SignBlob' and 'google.iam.credentials.v1.SignJwt'. Then check whether the principal had 'roles/iam.serviceAccountTokenCreator', 'roles/iam.serviceAccountUser' or a workload identity role on the target account. The Service Account User role is not the same as Token Creator, so the rule note should name which route the event suggests.
Cloud Audit Logs can include both the authenticated principal and the impersonated service account. Preserve that delegation chain where the export path carries it. If the SIEM parser drops serviceAccountDelegationInfo or the target resource name, the alert may still fire, but the reviewer will have to reconstruct the chain manually from IAM policy history and later resource access.
Service-account abuse often becomes dangerous when the account receives a broad role. Google Cloud roles are collections of permissions granted to principals, including users, groups and service accounts. Basic roles such as Owner and Editor are especially noisy because they cover broad resource access. Custom roles can be just as sensitive when they include IAM, key-management or data-plane permissions.
For project, folder and organisation-level grants, Cloud Resource Manager records the change with protoPayload.serviceName set to 'cloudresourcemanager.googleapis.com' and protoPayload.methodName set to 'SetIamPolicy'. For IAM changes on the service-account resource itself, IAM audit logs use the IAM Admin method shape, such as 'google.iam.admin.v1.SetIAMPolicy'. Keep those lanes separate so a resource-manager grant does not get mistaken for a service-account policy grant.
Treat the first filter as a candidate selector. Confirm the added binding from fields your export path preserves, from metadata or policy-delta fields where available, or by comparing the response policy with the previous policy. Do not rely on protoPayload.serviceData.policyDelta alone until you have proved that your sink and SIEM parser keep it, because the sibling GCP audit-log guide documents that serviceData is deprecated and can be stripped during export.
protoPayload.serviceName="cloudresourcemanager.googleapis.com"
protoPayload.methodName="SetIamPolicy"
resource.type in ["project", "folder", "organization"]
changed_binding.member endswith "@PROJECT_ID.iam.gserviceaccount.com"
changed_binding.role in ["roles/owner", "roles/editor", "roles/iam.securityAdmin"]
changed_binding.action="ADD"
# Derive changed_binding from preserved metadata/policyDelta fields,
# or by comparing the response policy with the prior policy.
# Do not assume deprecated serviceData survives SIEM export.New service-account creation is not automatically malicious. Google Cloud projects create default service accounts when some services are enabled, and platform service agents exist so Google Cloud services can operate. The useful detection is narrower: a user-managed service account created in a sensitive project, followed by a key, a Token Creator grant or a broad role assignment.
Use 'google.iam.admin.v1.CreateServiceAccount' as the service-account creation event. The example logs published by Google show the creator in authenticationInfo.principalEmail and the created account in response.email. Keep both fields in the case, because the account email is what later resource-access logs will show when the account is used.
For ATT&CK, keep the mapping honest. Creation alone can support T1136.003 as a persistence review signal. It becomes stronger when the account receives additional credentials or roles, which pulls the case towards T1098 and T1078.004. A service account created by Terraform during an approved platform build should close as expected change, not as a weak cloud-account alert left to irritate the SOC.
A service-account alert is only useful if the reviewer can see which identity acted, which service account changed and which project, folder or organisation inherited the risk. Keep protoPayload.serviceName, protoPayload.methodName, protoPayload.authenticationInfo.principalEmail, protoPayload.requestMetadata.callerIp, resourceName, resource.type, timestamp, insertId, response.email and the relevant policy-change fields visible in the SIEM case.
Record known deployment pipelines, break-glass users, service agents, workload identity pools and legacy key exceptions before suppressing administrative events. A key created by a build system may be expected. The same event by a human user in a sensitive project deserves review, especially when the service account later reads data or receives a broader role.
The coverage report should say what the detection proves. Key creation proves a credential was created. Token generation proves short-lived credential use. SetIamPolicy proves a policy changed, but the risky binding still needs to be extracted or compared. DCV can record those distinctions beside the ATT&CK mapping so reviewers do not overclaim coverage from a single audit method name.