Lateral Movement via External GCP Service Accounts

Introduction

In Google Cloud Platform (GCP), Service Accounts (SAs) are designed as non-human identities for workloads like Compute Engine, Cloud Functions, and GKE. They hold credentials and roles that often allow automation at scale. But when Service Accounts from outside an organization are granted permissions inside projects, they become a hidden backdoor for attackers.

This article explores how adversaries can exploit external Service Accounts for lateral movement into victim environments, why this is uniquely dangerous, and how defenders can detect and block it using MITRE ATT&CK mapping and Organization Policies.

The Risk of External Service Accounts

Unlike human accounts, Service Accounts do not require MFA, login monitoring, or password rotation. If an organization misconfigures IAM and allows a foreign SA to be bound to its resources:

• Attackers can use their own SA (from a project they control) to authenticate into the victim’s projects.
• These bindings may persist unnoticed for months, especially if granted at the project or organization level.
• External SAs can then impersonate other SAs inside the victim’s environment if granted roles/iam.serviceAccountTokenCreator.

This is effectively trusting another tenant’s user. Once granted, it is as if the attacker has a permanent bridge into your cloud.

Attack Scenario: External SA Backdoor

Step 1: Misconfiguration by a Victim Project Owner

A project owner in Org A mistakenly grants broad access to an external SA from Org B:

{

"role": "roles/storage.admin",

"members": [

"serviceAccount:[email protected]"

]

}

Step 2: Attacker Uses Their Own Service Account

The attacker activates their SA in their environment:

gcloud auth activate-service-account [email protected] \

--key-file=attacker-sa-key.json

Step 3: Access Victim Resources

Now the attacker can directly list buckets inside Org A:

gcloud storage buckets list --project=victim-project

Or with Python:

from google.cloud import storage

from google.oauth2 import service_account

creds = service_account.Credentials.from_service_account_file("attacker-sa-key.json")

client = storage.Client(credentials=creds, project="victim-project")

for bucket in client.list_buckets():

print(bucket.name)

Step 4: Lateral Movement via Impersonation

If the external SA also has roles/iam.serviceAccountTokenCreator on an internal SA, the attacker can impersonate it:

gcloud auth print-access-token \

--impersonate-service-account=internal-sa@victim-project.iam.gserviceaccount.com

From here, the attacker can move laterally to other projects or escalate privileges inside Org A.

Detection Strategies (MITRE ATT&CK Mapping)

1. Detect Cross-Domain IAM Bindings
   • Regularly scan IAM policies for serviceAccount:*@external-domain.com.
   • MITRE Technique: [T1098 – Account Manipulation].
2. Monitor GenerateAccessToken Calls
   • Audit logs from iamcredentials.googleapis.com reveal impersonation events.
   • MITRE Technique: [T1134 – Access Token Manipulation].
3. Watch for Abnormal SA Behavior
   • Flag when an SA from outside the organization starts accessing storage, BigQuery, or Pub/Sub.
   • MITRE Technique: [T1078 – Valid Accounts].
4. Key Creation Monitoring
   • Alert on google.iam.admin.v1.CreateServiceAccountKey for unexpected SAs.
   • MITRE Technique: [T1552 – Unsecured Credentials].

Mitigation Strategies

1. Restrict Cross-Domain Members

The most important safeguard is the Organization Policy iam.allowedPolicyMemberDomains. This enforces which identity domains can be granted IAM roles.

Example policy YAML:

constraint: iam.allowedPolicyMemberDomains

listPolicy:

allowedValues:

- "gcp.myorg.com"

Command to apply:

gcloud org-policies set-policy policy.yaml --organization=ORG_ID

This ensures that only SAs from your own domain (e.g., *.gserviceaccount.com linked to your Workspace/Org) can be bound.

2. Disable Service Account Key Creation

gcloud org-policies enable-enforce iam.disableServiceAccountKeyCreation \

--organization=ORG_ID

Prevents attackers from exporting long-lived SA keys.

3. Principle of Least Privilege

• Avoid assigning Editor or Owner to SAs.
• Never grant roles/iam.serviceAccountTokenCreator to external accounts.

4. Continuous Monitoring

• Set alerts on abnormal impersonation events.

Cyngular Security's CIRA Platform

To further secure your cloud environment, consider integrating Cyngular Security's CIRA platform. It enhances your security posture by providing advanced investigation and response capabilities, enabling your team to address threats swiftly and effectively. By adopting Cyngular Security's CIRA, you empower your organization with proactive and automated security measures that protect your cloud assets.

Get a Free Breach Assessment

Protect your cybersecurity infrastructure with a complimentary breach assessment from Cyngular:

• Safe and Non-disruptive: Conducted with read-only access to ensure no operational disruption.
• Easy Setup: Integrates seamlessly with your existing SIEM systems.
• Deep Insights: Empowers your cybersecurity strategy with advanced threat hunting and proactive investigation capabilities.

Request your free Proof-of-Value today and lead the way in cybersecurity innovation with Cyngular.