Threat Hunting in the Cloud, Part 4: Google Cloud

Google Cloud threat hunting has a distinct center of gravity: service accounts, projects, data services, managed runtime, and security findings. Google Cloud environments often run through automated identities rather than human users. That makes service account impersonation, token generation, cross-project access, workload identity, and IAM policy changes especially important.

Google Security Command Center provides threat findings, investigation guidance, threat dashboards, vulnerability and misconfiguration assessment, and identity and access findings. Google documentation highlights that Security Command Center findings can include MITRE ATT&CK framework entries for attacks against cloud resources. Google Security Operations adds SIEM search, investigative views, YARA-L 2.0, curated detections, threat intelligence, and entity context. Together, they create a strong native foundation for cloud hunting.

The defender's job is to turn that native foundation into a repeatable hunt program. The Cloud ATT&CK matrix gives the behavior map. Threat Foundry gives analysts a workflow for building hunts, preserving query adaptations, converting reviewed logic into detection content, and carrying evidence into cases.

The Google Cloud Hunt Surface

1. IAM and Service Accounts

In Google Cloud, service accounts are often the most important identities in the environment. They run workloads, automation, data pipelines, CI/CD jobs, serverless services, and cross-project operations. Attackers who can impersonate or mint tokens for service accounts can often move faster than they could with a human user.

High-value hunts include:

• iam.serviceAccounts.getAccessToken, signJwt, signBlob, or OpenID token generation by unusual principals.
• Service Account Token Creator granted at organization, folder, or project scope.
• New service account keys created for sensitive accounts.
• Service accounts granted Owner, Editor, or broad custom roles.
• Cross-project service account impersonation.
• Dormant service accounts becoming active.
• Denied permission spikes followed by successful role changes.
• Workload identity changes that bind Kubernetes service accounts to powerful Google service accounts.

ATT&CK mapping: Valid Accounts, Cloud Accounts, Application Access Token, Steal Application Access Token, Cloud Infrastructure Discovery, Permission Groups Discovery, and Use Alternate Authentication Material.

Threat Foundry tie-in: Hunt Builder can anchor service account abuse to Cloud ATT&CK techniques, while Field Normalization can map Google Cloud audit fields into common identity and resource entities. That makes service account hunts reusable across Chronicle, BigQuery exports, Splunk, or another SIEM.

2. Projects, Folders, Organizations, and Control Plane

Google Cloud resource hierarchy matters. Organization, folder, project, and resource-level permissions create many paths for privilege inheritance and lateral movement. Control-plane hunts should watch both direct resource changes and policy changes that create future access.

High-value hunts include:

• IAM policy changes at organization, folder, or project scope.
• Custom roles created or updated with sensitive permissions.
• Logging sinks changed, excluded, or redirected.
• Audit log settings modified.
• VPC firewall rules opened broadly or modified for management access.
• New projects created by unusual identities.
• Organization policies weakened.
• Secrets accessed after role grants.

ATT&CK mapping: Cloud Infrastructure Discovery, Cloud Service Discovery, Cloud Service Dashboard, Permission Groups Discovery, Impair Defenses, and Unsecured Credentials.

Threat Foundry tie-in: Attack Path Builder can model the hierarchy-aware sequence: Cloud Account, Permission Groups Discovery, Cloud Infrastructure Discovery, service account token generation, and data access. That path gives analysts a reusable structure for multi-project investigations.

3. Security Command Center as a Hunt Queue

Security Command Center is not only a posture dashboard. It can provide threat findings across services, threat investigation guidance, dashboards for potentially harmful events, identity and access findings, misconfiguration detection, vulnerability findings, and cloud-specific threat categories. Its detection services include findings for AI services, BigQuery exfiltration, Cloud Run threats, Compute Engine rootkits or crypto mining, GKE secret access, Kubernetes attack tools, reverse shells, default compute service account privilege issues, Cloud SQL exfiltration, backup deletion, and more.

High-value hunts include:

• Security Command Center threat finding followed by related IAM or audit-log activity.
• Multiple low-severity findings against the same project, service account, or workload.
• Findings that indicate credential access, discovery, or exfiltration in sequence.
• Backup and DR deletion or reduced backup frequency.
• BigQuery exfiltration findings correlated with IAM changes.
• GKE secret access or cluster-admin grants correlated with pod execution.

ATT&CK mapping: Discovery, Credential Access, Collection, Exfiltration, Defense Evasion, Privilege Escalation, and Impact.

Threat Foundry tie-in: CTI intake and Auto Triage help prioritize external reporting about Google Cloud threats, while Case Workspace can collect Security Command Center findings, audit events, asset context, and ATT&CK mapping into one investigation record.

4. Google Security Operations and YARA-L Hunting

Google Security Operations supports searching events and alerts, investigating entity context, creating multi-stage YARA-L 2.0 queries, using joins, aggregations, metrics, reference lists, investigative views, curated detections, Mandiant hunting rules, Applied Threat Intelligence, and raw log search. This matters because Google Cloud hunts often need multi-stage logic.

High-value Google SecOps hunt themes include:

• Service account token generation followed by BigQuery table export.
• IAM role grant followed by Cloud Storage object listing.
• GKE secret read followed by external network connection.
• Cloud Run service update followed by suspicious outbound traffic.
• Compute Engine startup script added followed by crypto mining indicators.
• New firewall ingress rule followed by SSH brute force or remote access.

Threat Foundry tie-in: Threat Foundry can generate the behavior package and preserve YARA-L or other local query language adaptations through Query Overrides. That creates a bridge between ATT&CK-centered reasoning and Google SecOps execution.

5. BigQuery, Cloud Storage, and Data Movement

Google Cloud data services are high-value targets. BigQuery datasets, Cloud Storage buckets, Cloud SQL, AlloyDB, Spanner, Looker, and exported analytics data can become exfiltration paths. Many data-theft scenarios do not look like malware; they look like queries, exports, bucket copies, external table creation, or sharing changes.

High-value hunts include:

• BigQuery jobs exporting sensitive datasets to external buckets.
• External tables created for sensitive data.
• Dataset or table IAM changes followed by large queries.
• Cloud Storage IAM changes followed by object listing or copying.
• Buckets made public or exposed to external identities.
• Cloud SQL backup/export activity to external locations.
• Service account access to data outside its normal project or workload.

ATT&CK mapping: Data from Cloud Storage, Data from Information Repositories, Transfer Data to Cloud Account, Cloud Storage Object Discovery, and Exfiltration Over Web Service.

Threat Foundry tie-in: Asset Classification can label high-value datasets, applications, and vendors. Priority Vendors/Products can raise the triage priority of CTI affecting critical cloud-hosted software or managed services. Saved hunts can preserve the exact data-access hypothesis for future audits.

6. GKE, Cloud Run, Compute Engine, and Runtime

Google Cloud runtime hunts should combine control-plane changes with workload behavior. GKE, Cloud Run, Compute Engine, and AI workloads can expose secrets, metadata, service account tokens, or privileged runtime capabilities.

High-value hunts include:

• GKE pods launched with excessive privileges or host access.
• Kubernetes secrets accessed by unusual service accounts.
• Certificate signing requests approved unexpectedly.
• Cloud Run services updated to new images or suspicious environment variables.
• Compute Engine startup scripts or SSH keys added.
• Metadata service access followed by API activity.
• Crypto mining, reverse shells, netcat, curl-to-shell, or encoded command execution.

ATT&CK mapping: Cloud Instance Metadata API, Exploitation for Credential Access, Remote Services, Resource Hijacking, Defense Evasion, and Execution.

Threat Foundry tie-in: Sigma Builder is useful for runtime and audit-log behavior. YARA Builder becomes useful when reporting contains file hashes, script strings, malicious libraries, container payload markers, or malware traits. The split keeps cloud behavior and file-content detection in the right lanes.

7. Impact and Recovery

Google Cloud impact hunts should focus on backup deletion, lifecycle policy changes, access removal, encryption misuse, resource exhaustion, and security monitoring tampering.

High-value hunts include:

• Backup and DR resources deleted or backup expiration reduced.
• Logging sinks removed, exclusions added, or audit logs changed.
• KMS keys disabled or scheduled for destruction.
• Cloud Storage lifecycle rules modified for deletion.
• Bulk object deletes or dataset deletes.
• Quota spikes, GPU creation, or many instances created.
• Administrator or responder access removed.

ATT&CK mapping: Inhibit System Recovery, Lifecycle-Triggered Deletion, Data Destruction, Data Encrypted for Impact, Account Access Removal, and Resource Hijacking.

Threat Foundry tie-in: Case Workspace is where the cloud-native impact story becomes clear. Analysts can preserve who changed what, which service account or user performed the action, what data or workload was affected, and which ATT&CK techniques explain the sequence.

A Practical Google Cloud Hunt Loop

1. Select a Cloud ATT&CK behavior such as Application Access Token, Cloud Storage Object Discovery, Data from Cloud Storage, or Resource Hijacking.
2. Confirm telemetry: Cloud Audit Logs, Security Command Center findings, Google SecOps normalized events, Cloud DNS or network logs, GKE audit logs, and workload telemetry.
3. Generate a Threat Foundry hunt using the Cloud matrix.
4. Adapt the query to Google SecOps YARA-L, BigQuery SQL, or the customer's SIEM through Query Overrides.
5. Run the hunt and save useful evidence.
6. Convert stable logic to reviewed Sigma or platform-native detections.
7. Send suspicious results into Case Workspace and track follow-up.

Google Cloud hunting works best when teams focus on service account behavior, resource hierarchy, data access, and managed runtime. Security Command Center and Google Security Operations provide strong native context. Threat Foundry helps turn that context into repeatable ATT&CK-aligned hunts and operational evidence.

Sources

• Google Cloud Documentation, Detection services in Security Command Center.
• Google Cloud Documentation, Investigating and responding to threats in Security Command Center.
• Google Cloud Documentation, Google Security Operations SIEM overview.
• Google Cloud Documentation, Default detection rules in Google Security Operations.
• MITRE ATT&CK, Enterprise Cloud Matrix.