Last reviewed:
How to detect Google Cloud service account impersonation, unauthorised key creation, high-risk IAM role assignments and suspicious service account creation using Cloud Audit Logs and asset metadata.
Service accounts are the primary targets for persistence in Google Cloud. An attacker who gains a service account key or the permission to impersonate a service account can act with the identity of that account. This can bypass traditional identity controls and provide long-lived access to a project or folder.
Common abuse patterns include creating new service accounts, creating new keys for existing accounts, granting highly privileged roles to a compromised account and using service account impersonation to move laterally. Detection requires monitoring both the creation of credentials and the identity-assignment changes that enable them.
Google Cloud allows users to create external keys for service accounts. These keys are long-lived, can be used from outside Google Cloud and usually never expire unless an organisation policy sets an expiry. SOC teams should monitor for the creation of new keys, particularly for accounts that do not usually require them or when created by an unusual identity.
Key use is different from impersonation. A service account key can authenticate as the service account without leaving a human delegation chain in the later resource-access logs, so the creation event, key name, creator identity and target service account matter during review.
Monitor for the 'google.iam.admin.v1.CreateServiceAccountKey' method in Admin Activity logs. An alert should fire when a key is created for a privileged service account or by an identity that is not part of a known deployment pipeline. Reviewing the 'callerIp' and 'principalEmail' helps separate legitimate automation from suspicious manual key creation.
Impersonation allows one identity to act as another, such as a user assuming the role of a service account. This is a powerful feature for administrators but is also a vector for lateral movement. The 'google.iam.credentials.v1.GenerateAccessToken' and 'google.iam.credentials.v1.SignBlob' methods record impersonation events.
Detection depends on observing the delegation chain. In Cloud Audit Logs, the 'authenticationInfo.principalEmail' field shows the caller, while service-account resource names, serviceAccountDelegationInfo where present and the IAM Credentials API method identify the service account being used. Look for impersonation involving accounts with sensitive permissions or those that bridge access across project boundaries.
Attackers often manipulate IAM policies to grant themselves further access. Monitoring for changes to project, folder and organisation-level IAM bindings is essential. For those resource-level grants, Cloud Resource Manager records the event with protoPayload.serviceName set to 'cloudresourcemanager.googleapis.com' and protoPayload.methodName set to 'SetIamPolicy'.
Treat the first filter as a candidate selector, then confirm the added binding from the policy-delta fields your export path preserves or by comparing the response policy with the prior 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.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.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, resourceName, resource.type, timestamp, insertId and the relevant policyDelta or response fields visible in the SIEM case.
Record known deployment pipelines, break-glass users and service agents before suppressing noisy administrative events. A key creation by a build system may be expected; the same event by a human user in a sensitive project deserves review.