CrowdStrike has announced a significant expansion of its Falcon Adversary OverWatch managed threat hunting service, extending 24/7 human-led adversary hunting capabilities across AI systems and Google Cloud environments. This is not a routine product update — it is a direct response to a measurable shift in adversary behavior: threat actors are now deliberately targeting AI infrastructure, cloud-native workloads, and the control planes that orchestrate them.
For SOC teams, CISOs, and defenders operating in Google Cloud or deploying AI/ML pipelines, this announcement carries a clear signal: the threat surface you are responsible for has outpaced the tooling most organizations currently have in place. Adversaries are not waiting for your security stack to catch up. This post breaks down what the expansion covers, why AI and Google Cloud are now priority targets, and what your team should be doing right now to close visibility gaps before they are exploited.
Technical Analysis: What CrowdStrike Is Expanding and Why It Matters
What Is Falcon Adversary OverWatch?
Falcon Adversary OverWatch is CrowdStrike's managed threat hunting service — a team of elite human threat hunters operating around the clock, proactively searching for adversary activity that automated detections miss. Unlike signature or rule-based alerting, OverWatch hunters are trained to identify hands-on-keyboard intrusions, living-off-the-land techniques, and novel attack chains that have not yet been codified into detections.
The expansion announced extends this human-led hunting capability into two domains that have historically been underserved by managed detection and response (MDR) services:
1. AI Systems and Workloads
Organizations are deploying large language models (LLMs), machine learning pipelines, and AI agents at unprecedented speed — often with minimal security oversight. Threat actors have taken notice. The specific attack vectors against AI infrastructure include:
- Model theft and intellectual property exfiltration: Adversaries targeting model weights, training datasets, and fine-tuned model artifacts stored in cloud object storage.
- Prompt injection and model manipulation: Adversaries crafting inputs designed to extract sensitive data from LLM-powered applications or manipulate model outputs.
- AI supply chain compromise: Malicious packages or backdoored model artifacts introduced into ML pipelines via public repositories (e.g., poisoned Hugging Face models, compromised PyPI/NPM packages used in ML workflows).
- Credential theft targeting AI service accounts: Service accounts with access to AI training infrastructure often carry broad permissions and are frequently over-privileged, making them high-value targets for lateral movement.
CrowdStrike's expanded OverWatch hunting specifically monitors for adversary behavior across these AI attack surfaces — including anomalous access to model repositories, unusual API call patterns against AI endpoints, and indicators of prompt injection campaigns.
2. Google Cloud Platform (GCP)
Google Cloud has grown into a critical enterprise platform, yet many organizations have significantly less mature detection coverage in GCP compared to their AWS or Azure footprints. CrowdStrike's expansion brings OverWatch hunting to GCP environments, covering:
- GCP control plane activity: Monitoring IAM policy changes, service account key creation, and privilege escalation attempts via Google Cloud Audit Logs.
- GCP workload protection: Extending Falcon sensor telemetry to Google Compute Engine (GCE) instances and Google Kubernetes Engine (GKE) clusters, enabling process-level and network-level hunting on GCP-hosted workloads.
- Cross-cloud correlation: Correlating adversary activity across GCP, AWS, Azure, and on-premises environments to identify multi-cloud intrusion campaigns — a pattern increasingly observed in nation-state and eCrime operations.
The Threat Context: Why Now
This expansion is driven by observable adversary tradecraft trends, not vendor marketing cycles. Key drivers include:
- Cloud-conscious adversaries are standard, not exceptional. Groups tracked by CrowdStrike as SCATTERED SPIDER, COZY BEAR, and multiple China-nexus actors have demonstrated consistent capability to operate within cloud control planes, abuse federated identity, and persist in cloud environments without deploying traditional malware.
- AI infrastructure is a greenfield target. Most organizations deployed AI workloads faster than they deployed security controls for them. Service accounts, API keys, and model endpoints are frequently exposed with excessive permissions and minimal monitoring.
- GCP detection gaps are a known blind spot. SOC teams often have mature Windows and AWS telemetry pipelines but lack equivalent visibility into GCP audit logs, GKE cluster activity, and GCP workload process execution.
Exploitation Status
This news item does not describe a specific CVE or a single in-the-wild exploit. It describes a capability expansion in response to active, ongoing adversary campaigns targeting AI systems and cloud environments. The threats motivating this expansion — cloud control plane abuse, AI supply chain compromise, and cross-cloud lateral movement — are confirmed as actively exploited techniques observed across multiple intrusion campaigns in 2025 and continuing into 2026.
Detection & Response
This is a technical threat post focused on the adversary behaviors driving the OverWatch expansion. The detection content below targets the specific techniques defenders should be hunting for in AI and GCP environments — regardless of whether you use CrowdStrike.
Sigma Rules
---
title: GCP Service Account Key Creation by Non-Administrative Identity
id: 3f8a1c72-7d4e-4b9a-a2c1-5e6f7a8b9c0d
status: experimental
description: Detects creation of GCP service account keys by identities that do not normally perform IAM administration. Adversaries create service account keys to establish persistence in GCP environments after initial access.
references:
- https://attack.mitre.org/techniques/T1098/001/
- https://cloud.google.com/iam/docs/audit-logging
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1098.001
- attack.privilege_escalation
logsource:
product: gcp
service: audit
detection:
selection:
protoPayload.methodName: 'google.iam.admin.v1.CreateServiceAccountKey'
filter_known_admins:
protoPayload.authenticationInfo.principalEmail|endswith:
- '@your-admin-group.iam.gserviceaccount.com'
condition: selection and not filter_known_admins
falsepositives:
- CI/CD pipelines programmatically rotating service account keys
- Terraform or infrastructure-as-code deployments creating keys
level: high
---
title: Suspicious Access to AI Model Artifacts in Cloud Storage
id: 7b2e9f41-3a5c-4d8e-b1f2-6a7c8d9e0f1a
status: experimental
description: Detects anomalous read or export operations against cloud storage buckets containing AI model weights, training data, or fine-tuned model artifacts. Adversaries targeting AI intellectual property will attempt bulk downloads or cross-project copies of model artifacts.
references:
- https://attack.mitre.org/techniques/T1530/
- https://attack.mitre.org/techniques/T1567/002/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.t1530
- attack.exfiltration
- attack.t1567.002
logsource:
product: gcp
service: audit
detection:
selection:
protoPayload.methodName|contains:
- 'storage.objects.get'
- 'storage.objects.list'
protoPayload.resourceName|contains:
- 'model'
- 'checkpoint'
- 'weights'
- 'training'
- 'ml-artifacts'
- 'huggingface'
- '.bin'
- '.safetensors'
- '.ckpt'
condition: selection
falsepositives:
- Data scientists and ML engineers accessing model artifacts as part of normal workflows
- Automated model deployment pipelines pulling artifacts
level: medium
---
title: Anomalous Process Execution in GKE or GCP Workload
id: 9c1d3e52-8f6a-4b7c-a3d4-2e5f6a7b8c9d
status: experimental
description: Detects execution of reconnaissance or post-exploitation tooling within GCP workloads including GKE containers and GCE instances. Adversaries operating in cloud workloads frequently use living-off-the-land techniques and cloud-native CLI tools for discovery and lateral movement.
references:
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1613/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1059
- attack.discovery
- attack.t1613
logsource:
category: process_creation
product: linux
detection:
selection_img:
Image|endswith:
- '/kubectl'
- '/gcloud'
- '/gsutil'
- '/curl'
- '/wget'
selection_cmd:
CommandLine|contains:
- 'kubectl exec'
- 'kubectl get secrets'
- 'gcloud iam service-accounts'
- 'gcloud secrets versions access'
- 'metadata.google.internal'
- '169.254.169.254'
condition: selection_img and selection_cmd
falsepositives:
- DevOps engineers performing cluster administration
- Automated CI/CD pipelines interacting with GCP APIs
level: high
KQL (Microsoft Sentinel / Defender)
The following query hunts for GCP audit log events indicative of adversary activity in the control plane — specifically service account manipulation, IAM privilege escalation, and anomalous access to AI/ML storage resources. This assumes GCP audit logs are ingested into Sentinel via the Google Cloud Platform connector or via CEF/Syslog forwarding.
// Hunt: GCP Service Account Key Creation + IAM Policy Changes + AI Artifact Access
// Correlates high-risk GCP control plane events over a 7-day window
let TimeWindow = 7d;
let HighRiskMethods = dynamic([
"google.iam.admin.v1.CreateServiceAccountKey",
"google.iam.admin.v1.UpdateServiceAccount",
"SetIamPolicy",
"google.iam.admin.v1.CreateServiceAccount"
]);
let AIStorageIndicators = dynamic([
"model", "checkpoint", "weights", "training",
"ml-artifacts", ".safetensors", ".ckpt", ".bin"
]);
// Part 1: IAM manipulation events
let IAMEvents = CommonSecurityLog
| where TimeGenerated > ago(TimeWindow)
| where DeviceVendor == "Google" or SourceSystem == "GCP"
| where Activity has_any (HighRiskMethods)
| project TimeGenerated, SourceUserID, Activity, SourceIP, DestinationHostName, AdditionalExtensions;
// Part 2: AI/ML storage access events
let AIArtifactAccess = CommonSecurityLog
| where TimeGenerated > ago(TimeWindow)
| where DeviceVendor == "Google" or SourceSystem == "GCP"
| where Activity has "storage.objects"
| where FilePath has_any (AIStorageIndicators) or RequestURL has_any (AIStorageIndicators)
| project TimeGenerated, SourceUserID, Activity, SourceIP, FilePath, RequestURL;
// Part 3: Combine and summarize by identity
union IAMEvents, AIArtifactAccess
| summarize
EventCount = count(),
DistinctActivities = make_set(Activity),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
SourceIPs = make_set(SourceIP)
by SourceUserID
| where EventCount > 3 // Tune threshold for your environment
| sort by EventCount desc
// Hunt: Suspicious process execution on GCP workloads (via Syslog or EDR telemetry)
// Targets cloud-native recon and post-exploitation tooling
DeviceProcessEvents
| where TimeGenerated > ago(48h)
| where FileName in~ ("kubectl", "gcloud", "gsutil")
| where ProcessCommandLine has_any (
"kubectl exec",
"kubectl get secrets",
"gcloud iam service-accounts keys create",
"gcloud secrets versions access",
"metadata.google.internal"
)
| project
TimeGenerated,
DeviceName,
FileName,
ProcessCommandLine,
AccountName,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| sort by TimeGenerated desc
Velociraptor VQL
For organizations running Velociraptor on GCP workloads (GCE instances, GKE nodes), this artifact hunts for evidence of adversary interaction with cloud metadata services and credential access — common post-compromise behaviors in cloud intrusions.
-- Hunt: Cloud metadata service access and credential file discovery on GCP workloads
-- Targets adversary reconnaissance and credential theft in cloud environments
-- Part 1: Processes accessing GCP instance metadata
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'metadata\\.google\\.internal'
OR CommandLine =~ '169\\.254\\.169\\.254'
OR CommandLine =~ 'gcloud.*iam.*service-accounts.*keys'
OR CommandLine =~ 'kubectl.*get.*secrets'
-- Part 2: Discover service account key files and cloud credential caches
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
'/home/*/.config/gcloud/**',
'/root/.config/gcloud/**',
'/home/*/.kube/config',
'/root/.kube/config',
'/tmp/*.json',
'/var/run/secrets/kubernetes.io/**'
])
WHERE Mtime > timestamp(epoch=now() - 604800) -- Modified in last 7 days
ORDER BY Mtime DESC
Remediation Script (Bash — GCP Environment Hardening)
The following script audits and hardens key GCP configurations related to service account security and AI/ML storage access controls. Run this against your GCP projects to identify and remediate the most commonly exploited misconfigurations.
#!/bin/bash
# GCP Service Account and AI Storage Security Audit
# Run with appropriate GCP IAM permissions (SecurityReviewer or higher)
# Usage: ./gcp_security_audit.sh PROJECT_ID
set -euo pipefail
PROJECT_ID="${1:?Usage: $0 <PROJECT_ID>}"
REPORT="gcp_audit_$(date +%Y%m%d_%H%M%S).txt"
echo "=== GCP Security Audit: $PROJECT_ID ===" | tee "$REPORT"
# --- 1. Audit: List all service accounts with user-managed keys ---
echo -e "\n[1] Service Accounts with User-Managed Keys (Persistence Risk)" | tee -a "$REPORT"
gcloud iam service-accounts list --project="$PROJECT_ID" --format="value(email)" | while read -r SA; do
KEYS=$(gcloud iam service-accounts keys list \
--iam-account="$SA" \
--managed-by=user \
--format="value(name)" 2>/dev/null || true)
if [ -n "$KEYS" ]; then
echo " [!] $SA has user-managed keys:" | tee -a "$REPORT"
echo "$KEYS" | tee -a "$REPORT"
fi
done
# --- 2. Audit: Overly permissive IAM bindings ---
echo -e "\n[2] Overly Permissive IAM Bindings (roles/owner, roles/editor)" | tee -a "$REPORT"
gcloud projects get-iam-policy "$PROJECT_ID" \
--flatten="bindings[].members" \
--filter="bindings.role:roles/owner OR bindings.role:roles/editor" \
--format="table(bindings.role, bindings.members)" | tee -a "$REPORT"
# --- 3. Audit: Service accounts with overly broad roles ---
echo -e "\n[3] Service Accounts with Broad Roles (roles/editor or roles/owner)" | tee -a "$REPORT"
gcloud projects get-iam-policy "$PROJECT_ID" \
--flatten="bindings[].members" \
--filter="bindings.members:serviceAccount AND (bindings.role:roles/owner OR bindings.role:roles/editor)" \
--format="table(bindings.role, bindings.members)" | tee -a "$REPORT"
# --- 4. Audit: Publicly accessible GCS buckets (potential AI artifact exposure) ---
echo -e "\n[4] Publicly Accessible Storage Buckets (AI/ML Data Exposure Risk)" | tee -a "$REPORT"
gcloud storage buckets list --project="$PROJECT_ID" --format="value(name)" | while read -r BUCKET; do
IAM=$(gcloud storage buckets get-iam-policy "gs://$BUCKET" 2>/dev/null || true)
if echo "$IAM" | grep -q "allUsers\|allAuthenticatedUsers"; then
echo " [CRITICAL] gs://$BUCKET is publicly accessible" | tee -a "$REPORT"
fi
done
# --- 5. Audit: Check if Uniform Bucket-Level Access is enabled ---
echo -e "\n[5] Buckets Without Uniform Bucket-Level Access (Legacy ACL Risk)" | tee -a "$REPORT"
gcloud storage buckets list --project="$PROJECT_ID" \
--format="value(name,uniform_bucket_level_access_enabled)" | while read -r BUCKET UBLA; do
if [ "$UBLA" != "True" ]; then
echo " [WARNING] gs://$BUCKET does not have uniform bucket-level access enabled" | tee -a "$REPORT"
fi
done
# --- 6. Remediation: Enable Uniform Bucket-Level Access on all buckets ---
echo -e "\n[6] Remediation: Enabling Uniform Bucket-Level Access" | tee -a "$REPORT"
read -p "Apply uniform bucket-level access to all buckets? (yes/no): " CONFIRM
if [ "$CONFIRM" = "yes" ]; then
gcloud storage buckets list --project="$PROJECT_ID" --format="value(name)" | while read -r BUCKET; do
gcloud storage buckets update "gs://$BUCKET" --uniform-bucket-level-access 2>/dev/null && \
echo " [OK] Enabled UBLA on gs://$BUCKET" | tee -a "$REPORT" || \
echo " [FAIL] Could not update gs://$BUCKET" | tee -a "$REPORT"
done
fi
# --- 7. Audit: Check for Workload Identity usage in GKE (recommended over SA keys) ---
echo -e "\n[7] GKE Clusters Without Workload Identity" | tee -a "$REPORT"
gcloud container clusters list --project="$PROJECT_ID" \
--format="value(name,workloadIdentityConfig.workloadPool)" 2>/dev/null | while read -r CLUSTER WI; do
if [ -z "$WI" ]; then
echo " [WARNING] Cluster $CLUSTER does not have Workload Identity enabled" | tee -a "$REPORT"
fi
done
echo -e "\n=== Audit Complete. Report saved to $REPORT ==="
Remediation
No patch or CVE-specific fix applies here — this is a capability and posture improvement, not a vulnerability fix. The remediation steps below address the underlying detection and configuration gaps that make AI systems and GCP environments attractive targets.
Immediate Actions (This Week)
-
Inventory your AI/ML attack surface. Identify all AI workloads, model repositories, training pipelines, and AI API endpoints across your environment. You cannot protect what you have not catalogued. Pay special attention to shadow AI deployments spun up by engineering teams outside of security review.
-
Enable and centralize GCP Audit Logs. Ensure Admin Activity, Data Access, and System Event audit logs are enabled across all GCP projects and forwarded to your SIEM (Sentinel, Splunk, Chronicle, or otherwise). If you are not ingesting Data Access logs for Cloud Storage buckets containing AI/ML artifacts, you have a critical blind spot.
-
Eliminate user-managed service account keys. User-managed keys are the single most common persistence mechanism in GCP intrusions. Migrate to Workload Identity (GKE), service account impersonation, or short-lived credentials via
gcloud auth application-default. Set an organization policy constraint (constraints/iam.disableServiceAccountKeyCreation) to prevent new key creation. -
Apply least-privilege to AI service accounts. Service accounts used by AI training jobs, inference endpoints, and data pipelines are frequently over-privileged. Audit and reduce to the minimum required permissions. Remove
roles/ownerandroles/editorfrom all service accounts — use predefined or custom roles with scoped permissions. -
Enable uniform bucket-level access on all GCS buckets, especially those storing model weights, training data, or ML artifacts. Remove any
allUsersorallAuthenticatedUsersIAM bindings immediately.
Medium-Term Hardening (This Quarter)
-
Deploy EDR on GCP workloads. Whether you use CrowdStrike Falcon, SentinelOne, or another EDR, ensure your GCE instances and GKE nodes have sensor coverage. GKE clusters are not inherently monitored — you need daemonset-based sensor deployment for process-level visibility.
-
Implement AI-specific monitoring. Monitor API calls to AI/ML endpoints for anomalous patterns: bulk model downloads, unusual inference request volumes, and prompt patterns consistent with injection attacks. If your organization uses Vertex AI, enable and review Vertex AI audit logs.
-
Correlate cross-cloud telemetry. If you operate in multi-cloud, ensure your SIEM can correlate identity and network activity across AWS, Azure, and GCP. Adversaries routinely move between cloud providers to evade single-cloud detection.
-
Evaluate managed threat hunting coverage. If your SOC lacks the capacity for 24/7 human-led hunting across cloud and AI environments, evaluate managed services (CrowdStrike OverWatch, or equivalent MDR providers) that specifically cover GCP and AI workloads. Ask prospective providers explicitly: "Do your threat hunters cover GCP control plane activity and AI/ML infrastructure?"
Vendor Advisory
- CrowdStrike blog post: https://www.crowdstrike.com/en-us/blog/crowdstrike-expands-threat-hunting-across-ai-and-google-cloud/
- Google Cloud Audit Logging documentation: https://cloud.google.com/logging/docs/audit
- GCP Organization Policy constraints for IAM: https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts
Bottom Line
The expansion of Falcon Adversary OverWatch into AI systems and Google Cloud reflects a reality that defenders cannot afford to ignore: adversaries are already operating in these environments, and most organizations have inadequate detection coverage for them. Whether or not you are a CrowdStrike customer, the defensive imperatives are the same — get visibility into your GCP control plane, lock down service accounts and AI storage, deploy endpoint telemetry on cloud workloads, and ensure your hunting capability extends to where your adversaries already are.
The window between "we deployed AI workloads" and "an adversary found them" is closing. Act now.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.