[TTD] Google Cloud Vertex AI SDK Predictable Staging Bucket Abuse and Model Upload Hijack Exposure

Report Type: TTD
Threat Category: Cloud AI Supply Chain / Model Upload Staging Bucket Abuse
Assessment Date: June 18, 2026
Primary Impact Domain: AI Model Integrity and Cloud Workload Trust
Secondary Impact Domains: Cloud Storage Governance; Service-Account Security; ML Pipeline Trust; Endpoint Deployment Integrity; AI Governance and Compliance Confidence
Affected Asset Class: Google Cloud Vertex AI Workflows, Cloud Storage Staging Buckets, Serialized Model Artifacts, ML CI/CD Pipelines, Notebooks, Model Registries, Endpoints, and Vertex AI-Linked Service Accounts
Threat Objective Classification: Model Artifact Interception, Model Replacement, Model Poisoning, Unsafe Model-Load Execution, Model Theft, and Downstream Cloud Identity Abuse

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: June 18, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

‍  Google Cloud Vertex AI SDK for Python model-upload workflows are exposed to a cloud AI supply-chain abuse path where predictable or insufficiently verified staging bucket behavior can allow an attacker to pre-create or control the Cloud Storage bucket used during model upload, access or replace serialized model artifacts, and influence later model registration or deployment behavior. The executive concern is not only whether google-cloud-aiplatform has been updated, but whether model upload workflows, staging buckets, model artifacts, service accounts, Vertex AI deployments, and downstream AI workloads can still be trusted after the exposure window.

Executive Risk Translation

This threat converts a trusted ML development workflow into a model-artifact integrity and cloud workload trust issue. If attackers can control the staging location used during model upload, they may be able to access, replace, or poison model artifacts before the victim’s Vertex AI workflow imports, registers, loads, or deploys them. For organizations using Vertex AI for production ML, internal automation, analytics, customer-facing inference, regulated decision support, fraud detection, security automation, or AI-assisted operations, the risk is not limited to software patching. It includes model integrity, service-account permissions, unsafe deserialization exposure, model theft, model poisoning, endpoint deployment trust, and AI governance confidence.

S5 Executive Risk Summary

Business Risk

Vertex AI staging bucket abuse can undermine AI model integrity, ML pipeline trust, cloud storage governance, service-account isolation, production inference reliability, and confidence in AI-supported business workflows. Business impact increases where affected Vertex AI models support fraud detection, customer scoring, healthcare analytics, financial modeling, security automation, document processing, operational forecasting, customer-facing assistants, regulated decisions, or production services that automatically load or deploy model artifacts.

Technical Cause

The primary issue addressed by this TTD is the Unit 42-reported Vertex AI SDK Model.upload staging bucket hijack exposure. In that path, SDK-managed model-upload staging behavior may rely on a predictable or insufficiently verified Cloud Storage bucket when a user does not explicitly provide a trusted staging bucket. An attacker who can predict and pre-create the expected bucket name may cause a victim workflow to interact with attacker-controlled storage. Depending on serialization format, upload timing, model-loading behavior, and service-account permissions, this can create model artifact exposure, model replacement, model poisoning, unsafe deserialization, or downstream cloud identity abuse.

CVE-2026-2473 is related context, not the core vulnerability covered by this TTD. CVE-2026-2473 concerns predictable bucket naming in Vertex AI Experiments and helps demonstrate that predictable AI staging resources are a recurring detection concern. This TTD remains centered on the Model.upload staging bucket hijack exposure and the resulting model artifact integrity risk.

Threat Posture

This is strategically significant because it affects the trust boundary between ML developer tooling, Cloud Storage staging, model serialization, Vertex AI model upload, model registry state, and cloud-hosted model execution. The Model.upload issue should be treated as a detection-worthy cloud AI supply-chain exposure even where exploitation has not been confirmed. CVE-2026-2473 should be referenced only as related Vertex AI predictable-bucket context, not as the primary issue or as proof that all Vertex AI predictable-bucket behavior shares the same exploit path.

Executive Decision Requirement

Leadership should require immediate validation of google-cloud-aiplatform SDK versions, explicit trusted staging bucket configuration, review of Vertex AI model upload history, Cloud Storage bucket ownership and IAM review, service-account permission review, model artifact integrity validation, audit-log preservation, detection deployment across GCP, CI/CD, developer, storage, IAM, and Vertex AI telemetry, and controlled rebuild or redeployment of sensitive models where staging bucket trust cannot be proven.

S6 Executive Cost Summary

Google Cloud Vertex AI staging bucket abuse creates financial exposure because the organization must determine whether affected ML workflows were only exposed, whether attacker-controlled storage was used, whether model artifacts were accessed or replaced, and whether downstream Vertex AI workloads loaded untrusted model content.

Response cost is driven by SDK version validation, dependency inventory, CI/CD and notebook review, Cloud Storage audit review, bucket ownership validation, model artifact hash comparison, model registry inspection, service-account permission review, Vertex AI endpoint review, endpoint redeployment validation, customer-impact assessment, AI governance review, legal review where sensitive model or training data exposure cannot be ruled out, and remediation of overly broad cloud identity permissions.

Low Impact Scenario

Estimated $20K - $100K.

This scenario applies where vulnerable or unvalidated SDK usage is identified quickly, no attacker-controlled staging bucket use is observed, model artifact hashes match trusted build records, service-account access remains expected, Vertex AI model versions and endpoints are validated, and audit logs confirm no suspicious bucket creation, object access, artifact replacement, model deployment drift, or downstream data exposure.

Moderate Impact Scenario

Estimated $100K - $600K.

This scenario applies where SDK exposure, ambiguous staging bucket usage, unexplained model upload behavior, unusual Cloud Storage object activity, incomplete logs, unverified bucket ownership, or uncertain model provenance prevents the organization from quickly proving model integrity. Response may require model rebuilds, artifact comparison, service-account rotation, IAM cleanup, CI/CD review, endpoint rollback or redeployment, AI governance review, and stakeholder assurance.

High Impact Scenario

Estimated $600K - $3.5M+.

This scenario applies where attacker-controlled buckets were used, model artifacts were accessed or replaced, pickled or otherwise unsafe serialized content was loaded, service accounts accessed sensitive resources, models were poisoned or stolen, production endpoints served untrusted model versions, regulated or customer-impacting workflows were affected, or the organization must suspend, rebuild, retrain, revalidate, and redeploy critical AI systems.

S6A Key Cost Drivers

·        Number and importance of affected Vertex AI projects, regions, models, endpoints, pipelines, notebooks, CI/CD workflows, and service accounts.

·        Whether affected models support customer-facing inference, regulated decisions, fraud detection, security automation, financial analytics, healthcare analytics, operational forecasting, executive reporting, or production decision support.

·        Evidence of attacker-controlled staging buckets, unexpected bucket creation, abnormal object writes, object overwrites, object reads, model artifact replacement, unusual model upload events, endpoint deployment changes, service-account misuse, or sensitive data access.

·        Availability and retention of Cloud Audit Logs, Cloud Storage Data Access logs, Vertex AI audit logs, CI/CD logs, dependency build logs, notebook execution logs, Artifact Registry logs, Secret Manager logs, BigQuery audit logs, VPC Flow Logs, DNS logs, and identity logs.

·        Completeness of approved Vertex AI project, region, service-account, staging-bucket, model-registry, CI/CD, developer workstation, notebook, model artifact, and deployment-user inventories.

·        Scope of service-account key rotation, IAM review, bucket policy cleanup, model rebuilds, endpoint redeployments, model validation, and downstream application testing.

·        Business disruption caused by pausing model deployments, reverting endpoints, retraining models, revalidating model quality, rebuilding pipelines, and restoring AI governance confidence.

·        Customer, contractual, regulatory, legal, or model-risk exposure if model artifact theft, training metadata exposure, model poisoning, unsafe execution, production inference manipulation, or service-account misuse cannot be ruled out.

S6B Compliance and Risk Context

Vertex AI model upload compromise may create compliance, contractual, privacy, AI governance, customer-safety, model-risk-management, operational resilience, or data-protection exposure when model artifacts, training metadata, inference behavior, service accounts, cloud secrets, storage objects, or regulated workflows may have been affected.

Vulnerable SDK version status alone is not sufficient for breach determination. The governance question is whether the organization can prove that model staging, artifact upload, model registration, endpoint deployment, and service-account activity remained legitimate during the exposure window.

Risk Register Entry

Risk Title

Google Cloud Vertex AI SDK Predictable Staging Bucket Abuse and Model Upload Hijack Exposure

Risk Description

Attackers may abuse predictable or insufficiently verified Vertex AI SDK staging bucket behavior to pre-create or control Cloud Storage buckets, intercept model upload workflows, replace serialized model artifacts, influence unsafe model loading, steal models, poison models, trigger code execution through unsafe deserialization, or pivot through Vertex AI-linked service-account permissions.

Likelihood

Moderate for organizations using affected or unvalidated google-cloud-aiplatform SDK model-upload workflows without explicit trusted staging buckets, strong bucket ownership validation, complete Cloud Storage Data Access logging, model artifact provenance, and service-account least privilege.

Impact

Moderate to Severe depending on model sensitivity, production deployment dependency, service-account permissions, artifact serialization format, endpoint exposure, data sensitivity, and ability to prove model integrity.

Risk Rating

High

Annualized Risk Exposure

Estimated $100K - $750K for organizations with active Vertex AI development, incomplete SDK inventory, weak Cloud Storage Data Access logging, broad service-account permissions, limited model artifact provenance, and limited model deployment governance.

Exposure may exceed $750K - $3.5M+ where affected models support regulated, customer-facing, revenue-impacting, safety-impacting, security-critical, or executive decision workflows, or where model tampering forces retraining, production rollback, legal review, customer notification analysis, or AI governance remediation.

S10 Threat Overview

Vertex AI SDK predictable staging bucket abuse creates a practical AI supply-chain risk because model upload workflows depend on transient cloud storage that may be trusted by developer tooling, CI/CD automation, notebooks, and Vertex AI services.

The threat addressed by this TTD is the Unit 42-reported Vertex AI SDK Model.upload staging bucket hijack exposure. The activity centers on attacker control of a staging bucket that a victim Model.upload workflow may expect the SDK to create or use. If bucket naming is predictable and ownership verification is weak or absent, an attacker may pre-create the bucket in an external project. When the victim uploads a model without specifying a trusted staging bucket, the SDK may interact with attacker-controlled storage. That can expose serialized artifacts, create a model replacement opportunity, or influence later loading, registration, and deployment behavior.

CVE-2026-2473 should be treated as related background rather than the centerpiece of this TTD. That issue concerns Vertex AI Experiments predictable bucket naming and is useful for coverage mapping because it shares the broader pattern of predictable AI staging resource exposure. It should not be described as the same vulnerability as the Model.upload staging bucket hijack path unless a future source explicitly connects them operationally.

This TTD treats the activity as cloud AI model-upload hijack and model artifact integrity exposure, not as a narrow SDK version-compliance issue and not as a CVE-2026-2473-only coverage item.

S13 Targets and Exposure Surface

Primary Targets

Google Cloud Vertex AI SDK for Python model upload workflows.

google-cloud-aiplatform dependency versions used by developer workstations, notebooks, CI/CD runners, ML platforms, and automation jobs.

Vertex AI projects, regions, model registries, endpoints, batch prediction jobs, custom training jobs, pipelines, notebooks, and deployed model resources.

Cloud Storage staging buckets, SDK-created buckets, user-specified staging buckets, model artifact objects, serialized model files, pickle files, TensorFlow artifacts, PyTorch artifacts, custom prediction containers, and model metadata.

Vertex AI service accounts, CI/CD service accounts, notebook service accounts, workload identities, deployment identities, service agents, and project-level automation accounts.

Higher-Risk Deployment Conditions

Developers or pipelines call Vertex AI Model.upload without an explicitly controlled staging bucket.

Affected or unpinned google-cloud-aiplatform SDK versions are used in CI/CD, notebooks, or production ML automation.

Model artifacts use pickle or other serialization formats capable of unsafe code execution during load.

Vertex AI service accounts have broad Cloud Storage, Artifact Registry, Secret Manager, BigQuery, IAM, Cloud Build, GKE, Cloud Run, or project-level permissions.

Cloud Storage Data Access logs are disabled, incomplete, or short-lived.

Bucket creation, bucket IAM changes, and object access are not monitored.

Model artifact hashes, build provenance, signatures, attestations, or registry approval records are absent.

CI/CD runners can upload or deploy models without separation of duties.

Production endpoints automatically deploy newly uploaded model versions.

Exposure Surface

Cloud Storage global bucket namespace.

SDK-created or default Vertex AI staging buckets.

Vertex AI Model.upload workflows.

Serialized model artifacts and prediction code.

CI/CD model build and deployment jobs.

Developer notebooks and workstations.

Vertex AI model registry and endpoint deployment paths.

Cloud Audit Logs and Cloud Storage Data Access logs.

Service-account IAM, workload identity, service-agent permissions, and service-account keys.

Artifact Registry, Secret Manager, BigQuery, Cloud Build, Cloud Run, GKE, Compute Engine, and other resources reachable by Vertex AI-linked identities.

S17 MITRE ATT&CK Chain Flow Mapping

Stage 1: Attacker-Controlled Cloud Staging Resource Preparation

The attacker prepares cloud-hosted storage infrastructure by pre-creating a predictable Cloud Storage bucket that the victim’s Vertex AI SDK Model.upload workflow may attempt to use as a staging location.

·        T1583.006 Acquire Infrastructure: Web Services.

Stage 2: Model Upload Workflow Routed Through Untrusted Storage

The victim’s model-upload workflow interacts with the attacker-controlled or otherwise untrusted staging bucket during SDK-managed model upload. This creates an opportunity for model artifact exposure or artifact substitution before model registration or deployment.

·        T1195.002 Supply Chain Compromise: Compromise Software Supply Chain.

·        T1530 Data from Cloud Storage, applied only where Cloud Storage object access, model artifact retrieval, or model artifact exposure is observed.

Stage 3: Model Artifact Manipulation

The attacker may replace, alter, or stage malicious serialized model content, model files, or model metadata in the staging path before the victim workflow registers, loads, or deploys the model.

·        T1565.001 Data Manipulation: Stored Data Manipulation.

Stage 4: Conditional Execution Through Unsafe Model Loading

Execution is conditional and should only be mapped where telemetry shows that a tampered model artifact, unsafe serialized payload, custom prediction routine, or related model-loading behavior caused code or command execution.

·        T1059 Command and Scripting Interpreter, applied only where command, interpreter, or runtime execution is observed.

Conditional Technique Notes

Do not map this TTD to broad cloud compromise, generic credential theft, lateral movement, ransomware, container escape, or APT-specific behavior unless supporting telemetry connects those behaviors to the Vertex AI Model.upload staging bucket path.

Do not apply T1530 unless Cloud Storage object access, model artifact retrieval, or model artifact exposure is observed.

Do not apply T1059 unless runtime execution, command execution, or unsafe model-loading execution is observed.

Do not treat CVE-2026-2473 as the primary MITRE mapping driver for this TTD. CVE-2026-2473 is related predictable-bucket context for Vertex AI Experiments, while this section maps the Unit 42-reported Model.upload staging bucket hijack exposure.

S18 Attack Path Narrative

An attacker identifies a target organization using Vertex AI SDK model-upload workflows.

The attacker predicts the staging bucket name that the SDK may use when the victim does not explicitly provide a trusted staging bucket.

The attacker pre-creates the predictable Cloud Storage bucket in an attacker-controlled project.

A victim developer, notebook, or CI/CD job calls Vertex AI model upload using affected SDK behavior.

The SDK interacts with the pre-existing bucket, causing model artifacts to pass through untrusted storage or allowing attacker-controlled object manipulation.

The attacker may access uploaded artifacts, replace serialized model content, insert malicious pickle payloads, poison model behavior, alter metadata, or stage content that later influences model loading or deployment.

The victim registers or deploys the uploaded model in Vertex AI.

The attacker’s impact may include model theft, model poisoning, unsafe deserialization execution, endpoint manipulation, service-account misuse, access to adjacent cloud resources, or loss of trust in model provenance.

Defenders should detect this through correlated SDK dependency exposure, suspicious bucket creation, untrusted bucket ownership, Cloud Storage object access from non-customer projects, Vertex AI model upload events, model artifact hash drift, abnormal service-account activity, CI/CD upload anomalies, and downstream endpoint deployment changes.

S20 TTP Analysis

Initial Access

Attackers do not need direct access to the victim project if they can pre-create the expected Cloud Storage bucket in the global namespace before the victim workflow uses it.

Execution

Execution may occur if tampered serialized model artifacts, custom prediction code, or unsafe model-loading behavior is later loaded by a developer environment, CI/CD job, custom container, or Vertex AI deployment.

Persistence

Persistence may occur through poisoned model versions, untrusted artifacts in model registries, modified endpoint deployments, attacker-influenced model metadata, malicious custom prediction containers, CI/CD pipeline contamination, or continued use of attacker-controlled staging locations.

Privilege Escalation

Privilege escalation may occur if Vertex AI-linked service accounts, CI/CD service accounts, notebook identities, or model deployment identities have broad access to Cloud Storage, Secret Manager, BigQuery, Artifact Registry, IAM, Cloud Build, GKE, Cloud Run, or production resources.

Defense Evasion

Attackers may use bucket names that appear SDK-generated, benign object names, normal model artifact paths, expected pickle or model file extensions, short-lived object replacement, matching timestamps, model metadata reuse, or activity that resembles legitimate ML experimentation.

Credential Access

Attackers may attempt to access service-account tokens, metadata endpoints, cloud secrets, environment files, CI/CD variables, notebook credentials, or storage objects containing model credentials or training metadata if execution occurs.

Discovery

Attackers may inspect bucket contents, model file names, training metadata, project identifiers, region information, service-account names, endpoint names, artifact paths, dependency versions, and cloud resource naming conventions.

Command and Control / Tool Transfer

Attackers may stage malicious serialized payloads, secondary scripts, remote loaders, or external callback logic inside model artifacts or custom prediction code where unsafe model loading permits execution.

Impact

Attackers may steal models, poison model behavior, alter inference results, force model redeployment, trigger unsafe execution, abuse service-account permissions, damage AI governance confidence, disrupt production inference, or require full model provenance rebuild.

S20A — Adversary Tradecraft Summary

The durable tradecraft pattern is AI staging-trust conversion: predictable cloud storage naming or weak ownership validation allows attacker-controlled bucket placement, which is converted into model artifact access, model replacement, unsafe serialization exposure, model poisoning, or downstream cloud identity abuse. Detection should focus on staging bucket ownership, SDK behavior, model artifact provenance, upload-to-deployment sequence, and service-account activity rather than a single CVE, bucket name, object hash, proof-of-concept string, or vendor advisory.

S21 Detection Strategy Overview

Detection Philosophy

Detect Vertex AI staging bucket abuse through correlated cloud AI workflow behavior, not single indicators.

Primary Detection Anchors

Affected or unvalidated google-cloud-aiplatform SDK usage, Vertex AI model upload events, SDK-managed staging bucket use, bucket creation or existence outside approved project ownership, Cloud Storage object writes to staging paths, object reads from unusual principals, model artifact hash drift, Vertex AI model registration, endpoint deployment changes, service-account activity, CI/CD upload activity, and downstream cloud-resource access.

Detection Prioritization Model

Prioritize events where affected SDK usage or model-upload activity aligns with unapproved staging bucket ownership, unexpected bucket creation, object writes by unusual principals, object reads from external projects, model artifact hash mismatch, model upload followed by endpoint deployment, or service-account activity against sensitive resources within a bounded time window.

Correlation Strategy Strict Enforcement

Do not promote one SDK version finding, one bucket creation event, one model upload, one Cloud Storage object write, or one endpoint deployment event to high confidence without project, region, bucket, service account, model artifact, CI/CD job, Vertex AI model, endpoint, identity, or time-window correlation.

Telemetry Prioritization

Prioritize Cloud Audit Logs, Cloud Storage Admin Activity logs, Cloud Storage Data Access logs, Vertex AI audit logs, Cloud Asset Inventory, CI/CD logs, dependency inventory, notebook logs, endpoint deployment logs, IAM policy change logs, Secret Manager logs, Artifact Registry logs, BigQuery audit logs, VPC Flow Logs, DNS logs, and EDR telemetry from ML developer and build systems.

Detection Design Constraints

Avoid detection designs based only on CVE name, SDK package name, one predictable bucket string, one public proof-of-concept pattern, one object extension, one vulnerable version, or one model-upload event.

Baseline and Deployment Requirements

Baseline approved Vertex AI projects, approved regions, approved staging buckets, approved bucket naming conventions, approved service accounts, approved CI/CD runners, approved notebook users, approved model registries, approved model artifact hashes, approved endpoint deployment workflows, approved storage principals, approved release windows, and approved emergency rebuild workflows.

Variant Resilience Requirements

Rules should remain useful for future Vertex AI, AI platform, ML pipeline, or cloud SDK staging abuse paths that produce the same operational behavior: predictable or untrusted staging location, model artifact upload through unapproved storage, artifact replacement, model registry manipulation, endpoint deployment drift, service-account misuse, and model provenance failure.

Operational Detection Model

Run detections in hunt mode first, tune exceptions, validate project and bucket ownership joins, verify Cloud Storage Data Access logging, confirm Vertex AI audit-log coverage, baseline approved ML deployment workflows, and then promote to alert mode.

Explicit Non-Deployment Guardrails

Do not claim confirmed model hijack from affected SDK version alone. Do not claim code execution without model-loading, endpoint, process, container, or runtime evidence. Do not attribute unrelated GCP identity, storage, network, or endpoint anomalies to Vertex AI SDK abuse without staging bucket, model upload, service-account, artifact, or time-window linkage.

Figure

S22 Primary Detection Signals

Primary Detection Signals

Vertex AI Model.upload activity from projects using affected or unvalidated google-cloud-aiplatform SDK versions.

Model upload workflows without explicit approved staging bucket configuration.

Creation or existence of expected Vertex AI staging bucket names outside approved project ownership.

Cloud Storage bucket creation with naming patterns tied to project ID, region, Vertex AI, staging, or SDK-generated conventions.

Cloud Storage object writes to model artifact paths from unexpected principals, projects, networks, or automation identities.

Cloud Storage object reads from staging buckets by principals outside approved Vertex AI, CI/CD, notebook, or build workflows.

Model artifact hash mismatch between build output, staging object, model registry, and deployed model version.

Vertex AI model registration followed by endpoint deployment from untrusted or unverified artifacts.

Unexpected IAM policy changes on staging buckets, model artifact buckets, Vertex AI service accounts, or CI/CD service accounts.

Supporting Detection Signals

CI/CD jobs invoking model upload with newly installed, unpinned, vulnerable, or unvalidated google-cloud-aiplatform dependency versions.

Notebook executions that call Vertex AI upload outside approved user, project, region, or maintenance window.

Bucket IAM changes granting external principals access to staging or model artifact locations.

Object overwrite, delete, compose, rewrite, or metadata update operations near model upload time.

New model versions with unexpected source URI, artifact URI, container image, environment variable, or service account.

Vertex AI endpoint deployment changes shortly after suspicious storage activity.

Service-account access to Secret Manager, BigQuery, Artifact Registry, Cloud Build, GKE, Cloud Run, IAM, or Cloud Storage after suspicious model upload.

Exploit Attempt and Instability Signals

Repeated failed bucket creation attempts for predictable Vertex AI staging names.

Cloud Storage bucket conflict or bucket-already-exists patterns during model upload automation.

Model upload failure followed by retry using the same staging location.

Model import or deployment errors involving unexpected artifact format, pickle load failure, container startup failure, or model server exceptions.

Outbound Communication Signals

Unexpected egress from model-serving containers, training jobs, notebooks, or CI/CD runners after model upload or deployment.

DNS or VPC Flow activity from Vertex AI-linked workloads to newly seen, rare, suspicious, or unapproved destinations.

Persistence and Post-Exploitation Signals Conditional

Unapproved model versions, endpoint traffic splits, custom prediction routines, container image changes, service-account changes, bucket lifecycle changes, object retention changes, or CI/CD pipeline modifications.

Lateral Movement and Expansion Signals Conditional

Use of Vertex AI, CI/CD, notebook, or model-serving service accounts against adjacent GCP resources, secrets, storage, data warehouses, artifact registries, source repositories, or production infrastructure.

Signal Usage Constraints

Do not treat a single signal as compromise confirmation. Promote confidence when signals align by GCP organization, project, region, bucket, service account, model ID, endpoint ID, artifact path, CI/CD job, user, source IP, and time window.

S23 Telemetry Requirements

Required Telemetry

Cloud Audit Logs.

Cloud Storage Admin Activity logs.

Cloud Storage Data Access logs for staging and model artifact buckets.

Vertex AI audit logs.

Cloud Asset Inventory.

IAM policy change logs.

Cloud Build, GitHub Actions, GitLab CI, Jenkins, or other CI/CD logs.

Dependency inventory for google-cloud-aiplatform.

Notebook execution logs where applicable.

Approved Vertex AI project inventory.

Approved Vertex AI region inventory.

Approved staging bucket inventory.

Approved service-account lookup.

Approved CI/CD runner lookup.

Approved notebook user lookup.

Approved model registry and endpoint inventory.

Approved release or maintenance-window lookup.

Strongly Recommended Telemetry

VPC Flow Logs.

Cloud DNS logs.

Cloud NAT logs.

Secret Manager audit logs.

Artifact Registry audit logs.

BigQuery audit logs.

Cloud Run, GKE, Cloud Functions, or Compute Engine logs for model-serving workloads.

EDR telemetry from ML build systems and developer workstations.

Model artifact hash inventory.

Model signing or provenance records.

Software bill of materials for ML pipelines.

Package-lock, requirements, Poetry, pip-tools, or build dependency records.

Model registry approval records.

Endpoint traffic-split change records.

Container image build and deploy logs.

Recently seen domain enrichment.

Known-good model artifact baseline.

Local Mapping Required

GCP organization ID.

Folder ID.

Project ID.

Region.

Vertex AI model ID.

Vertex AI endpoint ID.

Model version.

Model artifact URI.

Staging bucket name.

Bucket project owner.

Bucket location.

Bucket IAM policy.

Object path.

Object generation.

Object hash.

Object action.

Principal email.

Service account.

Workload identity.

CI/CD job ID.

Notebook user.

SDK package version.

Source IP.

User agent.

Endpoint deployment action.

Traffic split.

Container image.

Secret access.

BigQuery dataset access.

Artifact Registry repository.

Maintenance-window status.

Approved staging bucket status.

Approved service-account status.

Approved CI/CD status.

Approved model artifact status.

S24 Detection Opportunities and Gaps

Detection Opportunities

Cloud Storage bucket creation and ownership can reveal predictable bucket squatting or unapproved staging locations.

Cloud Storage Data Access logs can reveal unexpected object reads, writes, overwrites, deletes, rewrites, or metadata changes around model upload.

Vertex AI audit logs can reveal model upload, model registration, endpoint deployment, and endpoint traffic-split changes.

Dependency inventory can identify affected or unvalidated google-cloud-aiplatform usage in notebooks, CI/CD, and ML platforms.

Model artifact hashes and provenance records can reveal replacement or tampering.

IAM logs can reveal service-account, bucket, or deployment permission changes.

CI/CD logs can connect model upload activity to code changes, dependency versions, and release windows.

Secret Manager, BigQuery, Artifact Registry, and VPC Flow telemetry can reveal downstream service-account misuse after suspicious model upload.

Detection Gaps

Cloud Storage Data Access logs may be disabled or selectively enabled.

Historical SDK version data may be incomplete for developer workstations and notebooks.

Model artifact hashes may not be preserved.

Untrusted staging bucket use may not be obvious if bucket names appear normal.

Cloud Storage bucket namespace is global, but ownership may require asset and audit correlation.

Unsafe model loading may occur outside Vertex AI logs, especially in notebooks or custom containers.

Model poisoning may not produce obvious runtime indicators.

Endpoint behavior changes may require ML quality, inference, or application telemetry to confirm.

GCP audit logs alone cannot prove model artifact execution.

Compensating Controls

Use Cloud Asset Inventory, Cloud Audit Logs, Cloud Storage Data Access logs, Vertex AI audit logs, CI/CD logs, dependency inventory, model artifact hashes, registry approval records, endpoint deployment records, IAM review, service-account access review, and controlled model rebuilds.

Do not rely only on SDK update status if model upload activity occurred during the exposure window.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

Production-deployable only where NDR / Network Behavioral Analytics can ingest or correlate with cloud audit telemetry, Cloud Storage object activity, DNS, proxy, CI/CD, identity, service-account, and model-workflow enrichment. Pure packet, NetFlow, DNS-only, or proxy-only visibility is not sufficient because the core behavior depends on Vertex AI model-upload context, Cloud Storage staging bucket ownership, artifact URI interpretation, and service-account linkage. Use this rule as a cloud-enriched correlation model, not as a standalone network-only detection.

Rule

Vertex AI Model Upload Staging Abuse With Network or Identity Follow-On

Rule Format

NDR / Network Behavioral Analytics cloud-enriched correlation model requiring product-specific translation, cloud API enrichment, DNS/proxy baselining, service-account mapping, and local workflow inventory. This is not product-native syntax until translated and validated against the customer’s NDR platform.

Detection Purpose

Detect Vertex AI model-upload staging abuse where unapproved or newly seen Cloud Storage staging bucket use aligns with unusual object access, rare egress, CI/CD dependency exposure, service-account activity, or endpoint deployment behavior.

Detection Logic

Trigger when Vertex AI model upload, model creation, model import, or endpoint deployment activity references a Cloud Storage artifact URI whose extracted staging bucket is not in the approved Vertex AI staging bucket inventory.

Assign medium severity when unapproved staging bucket use is observed with sufficient cloud-audit context but without additional downstream evidence.

Assign high severity when unapproved staging bucket use is followed within 120 minutes by Cloud Storage object write, overwrite, read, delete, rewrite, bucket IAM change, rare egress from a Vertex AI-linked workload, affected or unvalidated SDK usage, model artifact hash drift, endpoint deployment, or unusual service-account activity.

Promote to critical only when suspicious staging activity aligns with confirmed unsafe model-load behavior, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, model poisoning evidence, model theft evidence, or confirmed malicious artifact evidence.

Do not promote network-only indicators to high or critical unless they are linked to the same project, workload, service account, model, endpoint, bucket, artifact URI, CI/CD job, or bounded time window.

Required Telemetry

Vertex AI audit logs.

Cloud Audit Logs.

Cloud Storage Admin Activity logs.

Cloud Storage Data Access logs.

Cloud Asset Inventory.

DNS logs.

Proxy logs.

NDR session telemetry.

VPC Flow Logs where available.

CI/CD dependency telemetry.

Service-account inventory.

Model artifact hash inventory where available.

Approved Vertex AI project lookup.

Approved staging bucket lookup.

Approved service-account lookup.

Approved CI/CD runner lookup.

Approved model artifact hash lookup.

Approved egress-destination lookup.

Approved maintenance-window lookup.

Engineering Implementation Instructions

Map project_id, region, principal_email, service_account, source_ip, caller_ip, method_name, service_name, artifact_uri, staging_bucket, bucket_name, object_name, object_hash, model_id, endpoint_id, ci_job_id, package_name, package_version, package_version_status, dest_domain, dest_ip, proxy_action, dns_query, workload_id, and timestamp.

Create local enrichment that extracts staging_bucket from gs:// artifact URIs and maps the bucket to project owner, organization owner, IAM policy, retention policy, bucket location, approved use, and model workflow.

Create package_version_status from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint software inventory, or dependency inventory. Treat package_version_status as local enrichment, not a native NDR field.

Create asset groups for Vertex AI projects, Vertex AI-linked workloads, ML CI/CD runners, notebook hosts, model-serving hosts, approved staging buckets, approved service accounts, approved egress destinations, and approved maintenance windows.

Validate that cloud API events, storage object logs, DNS, proxy, and service-account telemetry can be joined by project, workload identity, service account, CI/CD job, bucket, model ID, endpoint ID, and bounded time window before enabling alert mode.

Run in hunt mode first to baseline normal model uploads, approved ML experimentation, notebook activity, endpoint deployments, batch prediction jobs, and CI/CD release behavior.

Treat cloud log ingestion, Cloud Storage Data Access logging, NDR enrichment, bucket ownership mapping, package-version enrichment, model-hash inventory, egress baselining, allowlist tuning, and SOC triage routing as required local deployment work.

DRI Assessment

High where NDR / Network Behavioral Analytics has cloud audit, storage object, DNS, proxy, CI/CD, identity, and model-provenance enrichment. Moderate where the platform only has DNS, proxy, or flow telemetry without cloud audit context.

DRI

8.4 / 10

TCR Assessment

Operational confidence is moderate for unapproved staging bucket use alone and high when unapproved staging aligns with storage object activity, rare egress, SDK exposure, endpoint deployment, service-account activity, or model artifact drift.

Operational TCR

7.9 / 10

Full-Telemetry TCR

9.0 / 10

Limitations

NDR alone cannot prove Vertex AI staging bucket abuse. Network telemetry cannot independently validate bucket ownership, model artifact integrity, Vertex AI audit method semantics, SDK versions, endpoint deployment state, or model registry trust. Do not attribute rare egress, DNS anomalies, or proxy events to this TTD unless they link to the same project, workload, service account, model, endpoint, bucket, artifact URI, CI/CD job, or bounded time window.

Detection Query Pattern

Use the following as a cloud-enriched NDR / Network Behavioral Analytics correlation model, not product-native NDR syntax. Translate this pattern into the customer’s NDR, network analytics, or SIEM-backed network correlation platform only after validating cloud audit ingestion, Cloud Storage Data Access logging, bucket ownership enrichment, service-account mapping, workload identity mapping, and bounded time-window correlation.

This pattern should not alert from network telemetry alone. It requires a cloud-audit-confirmed Vertex AI model-upload event referencing an unapproved or newly seen Cloud Storage staging bucket, followed by one or more corroborating storage, dependency, identity, or network signals.

CORRELATION MODEL:

Vertex AI Model Upload Staging Abuse With Network or Identity Follow-On

PRIMARY SIGNAL:

source = cloud_audit

service_name = "aiplatform.googleapis.com"

method_name contains one of:

  - "UploadModel"

  - "CreateModel"

  - "ImportModel"

  - "DeployModel"

artifact_uri starts with "gs://"

extracted_staging_bucket = bucket extracted from artifact_uri

extracted_staging_bucket not in APPROVED_VERTEX_STAGING_BUCKETS

project_id in APPROVED_VERTEX_PROJECTS

FOLLOW-ON SIGNALS WITHIN 120 MINUTES:

source = cloud_storage_audit

service_name = "storage.googleapis.com"

bucket_name = extracted_staging_bucket

method_name contains one of:

  - "storage.objects.create"

  - "storage.objects.update"

  - "storage.objects.delete"

  - "storage.objects.get"

  - "storage.objects.rewrite"

  - "storage.buckets.setIamPolicy"

OR

source = dependency_inventory

package_name = "google-cloud-aiplatform"

package_version_status in:

  - "affected"

  - "unvalidated"

OR

source = network_analytics

workload_id in VERTEX_AI_LINKED_WORKLOADS

service_account matches primary_signal.service_account

dest_domain not in APPROVED_VERTEX_EGRESS_DESTINATIONS

proxy_action in:

  - "allowed"

  - "proxied"

  - "connected"

OR

source = identity_or_service_account_activity

service_account matches primary_signal.service_account

activity_type contains one of:

  - "Secret Manager access"

  - "BigQuery access"

  - "Artifact Registry modification"

  - "IAM policy change"

  - "production endpoint deployment"

  - "endpoint traffic shift"

CORRELATION KEYS:

project_id

service_account

principal_email

extracted_staging_bucket

artifact_uri

model_id

endpoint_id

ci_job_id

workload_id

SEVERITY:

medium when the primary signal is present with sufficient cloud-audit context but without follow-on evidence.

high when the primary signal is followed within 120 minutes by Cloud Storage object activity, bucket IAM change, affected or unvalidated SDK usage, rare egress from a Vertex AI-linked workload, model artifact hash drift, endpoint deployment, or unusual service-account activity.

critical only when the correlated activity includes confirmed unsafe model-load behavior, model artifact tampering, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence.

SUPPRESSION:

suppress when maintenance_window = true

suppress when extracted_staging_bucket in APPROVED_VERTEX_STAGING_BUCKETS

suppress when service_account in APPROVED_VERTEX_SERVICE_ACCOUNTS and activity matches approved release workflow

suppress when ci_job_id in APPROVED_VERTEX_CICD_RUNNERS and build_id has approved deployment record

suppress when dest_domain in APPROVED_VERTEX_EGRESS_DESTINATIONS

OUTPUT:

first_seen

last_seen

severity

project_id

region

principal_email

service_account

source_ip

caller_ip

artifact_uri

extracted_staging_bucket

bucket_name

object_name

method_name

model_id

endpoint_id

ci_job_id

workload_id

package_version

package_version_status

dest_domain

dest_ip

correlation_reason

SentinelOne

Detection Viability Assessment

Production-deployable where SentinelOne covers ML developer workstations, notebook hosts, CI/CD runners, build servers, model-serving hosts, or container hosts that execute Vertex AI SDK workflows or load model artifacts. SentinelOne is not the primary control for bucket ownership, Vertex AI audit validation, Cloud Storage object ownership, or model registry state. Use SentinelOne as endpoint-side visibility for affected SDK usage, unsafe model loading, suspicious Python behavior, credential access, metadata-service access, transfer tooling, and unusual outbound communication from ML workflow systems.

Rule

Vertex AI Workflow Host Unsafe Model Artifact Load or Suspicious Cloud Interaction

Rule Format

SentinelOne Deep Visibility / STAR translation pattern requiring product-specific syntax validation, host grouping, dependency enrichment, command-line baselining, and cloud-event correlation. The rule body should be treated as a detection engineering template until translated into validated SentinelOne query syntax.

Detection Purpose

Detect suspicious endpoint behavior from ML workflow hosts, notebooks, CI/CD runners, or model-serving systems that may indicate unsafe model artifact loading, malicious serialized model execution, credential access, or unusual cloud interaction after Vertex AI staging bucket exposure.

Detection Logic

Trigger when a Vertex AI workflow host executes Python, pickle, joblib, cloudpickle, model-loading routines, shell commands, cloud transfer tools, metadata-service access, credential-file access, or unusual outbound communication near model upload, model artifact retrieval, or endpoint deployment activity.

Assign medium severity for affected or unvalidated Vertex AI SDK usage on ML workflow hosts with model upload behavior.

Assign high severity when model-loading behavior aligns with shell execution, suspicious Python execution, metadata access, credential-file access, external retrieval, rare outbound communication, or suspicious child processes.

Promote to critical only when endpoint behavior is correlated with unapproved staging bucket use, suspicious Cloud Storage object activity, model artifact hash mismatch, endpoint deployment, Secret Manager access, service-account misuse, or confirmed malicious serialized artifact evidence.

Do not treat SentinelOne endpoint behavior as proof of the GCP staging-bucket path unless it is correlated to cloud-side Vertex AI, Cloud Storage, artifact, service-account, or deployment evidence.

Required Telemetry

SentinelOne process telemetry.

SentinelOne command-line telemetry.

SentinelOne parent-process telemetry.

SentinelOne file telemetry.

SentinelOne network telemetry.

ML developer workstation group.

Notebook host group.

CI/CD runner host group.

Model-serving host group.

Approved Python command-pattern lookup.

Approved CI/CD workflow lookup.

Approved model artifact path lookup.

Approved service-account credential path lookup.

Approved egress-destination lookup.

Cloud correlation feed where available.

Engineering Implementation Instructions

Map EndpointName, EndpointId, AgentUuid, ProcessName, ProcessImagePath, ParentProcessName, ParentProcessImagePath, ProcessUser, CmdLine, FilePath, FileEventType, DstIp, DstPort, DstDomain, EventTime, and host group membership.

Create host groups for Vertex AI workflow hosts, notebook hosts, CI/CD runners, model-serving hosts, developer workstations, and approved security validation systems.

Create package-version enrichment from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint software inventory, or dependency inventory. Treat the enrichment as local context, not a native SentinelOne field.

Validate process and command-line patterns for python, python3, pip, poetry, conda, jupyter, ipykernel, cloudpickle, pickle, joblib, tensorflow, torch, gcloud, gsutil, curl, wget, bash, sh, and container runtime parents.

Create exceptions for approved model training, approved notebook experimentation, approved CI/CD model releases, approved deployment scripts, model rebuilds, vulnerability validation, incident response, and security scanning.

Run in hunt mode before alert mode to baseline normal ML development, model loading, model testing, artifact retrieval, deployment, and experiment workflows.

Treat host grouping, package enrichment, command-line validation, approved workflow exceptions, model artifact path mapping, egress baselining, and SIEM correlation to cloud audit events as required local deployment work.

DRI Assessment

High for endpoint-side unsafe model loading, suspicious Python behavior, credential access, and unusual outbound activity on managed ML workflow hosts.

DRI

8.2 / 10

TCR Assessment

Moderate when SentinelOne only sees endpoint behavior. High when correlated with Vertex AI audit logs, Cloud Storage Data Access logs, unapproved staging bucket use, model artifact hash drift, service-account activity, or endpoint deployment.

Operational TCR

7.8 / 10

Full-Telemetry TCR

9.0 / 10

Limitations

SentinelOne does not natively validate Cloud Storage bucket ownership, Vertex AI audit method names, GCP model registry state, Cloud Storage object generation, or GCP endpoint deployment state. Legitimate ML workflows may execute Python, load serialized artifacts, contact external repositories, call Google APIs, and use cloud transfer tools. Critical severity requires cloud-side, artifact-side, service-account, or runtime correlation.

Detection Query Pattern

Use the following as a SentinelOne Deep Visibility / STAR translation model, not guaranteed copy/paste syntax. Validate the exact SentinelOne field names, query operators, event types, and data availability in the customer tenant before deployment.

This pattern should not be treated as proof of the GCP Vertex AI staging-bucket path by itself. It is endpoint-side supporting detection for ML workflow hosts that may be involved in affected Vertex AI SDK usage, unsafe model artifact loading, credential access, metadata-service access, transfer tooling, or unusual outbound communication. Promote severity only when correlated with cloud-side Vertex AI, Cloud Storage, service-account, model artifact, or endpoint deployment evidence, or when endpoint telemetry shows a stronger standalone indicator such as metadata-service access, credential access, unsafe model-load execution, or suspicious child-process execution from a model-loading context.

TRANSLATION MODEL:
Vertex AI Workflow Host Unsafe Model Artifact Load or Suspicious Cloud Interaction

HOST SCOPE:
EndpointName in VERTEX_AI_WORKFLOW_HOSTS
OR EndpointName in VERTEX_AI_NOTEBOOK_HOSTS
OR EndpointName in VERTEX_AI_CICD_RUNNERS
OR EndpointName in VERTEX_AI_MODEL_SERVING_HOSTS

PRIMARY PROCESS INDICATORS:
ProcessName in:

·        "python"

·        "python3"

·        "jupyter"

·        "ipykernel"

·        "pip"

·        "poetry"

·        "conda"

·        "gcloud"

·        "gsutil"

OR

CmdLine contains one of:

·        "google-cloud-aiplatform"

·        "aiplatform.Model.upload"

·        "pickle.load"

·        "joblib.load"

·        "cloudpickle"

·        "torch.load"

·        "tensorflow"

·        "sklearn"

·        "model.tar"

·        ".pkl"

·        ".pickle"

·        ".joblib"

SUSPICIOUS FOLLOW-ON INDICATORS:
CmdLine contains one of:

·        "metadata.google.internal"

·        "computeMetadata/v1"

·        "GOOGLE_APPLICATION_CREDENTIALS"

·        "secretmanager.googleapis.com"

·        "storage.googleapis.com"

·        "curl"

·        "wget"

·        "bash -c"

·        "sh -c"

OR

ChildProcessName in:

·        "sh"

·        "bash"

·        "dash"

·        "zsh"

·        "curl"

·        "wget"

·        "nc"

·        "ncat"

·        "python"

·        "python3"

OR

FilePath matches one of:

·        "*.pkl"

·        "*.pickle"

·        "*.joblib"

·        "*model.tar"

·        "*model.tar.gz"

OR

DstDomain not in APPROVED_VERTEX_EGRESS_DESTINATIONS
AND DstDomain is rare for the host, workflow, CI/CD job, notebook, or model-serving service account
AND the network event is associated with a scoped model-loading process, Vertex AI SDK process, cloud transfer process, or suspicious child process

LOCAL ENRICHMENT:
package_name = "google-cloud-aiplatform"
package_version_status in:

·        "affected"

·        "unvalidated"

package_version_status must be populated from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint software inventory, or dependency inventory. Do not treat package_version_status as a native SentinelOne field.

CORRELATION REQUIREMENT:
Correlate endpoint-side matches within 120 minutes of one or more cloud-side signals:

·        Vertex AI model upload, model creation, model import, or endpoint deployment

·        Cloud Storage object write, overwrite, read, delete, rewrite, or bucket IAM change

·        Unapproved or newly seen Vertex AI staging bucket

·        Model artifact hash mismatch

·        Service-account activity against sensitive resources

·        Production endpoint deployment or endpoint traffic shift

For high or critical severity, require cloud-side correlation unless the endpoint-side evidence includes a stronger standalone indicator such as metadata-service access, credential-file access, Secret Manager access, unsafe model-load execution, suspicious child-process execution from a model-loading context, or confirmed malicious serialized artifact behavior.

SEVERITY:
medium when affected or unvalidated SDK usage appears on a scoped ML workflow host with model upload or artifact-handling behavior.

high when scoped endpoint behavior includes metadata access, credential-file access, external retrieval, rare outbound communication tied to a scoped model-loading or Vertex AI SDK process, suspicious child-process execution from a model-loading context, or suspicious model artifact access, and at least one reliable local join key or cloud-side signal supports the Vertex AI workflow relationship.

critical only when endpoint behavior is correlated with unapproved staging bucket use, suspicious Cloud Storage object activity, model artifact hash mismatch, service-account misuse, endpoint deployment, unsafe model-load execution, or confirmed malicious serialized artifact evidence.

SUPPRESSION:
suppress when EndpointName in APPROVED_VERTEX_SECURITY_VALIDATION_HOSTS
suppress when CmdLine in APPROVED_VERTEX_COMMAND_PATTERNS
suppress when FilePath in APPROVED_MODEL_ARTIFACT_PATHS
suppress when DstDomain in APPROVED_VERTEX_EGRESS_DESTINATIONS
suppress when DstDomain is common for the host, workflow, CI/CD job, notebook, or model-serving service account
suppress when CI/CD job, build ID, or deployment workflow is approved
suppress when maintenance_window = true

OUTPUT:
EventTime
EndpointName
EndpointId
AgentUuid
ProcessUser
ProcessName
ProcessImagePath
ParentProcessName
ParentProcessImagePath
ChildProcessName
CmdLine
FilePath
FileEventType
DstIp
DstPort
DstDomain
package_version
package_version_status
correlation_reason
severity

Splunk

Detection Viability Assessment

Production-deployable where Splunk ingests GCP audit logs, Cloud Storage Data Access logs, Vertex AI audit logs, Cloud Asset Inventory exports, CI/CD logs, dependency inventory, IAM logs, endpoint logs, DNS/proxy logs, and model provenance data. Alert-mode deployment should use normalized fields, macros, lookups, summary indexes, accelerated datasets, and bounded time windows. Avoid broad raw joins, unbounded subsearches, repeated mvexpand, high-volume append chains, and direct cross-source correlation over large raw datasets.

Rule

Vertex AI Model Upload to Unapproved Staging Bucket With Storage Artifact or Endpoint Follow-On

Rule Format

Splunk SPL production correlation search requiring local index, sourcetype, macro, lookup, summary-index, accelerated-dataset, and enrichment mapping. Any heavy multi-source search should be converted into staged candidate datasets, summary indexes, or accelerated data models before alert-mode deployment.

Detection Purpose

Detect Vertex AI model upload workflows that use unapproved staging buckets and align with suspicious Cloud Storage object activity, bucket administration, affected or unvalidated SDK usage, model artifact drift, endpoint deployment, service-account activity, or endpoint-side execution evidence.

Detection Logic

Trigger when Vertex AI model upload, model creation, model import, or endpoint deployment activity references a Cloud Storage artifact URI whose bucket is not in the approved Vertex AI staging bucket inventory.

Assign medium severity for unapproved staging bucket use.

Assign high severity when unapproved staging bucket use aligns with object writes, reads, overwrites, deletes, rewrites, bucket IAM changes, affected or unvalidated SDK usage, endpoint deployment, or model artifact hash mismatch within 120 minutes.

Promote to critical only when suspicious staging activity is followed by sensitive service-account activity, Secret Manager access, BigQuery access, Artifact Registry modification, IAM changes, unsafe model-load evidence, production endpoint traffic shift, confirmed model poisoning evidence, or confirmed malicious artifact evidence.

Do not treat a vulnerable or unvalidated SDK version alone as compromise. Use dependency status as exposure enrichment that raises priority when paired with unapproved staging, object activity, endpoint deployment, model artifact drift, or service-account activity.

Required Telemetry

GCP audit logs.

Cloud Storage Data Access logs.

Vertex AI audit logs.

Cloud Asset Inventory exports.

CI/CD logs.

Dependency inventory.

IAM policy logs.

Endpoint logs where available.

DNS/proxy logs where available.

Model provenance or hash records.

Approved staging bucket lookup.

Approved service-account lookup.

Approved CI/CD runner lookup.

Approved endpoint lookup.

Approved command-pattern lookup.

Approved maintenance-window lookup.

Engineering Implementation Instructions

Map indexes and sourcetypes for GCP audit logs, Cloud Storage logs, Vertex AI logs, CI/CD logs, dependency inventory, model registry exports, IAM policy logs, endpoint logs, DNS/proxy logs, and model provenance records.

Normalize gcp_project_id, region, principal_email, caller_ip, method_name, service_name, bucket_name, object_name, artifact_uri, staging_bucket, model_id, endpoint_id, service_account, ci_job_id, package_name, package_version, package_version_status, object_hash, endpoint_name, process_name, command_line, dest_domain, dest_ip, and _time.

Create lookups for approved Vertex AI projects, approved staging buckets, approved service accounts, approved CI/CD runners, approved model hashes, approved endpoints, approved release windows, approved package-version status, approved command patterns, approved egress destinations, and approved deployment users.

Create package_version_status as a local enrichment field from SCA, SBOM, CI/CD package telemetry, notebook package exports, endpoint software inventory, or dependency-management records. Do not treat package_version_status as a native Splunk field.

Use macros for GCP audit normalization, Vertex AI method scoping, Cloud Storage artifact scoping, approved staging bucket suppression, maintenance-window evaluation, CI/CD dependency enrichment, endpoint workflow-host scoping, and high-risk service-account activity.

For alert mode, convert the broad hunt pattern into staged candidate datasets: one for unapproved Vertex AI upload candidates, one for unapproved Cloud Storage object activity, one for affected or unvalidated dependency usage, and one for endpoint-side unsafe model-load indicators. Correlate those staged datasets over bounded windows instead of repeatedly searching high-volume raw indexes.

Validate Cloud Storage Data Access logging, artifact URI extraction, lookup output fields, macro expansion, Vertex AI audit method names, endpoint field mappings, staged dataset performance, and query runtime before alert-mode deployment.

Run in hunt mode against at least 30 days of history to baseline normal ML experimentation, model uploads, notebook use, endpoint deployment, batch prediction, and CI/CD release behavior.

Treat index mapping, macro validation, lookup hygiene, field normalization, package-version enrichment, hash inventory, summary-index design, query-performance testing, and SOC triage routing as required local deployment work.

DRI Assessment

High where Splunk can join Vertex AI, Cloud Storage, CI/CD, IAM, endpoint, DNS/proxy, and model provenance data by project, bucket, artifact URI, principal, model, endpoint, service account, host, and bounded time window.

DRI

9.0 / 10

TCR Assessment

High when unapproved staging bucket use aligns with object manipulation, endpoint deployment, affected or unvalidated SDK usage, service-account activity, endpoint-side execution evidence, or artifact hash drift. Lower where Data Access logs, dependency inventory, model hashes, or endpoint telemetry are absent.

Operational TCR

8.5 / 10

Full-Telemetry TCR

9.5 / 10

Limitations

Effectiveness depends on Cloud Storage Data Access logs, artifact URI capture, SDK inventory, approved bucket inventory, model hash records, and reliable local enrichment. Legitimate experimentation may use temporary buckets. Critical severity requires stronger evidence than unapproved bucket use alone. The supplied query pattern should be treated as a hunt/correlation design unless converted into summary-indexed, accelerated, and locally performance-tested alert logic.

Detection Query Pattern

Use the following as a Splunk production-correlation design. For alert mode, do not run this as one broad raw search across high-volume indexes. Build staged candidate datasets first, then correlate those staged records over bounded windows.

The staged datasets should be generated as scheduled searches, summary indexes, accelerated data models, or other locally approved Splunk acceleration mechanisms. The final correlation search should only operate over the staged candidate records.

The implementation must preserve the Stage 1 extracted staging_bucket and require Cloud Storage follow-on activity from Stage 2 to match that same bucket. Do not correlate a Vertex AI upload involving one unapproved bucket with unrelated Cloud Storage activity against a different unapproved bucket in the same project.

PRODUCTION DESIGN:

Vertex AI Model Upload to Unapproved Staging Bucket With Same-Bucket Storage Artifact or Endpoint Follow-On

STAGE 1:

Create staged candidate dataset:

vertex_ai_unapproved_upload_candidates

SOURCE:

GCP audit logs / Vertex AI audit logs

LOGIC:

service_name = "aiplatform.googleapis.com"

AND method_name contains one of:

  - "UploadModel"

  - "CreateModel"

  - "ImportModel"

  - "DeployModel"

AND artifact_uri starts with "gs://"

AND staging_bucket extracted from artifact_uri

AND staging_bucket not in APPROVED_VERTEX_STAGING_BUCKETS

REQUIRED OUTPUT FIELDS:

_time

gcp_project_id

region

principal_email

caller_ip

method_name

model_id

endpoint_id

artifact_uri

staging_bucket

artifact_path

service_account

ci_job_id where available

signal = "unapproved_vertex_staging_bucket"

STAGE 2:

Create staged candidate dataset:

vertex_ai_unapproved_storage_activity_candidates

SOURCE:

Cloud Storage Data Access logs / Cloud Storage Admin Activity logs

LOGIC:

service_name = "storage.googleapis.com"

AND method_name contains one of:

  - "storage.objects.create"

  - "storage.objects.update"

  - "storage.objects.delete"

  - "storage.objects.get"

  - "storage.objects.rewrite"

  - "storage.buckets.setIamPolicy"

AND bucket_name not in APPROVED_VERTEX_STAGING_BUCKETS

REQUIRED OUTPUT FIELDS:

_time

gcp_project_id

principal_email

caller_ip

method_name

bucket_name

object_name

object_hash

service_account where available

signal = "unapproved_bucket_storage_activity"

STAGE 3:

Create staged candidate dataset:

vertex_ai_sdk_exposure_candidates

SOURCE:

CI/CD logs, dependency inventory, notebook dependency exports, endpoint package inventory, or SCA/SBOM records

LOGIC:

package_name = "google-cloud-aiplatform"

AND package_version_status in:

  - "affected"

  - "unvalidated"

package_version_status must be a local enrichment field. Do not treat it as a native Splunk field.

REQUIRED OUTPUT FIELDS:

_time

ci_job_id

repo

commit_sha

actor

package_name

package_version

package_version_status

gcp_project_id

service_account where available

host where available

model_id where available

endpoint_id where available

signal = "affected_or_unvalidated_vertex_sdk_usage"

STAGE 4:

Create staged candidate dataset:

vertex_ai_endpoint_suspicious_behavior_candidates

SOURCE:

Endpoint logs, EDR logs, developer workstation logs, notebook host logs, CI/CD runner logs, or model-serving host logs

LOGIC:

host in VERTEX_AI_WORKFLOW_HOSTS

AND (

  command_line contains one of:

    - "pickle.load"

    - "joblib.load"

    - "cloudpickle"

    - "metadata.google.internal"

    - "GOOGLE_APPLICATION_CREDENTIALS"

    - "secretmanager.googleapis.com"

    - "storage.googleapis.com"

  OR process_name in:

    - "sh"

    - "bash"

    - "curl"

    - "wget"

    - "python"

    - "python3"

)

AND command_line not in APPROVED_VERTEX_COMMAND_PATTERNS

REQUIRED OUTPUT FIELDS:

_time

host

user

process_name

parent_process_name

command_line

dest_domain

dest_ip

gcp_project_id

service_account where available

ci_job_id where available

model_id where available

endpoint_id where available

signal = "possible_unsafe_model_load_or_credential_access"

FINAL CORRELATION SEARCH:

Search only staged candidate datasets:

  - vertex_ai_unapproved_upload_candidates

  - vertex_ai_unapproved_storage_activity_candidates

  - vertex_ai_sdk_exposure_candidates

  - vertex_ai_endpoint_suspicious_behavior_candidates

CORRELATION WINDOW:

120 minutes

REQUIRED PRIMARY SIGNAL:

signal = "unapproved_vertex_staging_bucket"

REQUIRED FOLLOW-ON SIGNAL:

At least one of:

  - signal = "unapproved_bucket_storage_activity" with Stage 2 bucket_name equal to Stage 1 staging_bucket

  - signal = "affected_or_unvalidated_vertex_sdk_usage" joined to Stage 1 by at least one reliable local key

  - signal = "possible_unsafe_model_load_or_credential_access" joined to Stage 1 by at least one reliable local key

SAME-BUCKET REQUIREMENT:

For Cloud Storage follow-on activity, Stage 2 bucket_name must equal Stage 1 staging_bucket.

Do not correlate the Stage 1 upload candidate to storage activity involving a different unapproved bucket, even when the project and time window match.

RELIABLE JOIN KEYS FOR SDK AND ENDPOINT FOLLOW-ON:

For SDK exposure and endpoint-side behavior, require at least one reliable local join key in addition to the 120-minute window:

  - gcp_project_id

  - ci_job_id

  - service_account

  - host

  - repo and commit_sha

  - model_id

  - endpoint_id

  - artifact_uri

  - approved build or deployment workflow identifier

Treat SDK exposure or endpoint-side behavior without a reliable local join key as investigation context, not high-confidence follow-on evidence.

CORRELATION KEYS:

gcp_project_id

Stage 1 staging_bucket matched to Stage 2 bucket_name

principal_email

service_account

model_id

endpoint_id

ci_job_id

host

repo

commit_sha

artifact_uri

SEVERITY:

medium when unapproved Vertex AI staging bucket use is present with sufficient cloud-audit context and either affected or unvalidated SDK exposure or weak but relevant follow-on context.

high when unapproved staging bucket use is followed within 120 minutes by same-bucket Cloud Storage object activity, same-bucket bucket IAM change, endpoint deployment, model artifact hash drift, or unusual service-account activity.

critical only when suspicious staging activity is correlated with unsafe model-load behavior, credential access, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, confirmed model poisoning evidence, model theft evidence, or confirmed malicious artifact evidence.

SUPPRESSION:

suppress when maintenance_window = true

suppress when staging_bucket in APPROVED_VERTEX_STAGING_BUCKETS

suppress when service_account in APPROVED_VERTEX_SERVICE_ACCOUNTS and activity matches approved release workflow

suppress when ci_job_id in APPROVED_VERTEX_CICD_RUNNERS and build_id has approved deployment record

suppress when command_line in APPROVED_VERTEX_COMMAND_PATTERNS

suppress when dest_domain in APPROVED_VERTEX_EGRESS_DESTINATIONS

OUTPUT:

first_seen

last_seen

severity

signals

gcp_project_id

region

principal_email

service_account

caller_ip

method_name

model_id

endpoint_id

artifact_uri

staging_bucket

bucket_name

object_name

object_hash

ci_job_id

repo

commit_sha

package_version

package_version_status

host

user

process_name

command_line

dest_domain

dest_ip

correlation_reason

Elastic

Detection Viability Assessment

Production-deployable after local ECS, custom GCP field, transform, value-list, exception-list, and join-key validation where Elastic ingests GCP audit logs, Cloud Storage Data Access logs, Vertex AI audit logs, CI/CD logs, endpoint logs, DNS/proxy logs, and dependency inventory.

Rule

Vertex AI Unapproved Staging Bucket Upload Sequence With Storage or SDK Follow-On

Rule Format

Elastic EQL / KQL detection pattern requiring local GCP field mapping, transforms, value lists, enrichment policies, and exception lists.

Detection Purpose

Detect Vertex AI model upload activity involving unapproved staging buckets followed by Cloud Storage object activity, bucket administration, endpoint deployment, affected or unvalidated SDK usage, endpoint-side execution behavior, or model artifact drift.

Detection Logic

Trigger when a Vertex AI model upload, model creation, model import, or model deployment event references a Cloud Storage artifact URI whose extracted staging bucket is not in the approved Vertex AI staging bucket inventory.

Assign medium severity when the primary Vertex AI event references an unapproved staging bucket and the event is supported by sufficient GCP audit context, but no stronger follow-on behavior has been observed.

Assign high severity only when the primary Vertex AI event is followed within 120 minutes by one or more corroborating signals tied to the same workflow. Corroborating signals may include Cloud Storage object activity against the same extracted staging bucket, bucket IAM changes against the same extracted staging bucket, endpoint deployment, affected or unvalidated google-cloud-aiplatform SDK usage, model artifact hash drift, unusual service-account activity, or scoped endpoint-side suspicious behavior.

For Cloud Storage follow-on activity, require same-bucket correlation. The follow-on Cloud Storage bucket must match the staging bucket extracted from the primary Vertex AI artifact URI. Do not correlate the primary Vertex AI event to Cloud Storage activity involving a different unapproved bucket, even when the project and time window match.

For SDK exposure, CI/CD, dependency, endpoint-side, or process behavior, require at least one reliable local join key in addition to the 120-minute window, such as cloud.project.id, ci.job.id, build.id, deployment.workflow.id, service_account, host.name, repository plus commit SHA, gcp.vertex.model.id, gcp.vertex.endpoint.id, gcp.vertex.artifact_uri, or an approved build or deployment workflow identifier.

Treat affected or unvalidated SDK usage, endpoint-side behavior, rare egress, or process activity without a reliable local join key as investigation context, not high-confidence follow-on evidence.

Promote to critical only when correlated activity includes unsafe model-load execution, credential access, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, confirmed model artifact tampering, model poisoning evidence, model theft evidence, or confirmed malicious serialized artifact evidence.

Do not treat one unapproved bucket, one model upload event, one SDK-version finding, one endpoint event, or one process event as confirmed Vertex AI staging-bucket abuse without same-bucket, workflow, artifact, service-account, model, endpoint, or reliable time-window correlation.

Required Telemetry

GCP audit logs.

Cloud Storage Data Access logs.

Vertex AI audit logs.

CI/CD logs.

Dependency inventory.

Endpoint telemetry where available.

DNS/proxy logs where available.

Elastic value list for approved Vertex AI projects.

Elastic value list for approved staging buckets.

Elastic value list for approved service accounts.

Elastic value list for approved CI/CD runners.

Elastic value list for approved egress destinations.

Elastic exception list for approved release windows.

Engineering Implementation Instructions

Map event.dataset, event.kind, cloud.project.id, cloud.region, gcp.audit.method_name, gcp.audit.service_name, user.email, source.ip, gcp.storage.bucket.name, gcp.storage.object.name, gcp.vertex.model.id, gcp.vertex.endpoint.id, gcp.vertex.artifact_uri, vertex.staging_bucket, package.name, package.version, package.version_status, ci.job.id, build.id, deployment.workflow.id, service_account, repository, commit_sha, host.name, process.name, process.parent.name, process.command_line, file.path, destination.domain, destination.ip, event.action, and @timestamp.

Create Elastic value lists, exception lists, enrich policies, or normalized boolean fields for approved Vertex AI projects, approved staging buckets, approved service accounts, approved CI/CD users, approved endpoints, approved model artifact hashes, approved maintenance windows, approved command patterns, approved egress destinations, and Vertex AI workflow hosts.

Use transforms, enrich processors, ingest pipelines, entity-centric indexing, alert pipelines, or downstream SIEM correlation logic to extract vertex.staging_bucket from gcp.vertex.artifact_uri on Vertex AI model upload, model creation, model import, and model deployment events.

Populate vertex.staging_bucket on Cloud Storage follow-on events only after validating that gcp.storage.bucket.name matches the primary Vertex AI event’s extracted staging bucket. Do not rely on raw EQL field-to-field comparison to enforce same-bucket matching.

Populate vertex.workflow_join.reliable only when dependency, CI/CD, endpoint-side, or process events are tied to the primary Vertex AI workflow by at least one reliable local join key, such as cloud.project.id, ci.job.id, build.id, deployment.workflow.id, service_account, host.name, repository plus commit SHA, gcp.vertex.model.id, gcp.vertex.endpoint.id, or gcp.vertex.artifact_uri.

Create package.version_status as a local enrichment field from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint software inventory, or dependency inventory. Do not treat package.version_status as a native Elastic field.

Do not treat $APPROVED_* placeholder names as copy/paste Elastic EQL syntax. Implement approved-bucket, approved-service-account, approved-command, approved-host, approved-project, approved-egress, and maintenance-window logic through Elastic value lists, exception lists, enrich fields, normalized booleans, alert suppression, or downstream detection workflow logic.

If Elastic cannot express package-version comparison, bucket ownership, workflow-join reliability, command approval, host approval, or maintenance-window logic directly in EQL, implement those controls through transforms, enrich processors, entity-centric indexing, exception lists, value lists, alert suppression, or downstream SIEM correlation logic before promoting the rule to alert mode.

Validate GCP log mappings, Vertex AI method names, artifact URI parsing, vertex.staging_bucket extraction, same-bucket storage validation, storage object field mappings, endpoint mappings, package.version_status, vertex.workflow_join.reliable, approved-list logic, exception-list behavior, and EQL sequence grouping before alert-mode deployment.

Run the Elastic rule in hunt mode first to baseline approved Vertex AI uploads, approved staging bucket use, normal ML experimentation, normal CI/CD model release behavior, endpoint deployments, notebook activity, process behavior, and approved maintenance workflows.

Treat ECS mapping, value-list creation, exception-list creation, transform configuration, enrich policy output, entity-centric correlation, artifact URI parsing, same-bucket validation, package-version enrichment, reliable join-key validation, EQL sequence testing, alert suppression, and SOC triage routing as required local deployment work.

DRI Assessment

High where Elastic has reliable GCP audit, storage, CI/CD, endpoint, DNS/proxy, and model metadata joins.

DRI

8.7 / 10

TCR Assessment

Strong when unapproved staging bucket use is paired with object activity, bucket admin changes, SDK exposure, endpoint deployment, endpoint-side execution evidence, or model artifact drift.

Operational TCR

8.2 / 10

Full-Telemetry TCR

9.2 / 10

Limitations

Elastic detection quality depends on GCP field mapping, artifact URI extraction, Data Access logging, local value lists, and local enrichment fields. Model poisoning may require model validation telemetry. Critical promotion requires stronger evidence than one unapproved bucket or one model upload event.

Detection Query Pattern

Use the following as an Elastic transform-and-enrichment-dependent EQL / correlation pattern. Do not deploy this as a raw EQL rule until local ingest pipelines, transforms, enrich processors, ECS mappings, value lists, exception lists, entity correlation keys, and join-key handling have been validated.

This pattern assumes local fields such as vertex.staging_bucket, gcp.vertex.artifact_uri, package.version_status, and vertex.workflow_join.reliable have already been created through ingest parsing, transforms, enrichment policy output, entity-centric indexing, or local normalization. These are not guaranteed native Elastic or ECS fields.

The implementation must preserve the primary event’s extracted vertex.staging_bucket and correlate follow-on Cloud Storage activity to the same bucket. Do not correlate the primary Vertex AI upload event to unrelated Cloud Storage activity against a different bucket in the same project.

The EQL example below is valid only where the Elastic implementation populates vertex.staging_bucket consistently on all participating events before the rule runs. For the primary Vertex AI event, vertex.staging_bucket must be extracted from the gs:// artifact URI. For follow-on Cloud Storage events, vertex.staging_bucket must be populated from the same bucket value only after local preprocessing validates that the storage event belongs to the same primary workflow bucket. For dependency and endpoint-side events, vertex.staging_bucket must be populated only when a reliable workflow join connects the event to the primary Vertex AI upload sequence.

PRODUCTION DESIGN:

Vertex AI Unapproved Staging Bucket Upload Sequence With Same-Bucket Storage or SDK Follow-On

REQUIRED LOCAL TRANSFORMS AND ENRICHMENT:

Extract vertex.staging_bucket from gcp.vertex.artifact_uri on Vertex AI model upload, model creation, model import, and model deployment events.

Map Cloud Storage bucket ownership to approved project and approved staging status.

Populate vertex.staging_bucket on Cloud Storage follow-on events only when the storage bucket matches the primary Vertex AI event’s extracted staging bucket through a validated transform, enrich policy, entity-centric index, alert pipeline, or SIEM correlation layer.

Map package.version_status from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint software inventory, or dependency inventory.

Map Vertex AI workflow hosts into VERTEX_AI_WORKFLOW_HOSTS.

Populate vertex.workflow_join.reliable only when a dependency, CI/CD, endpoint-side, or process event is tied to the primary Vertex AI workflow by at least one reliable local join key, such as cloud.project.id, ci.job.id, service_account, host.name, repository plus commit SHA, gcp.vertex.model.id, gcp.vertex.endpoint.id, gcp.vertex.artifact_uri, or an approved build or deployment workflow identifier.

Load approved staging buckets, approved Vertex AI projects, approved service accounts, approved command patterns, approved egress destinations, and approved maintenance windows into Elastic value lists, enrich policies, transforms, or exception lists.

Validate that follow-on storage activity is matched to the same staging bucket extracted from the primary Vertex AI event, not merely to any unapproved bucket in the same project.

PRIMARY SEQUENCE EVENT:

event.dataset in:

·        "ENV_GCP_AUDIT_DATASET"

gcp.audit.service_name = "aiplatform.googleapis.com"

gcp.audit.method_name contains one of:

·        "UploadModel"

·        "CreateModel"

·        "ImportModel"

·        "DeployModel"

gcp.vertex.artifact_uri starts with "gs://"

vertex.staging_bucket extracted from gcp.vertex.artifact_uri

vertex.staging_bucket not in APPROVED_VERTEX_STAGING_BUCKETS

cloud.project.id in APPROVED_VERTEX_PROJECTS

FOLLOW-ON EVENT WITHIN 120 MINUTES:

event.dataset in:

·        "ENV_GCP_STORAGE_DATASET"

gcp.audit.service_name = "storage.googleapis.com"

vertex.staging_bucket populated from same-bucket validated Cloud Storage activity

gcp.audit.method_name contains one of:

·        "storage.objects.create"

·        "storage.objects.update"

·        "storage.objects.delete"

·        "storage.objects.get"

·        "storage.objects.rewrite"

·        "storage.buckets.setIamPolicy"

OR

event.dataset in:

·        "ENV_CICD_DATASET"

·        "ENV_DEPENDENCY_DATASET"

package.name = "google-cloud-aiplatform"

package.version_status in:

·        "affected"

·        "unvalidated"

vertex.workflow_join.reliable = true

vertex.staging_bucket populated from the primary Vertex AI workflow after reliable join validation

OR

event.category = "process"

host.name in VERTEX_AI_WORKFLOW_HOSTS

vertex.workflow_join.reliable = true

vertex.staging_bucket populated from the primary Vertex AI workflow after reliable join validation

AND one of the following is true:

process.command_line contains one of:

·        "pickle.load"

·        "joblib.load"

·        "cloudpickle"

·        "metadata.google.internal"

·        "GOOGLE_APPLICATION_CREDENTIALS"

·        "secretmanager.googleapis.com"

·        "storage.googleapis.com"

OR

process.name in:

·        "sh"

·        "bash"

·        "curl"

·        "wget"

AND process.parent.name in:

·        "python"

·        "python3"

·        "jupyter"

·        "ipykernel"

·        "gcloud"

·        "gsutil"

AND either process.command_line is empty or process.command_line is not in APPROVED_VERTEX_COMMAND_PATTERNS.

CORRELATION WINDOW:

120 minutes

CORRELATION KEYS:

cloud.project.id

vertex.staging_bucket

user.email

service_account

gcp.vertex.model.id

gcp.vertex.endpoint.id

ci.job.id

host.name

repository plus commit SHA where available

approved build or deployment workflow identifier

SUPPRESSION:

suppress when event.action in:

·        "approved_vertex_model_release"

·        "approved_vertex_model_rebuild"

·        "approved_vertex_sdk_validation"

suppress when vertex.staging_bucket in APPROVED_VERTEX_STAGING_BUCKETS

suppress when user.email in APPROVED_VERTEX_SERVICE_ACCOUNTS and activity matches approved release workflow

suppress when ci.job.id in APPROVED_VERTEX_CICD_RUNNERS and build_id has approved deployment record

suppress when process.command_line in APPROVED_VERTEX_COMMAND_PATTERNS

suppress when destination.domain in APPROVED_VERTEX_EGRESS_DESTINATIONS

suppress when maintenance_window = true

SEVERITY:

medium when the primary Vertex AI unapproved staging bucket event is present with affected or unvalidated SDK exposure joined through a reliable local key but no stronger follow-on behavior.

high when the primary event is followed within 120 minutes by Cloud Storage object activity against the same extracted staging bucket, bucket IAM change, endpoint deployment, model artifact hash drift, unusual service-account activity, or scoped endpoint-side suspicious behavior joined through a reliable local key.

critical only when correlated activity includes unsafe model-load execution, credential access, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, confirmed model poisoning evidence, model theft evidence, or confirmed malicious artifact evidence.

OUTPUT:

first_seen

last_seen

severity

cloud.project.id

cloud.region

user.email

source.ip

gcp.audit.method_name

gcp.vertex.model.id

gcp.vertex.endpoint.id

gcp.vertex.artifact_uri

vertex.staging_bucket

gcp.storage.bucket.name

gcp.storage.object.name

package.version

package.version_status

ci.job.id

host.name

process.name

process.parent.name

process.command_line

destination.domain

destination.ip

correlation_reason

Equivalent Elastic EQL or correlation implementation should be built only after the local transforms and enrichments above are validated. The EQL example below assumes vertex.staging_bucket has already been normalized onto all participating events and that same-bucket validation has already occurred before the rule runs. Do not use this EQL example if the local implementation expects EQL itself to compare the primary Vertex AI bucket field to the follow-on Cloud Storage bucket field.

sequence by cloud.project.id, vertex.staging_bucket with maxspan=120m

[ any where

  event.kind == "event" and

  event.dataset == "ENV_GCP_AUDIT_DATASET" and

  gcp.audit.service_name == "aiplatform.googleapis.com" and

  (

    gcp.audit.method_name like "*UploadModel*" or

    gcp.audit.method_name like "*CreateModel*" or

    gcp.audit.method_name like "*ImportModel*" or

    gcp.audit.method_name like "*DeployModel*"

  ) and

  gcp.vertex.artifact_uri like "gs://*" and

  vertex.staging_bucket != null and

  not vertex.staging_bucket in $APPROVED_VERTEX_STAGING_BUCKETS and

  cloud.project.id in $APPROVED_VERTEX_PROJECTS

]

[ any where

  event.kind == "event" and

  vertex.staging_bucket != null and

  (

    (

      event.dataset == "ENV_GCP_STORAGE_DATASET" and

      gcp.audit.service_name == "storage.googleapis.com" and

      (

        gcp.audit.method_name like "*storage.objects.create*" or

        gcp.audit.method_name like "*storage.objects.update*" or

        gcp.audit.method_name like "*storage.objects.delete*" or

        gcp.audit.method_name like "*storage.objects.get*" or

        gcp.audit.method_name like "*storage.objects.rewrite*" or

        gcp.audit.method_name like "*storage.buckets.setIamPolicy*"

      )

    )

    or

    (

      event.dataset in ("ENV_CICD_DATASET", "ENV_DEPENDENCY_DATASET") and

      package.name == "google-cloud-aiplatform" and

      package.version_status in ("affected", "unvalidated") and

      vertex.workflow_join.reliable == true

    )

    or

    (

      event.category == "process" and

      host.name in $VERTEX_AI_WORKFLOW_HOSTS and

      vertex.workflow_join.reliable == true and

      (

        (

          process.command_line != null and

          (

            process.command_line like "*pickle.load*" or

            process.command_line like "*joblib.load*" or

            process.command_line like "*cloudpickle*" or

            process.command_line like "*metadata.google.internal*" or

            process.command_line like "*GOOGLE_APPLICATION_CREDENTIALS*" or

            process.command_line like "*secretmanager.googleapis.com*" or

            process.command_line like "*storage.googleapis.com*"

          ) and

          not process.command_line in $APPROVED_VERTEX_COMMAND_PATTERNS

        )

        or

        (

          process.name in ("sh", "bash", "curl", "wget") and

          process.parent.name in ("python", "python3", "jupyter", "ipykernel", "gcloud", "gsutil") and

          (

            process.command_line == null or

            not process.command_line in $APPROVED_VERTEX_COMMAND_PATTERNS

          )

        )

      )

    )

  )

]

until

[ any where

  event.kind == "event" and

  event.dataset == "ENV_CHANGE_CONTROL_DATASET" and

  event.action in (

    "approved_vertex_model_release",

    "approved_vertex_model_rebuild",

    "approved_vertex_sdk_validation"

  )

]

If the local Elastic implementation cannot populate vertex.staging_bucket on storage, dependency, or endpoint-side events through validated preprocessing, use the production-design model rather than the EQL example. In that case, correlate through an entity-centric transform, enrich policy, or alert pipeline that explicitly carries the primary staging bucket forward as the join key and enforces same-bucket matching before detection promotion.

QRadar

Detection Viability Assessment

Production-deployable where QRadar parses GCP audit, Cloud Storage, Vertex AI, CI/CD, dependency, endpoint, DNS/proxy, and IAM events into reliable custom properties. Implement as building blocks with an offense rule. The AQL patterns below are validation searches for building-block logic, not standalone production alerts.

Rule

Vertex AI Staging Bucket Hijack Exposure Offense

Rule Format

QRadar building-block and offense-rule implementation pattern with AQL validation searches.

Detection Purpose

Correlate Vertex AI model upload activity using unapproved staging buckets with Cloud Storage object manipulation, bucket administration, affected or unvalidated SDK usage, endpoint deployment, endpoint-side execution behavior, or service-account activity.

Detection Logic

Trigger building block one when Vertex AI model upload, create, import, or deploy activity references an unapproved Cloud Storage staging bucket extracted from the Vertex AI artifact URI.

Trigger building block two when Cloud Storage object or bucket administration activity occurs against an unapproved bucket.

Trigger building block three when CI/CD or dependency telemetry shows affected or unvalidated google-cloud-aiplatform SDK usage.

Trigger building block four when endpoint or workload telemetry shows suspicious model-loading, credential access, metadata access, transfer tooling, or shell execution behavior on Vertex AI workflow hosts.

Create an offense when building block one and at least one of building block two, building block three, or building block four occur within 120 minutes outside approved maintenance.

For building block two, require same-bucket correlation. Building block two BUCKETNAME must equal building block one STAGINGBUCKET.

For building blocks three and four, require at least one reliable local join key in addition to the 120-minute window, such as GCPPROJECT, CIJOBID, SERVICEACCOUNT, MODELID, ENDPOINTID, HOSTNAME, or an approved build or deployment workflow identifier.

Treat affected SDK usage or endpoint-side behavior without a reliable local join key as investigation context, not high-confidence follow-on evidence.

Promote to critical only when service-account access to secrets, BigQuery, Artifact Registry, IAM, production storage, endpoint traffic shifts, model hash mismatch, unsafe model-load behavior, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence occurs within 120 minutes and is tied back through a reliable local join key.

Required Telemetry

GCP audit logs.

Cloud Storage Data Access logs.

Vertex AI audit logs.

CI/CD logs.

Dependency inventory.

Endpoint telemetry where available.

DNS/proxy logs where available.

IAM policy logs.

Model provenance records where available.

Approved Vertex AI project reference set.

Approved staging bucket reference set.

Approved service-account reference set.

Approved CI/CD runner reference set.

Approved endpoint reference set.

Approved command-pattern reference set.

Approved maintenance-window reference set.

Engineering Implementation Instructions

Create custom properties for GCPPROJECT, REGION, PRINCIPALEMAIL, CALLERIP, SERVICENAME, METHODNAME, BUCKETNAME, OBJECTNAME, ARTIFACTURI, MODELID, ENDPOINTID, SERVICEACCOUNT, CIJOBID, PACKAGEVERSION, PACKAGEVERSIONSTATUS, OBJECTHASH, HOSTNAME, PROCESSNAME, COMMANDLINE, DESTINATIONDOMAIN, DESTINATIONIP, and EVENTTIME.

Create reference sets for approved Vertex AI projects, approved staging buckets, approved service accounts, approved CI/CD runners, approved model hashes, approved endpoints, approved maintenance windows, approved egress destinations, approved command patterns, and affected or unvalidated SDK versions.

Create PACKAGEVERSIONSTATUS as a local custom property or enrichment value from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint software inventory, or dependency inventory. Do not treat PACKAGEVERSIONSTATUS as a native QRadar property.

Validate DSM parsing and custom properties for each GCP, CI/CD, dependency, endpoint, and proxy log source before enabling offense correlation.

Test each building block independently with historical data.

Treat DSM parsing, custom property creation, reference-set loading, package-version enrichment, building-block validation, offense magnitude, ownership routing, and suppression workflow as required local deployment work.

DRI Assessment

Moderate to high where QRadar custom properties, reference sets, and building-block joins are reliable.

DRI

8.3 / 10

TCR Assessment

Strong when Vertex AI upload events, storage activity, dependency exposure, endpoint behavior, and endpoint changes can be joined by project, bucket, model, service account, host, or bounded time window.

Operational TCR

8.0 / 10

Full-Telemetry TCR

9.1 / 10

Limitations

QRadar effectiveness depends on DSM parsing quality, custom property accuracy, Data Access logging, local enrichment, and reference-set hygiene. Weak artifact URI parsing or missing Cloud Storage Data Access logs materially reduce confidence. Critical severity requires stronger evidence than one unapproved bucket or one model upload event.

Detection Query Pattern

Use the following AQL as QRadar building-block validation logic. Production alerting should use QRadar building blocks, reference sets, custom properties, and offense correlation, not a single raw AQL search.

Validate the exact AQL syntax, DSM parsing, custom-property names, reference-set names, and offense-rule behavior in the customer deployment before enabling alert mode.

This implementation requires a locally parsed custom property named STAGINGBUCKET, extracted from ARTIFACTURI on Vertex AI model upload, model creation, model import, or model deployment events. Do not use BUCKETNAME for the primary Vertex AI event unless the customer has already mapped it to the bucket extracted from ARTIFACTURI.

REQUIRED QRADAR CUSTOM PROPERTIES:

GCPPROJECT

REGION

PRINCIPALEMAIL

CALLERIP

SERVICENAME

METHODNAME

ARTIFACTURI

STAGINGBUCKET

BUCKETNAME

OBJECTNAME

OBJECTHASH

MODELID

ENDPOINTID

SERVICEACCOUNT

CIJOBID

PACKAGENAME

PACKAGEVERSION

PACKAGEVERSIONSTATUS

HOSTNAME

PROCESSNAME

COMMANDLINE

DESTINATIONDOMAIN

DESTINATIONIP

EVENTTIME

BUILDING BLOCK ONE VALIDATION SEARCH:

Vertex AI model upload, model creation, model import, or model deployment referencing an unapproved staging bucket.

SELECT QIDNAME(qid) AS event_name, GCPPROJECT, REGION, PRINCIPALEMAIL,

CALLERIP, SERVICENAME, METHODNAME, ARTIFACTURI, STAGINGBUCKET, MODELID,

ENDPOINTID, SERVICEACCOUNT, CIJOBID, starttime

FROM events

WHERE SERVICENAME = 'aiplatform.googleapis.com'

AND (

  METHODNAME ILIKE '%UploadModel%'

  OR METHODNAME ILIKE '%CreateModel%'

  OR METHODNAME ILIKE '%ImportModel%'

  OR METHODNAME ILIKE '%DeployModel%'

)

AND ARTIFACTURI ILIKE 'gs://%'

AND STAGINGBUCKET IS NOT NULL

AND NOT REFERENCESETCONTAINS('ENV_APPROVED_VERTEX_STAGING_BUCKETS', STAGINGBUCKET)

LAST 120 MINUTES

BUILDING BLOCK TWO VALIDATION SEARCH:

Cloud Storage object or bucket-policy activity against an unapproved bucket.

SELECT QIDNAME(qid) AS event_name, GCPPROJECT, PRINCIPALEMAIL, CALLERIP,

SERVICENAME, METHODNAME, BUCKETNAME, OBJECTNAME, OBJECTHASH, SERVICEACCOUNT,

starttime

FROM events

WHERE SERVICENAME = 'storage.googleapis.com'

AND (

  METHODNAME ILIKE '%storage.objects.create%'

  OR METHODNAME ILIKE '%storage.objects.update%'

  OR METHODNAME ILIKE '%storage.objects.delete%'

  OR METHODNAME ILIKE '%storage.objects.get%'

  OR METHODNAME ILIKE '%storage.objects.rewrite%'

  OR METHODNAME ILIKE '%storage.buckets.setIamPolicy%'

)

AND BUCKETNAME IS NOT NULL

AND NOT REFERENCESETCONTAINS('ENV_APPROVED_VERTEX_STAGING_BUCKETS', BUCKETNAME)

LAST 120 MINUTES

BUILDING BLOCK THREE VALIDATION SEARCH:

Affected or unvalidated Vertex AI SDK usage from dependency inventory, CI/CD telemetry, notebook dependency exports, endpoint package inventory, or SCA/SBOM records.

SELECT QIDNAME(qid) AS event_name, CIJOBID, PRINCIPALEMAIL, SERVICEACCOUNT,

PACKAGENAME, PACKAGEVERSION, PACKAGEVERSIONSTATUS, GCPPROJECT, MODELID,

ENDPOINTID, HOSTNAME, starttime

FROM events

WHERE PACKAGENAME = 'google-cloud-aiplatform'

AND (

  REFERENCESETCONTAINS('ENV_AFFECTED_OR_UNVALIDATED_VERTEX_SDK_VERSIONS', PACKAGEVERSION)

  OR PACKAGEVERSIONSTATUS IN ('affected','unvalidated')

)

LAST 120 MINUTES

BUILDING BLOCK FOUR VALIDATION SEARCH:

Scoped ML workflow host behavior involving unsafe model loading, metadata access, credential access, transfer tooling, or suspicious child-process execution.

SELECT QIDNAME(qid) AS event_name, GCPPROJECT, HOSTNAME, SERVICEACCOUNT,

CIJOBID, MODELID, ENDPOINTID, PROCESSNAME, COMMANDLINE, DESTINATIONDOMAIN,

DESTINATIONIP, starttime

FROM events

WHERE REFERENCESETCONTAINS('ENV_VERTEX_AI_WORKFLOW_HOSTS', HOSTNAME)

AND (

  LOWER(COMMANDLINE) LIKE '%pickle.load%'

  OR LOWER(COMMANDLINE) LIKE '%joblib.load%'

  OR LOWER(COMMANDLINE) LIKE '%cloudpickle%'

  OR LOWER(COMMANDLINE) LIKE '%metadata.google.internal%'

  OR LOWER(COMMANDLINE) LIKE '%google_application_credentials%'

  OR LOWER(COMMANDLINE) LIKE '%secretmanager.googleapis.com%'

  OR LOWER(COMMANDLINE) LIKE '%storage.googleapis.com%'

  OR PROCESSNAME IN ('sh','bash','curl','wget','python','python3')

)

AND NOT REFERENCESETCONTAINS('ENV_APPROVED_VERTEX_COMMAND_PATTERNS', COMMANDLINE)

LAST 120 MINUTES

OFFENSE RULE CONDITION:

Create an offense when Building Block One occurs and at least one of Building Block Two, Building Block Three, or Building Block Four occurs within 120 minutes outside approved maintenance.

For Building Block Two, require same-bucket correlation:

Building Block Two BUCKETNAME must equal Building Block One STAGINGBUCKET.

Do not correlate Building Block One to Cloud Storage activity involving a different unapproved bucket, even when GCPPROJECT, PRINCIPALEMAIL, or the 120-minute window match.

For Building Block Three, require at least one reliable local join key in addition to the 120-minute window:

  - GCPPROJECT

  - CIJOBID

  - SERVICEACCOUNT

  - MODELID

  - ENDPOINTID

  - HOSTNAME

  - approved build or deployment workflow identifier

Treat affected or unvalidated SDK usage without a reliable local join key as investigation context, not high-confidence follow-on evidence.

For Building Block Four, require at least one reliable local join key in addition to the 120-minute window:

  - GCPPROJECT

  - SERVICEACCOUNT

  - HOSTNAME

  - CIJOBID

  - MODELID

  - ENDPOINTID

  - approved build or deployment workflow identifier

Treat endpoint-side behavior without a reliable local join key as investigation context, not high-confidence follow-on evidence.

APPROVED MAINTENANCE AND SUPPRESSION CONDITIONS:

Suppress or downgrade when activity occurs during approved maintenance.

Suppress or downgrade when STAGINGBUCKET is in ENV_APPROVED_VERTEX_STAGING_BUCKETS.

Suppress or downgrade when SERVICEACCOUNT is in ENV_APPROVED_VERTEX_SERVICE_ACCOUNTS and the activity matches an approved release workflow.

Suppress or downgrade when CIJOBID is in ENV_APPROVED_VERTEX_CICD_RUNNERS and the build has an approved deployment record.

Suppress or downgrade when COMMANDLINE is in ENV_APPROVED_VERTEX_COMMAND_PATTERNS.

Suppress or downgrade when DESTINATIONDOMAIN is in ENV_APPROVED_VERTEX_EGRESS_DESTINATIONS.

CRITICAL PROMOTION CONDITION:

Promote to critical only when one or more of the following occurs within 120 minutes of the offense and is tied back through a reliable local join key:

  - Secret Manager access

  - BigQuery access

  - Artifact Registry modification

  - IAM policy change

  - production endpoint deployment

  - endpoint traffic shift

  - model artifact hash mismatch

  - confirmed unsafe model-load behavior

  - confirmed malicious serialized artifact evidence

  - model theft evidence

  - model poisoning evidence

REQUIRED OFFENSE OUTPUT:

first_seen

last_seen

severity

event_name

GCPPROJECT

REGION

PRINCIPALEMAIL

SERVICEACCOUNT

CALLERIP

SERVICENAME

METHODNAME

ARTIFACTURI

STAGINGBUCKET

BUCKETNAME

OBJECTNAME

OBJECTHASH

MODELID

ENDPOINTID

CIJOBID

PACKAGENAME

PACKAGEVERSION

PACKAGEVERSIONSTATUS

HOSTNAME

PROCESSNAME

COMMANDLINE

DESTINATIONDOMAIN

DESTINATIONIP

correlation_reason

SIGMA

Detection Viability Assessment

Production-deployable after conversion and local enrichment where cloud audit telemetry is normalized into a SIEM backend that supports GCP audit logs. SIGMA is appropriate for portable event-rule templates around Vertex AI audit events and Cloud Storage artifact URI visibility. It should not be used to represent multi-event model hijack confirmation without SIEM-native correlation.

Rule

GCP Vertex AI Model Upload Referencing Cloud Storage Artifact URI

Rule Format

SIGMA cloud audit event-rule template requiring target-SIEM conversion, GCP field mapping, staging bucket enrichment, exception logic, and SIEM-native correlation-layer promotion.

Detection Purpose

Detect Vertex AI model upload, model creation, import, or deployment events that reference Cloud Storage artifact locations requiring approved-staging-bucket validation.

Detection Logic

Trigger when GCP audit telemetry shows Vertex AI model upload or related model registration activity referencing a gs:// artifact URI.

Assign medium severity for standalone converted rule matches when the extracted bucket is not approved.

Promote to high severity in the target SIEM only when correlated with Cloud Storage object manipulation, bucket IAM changes, affected or unvalidated SDK usage, endpoint deployment, model artifact hash drift, or service-account activity.

Promote to critical only in the target SIEM when model artifact tampering, unsafe model-load execution, sensitive service-account activity, production endpoint traffic shift, or confirmed malicious artifact evidence is observed.

Required Telemetry

GCP audit logs.

Vertex AI audit logs.

Cloud Storage Data Access logs for correlation-layer promotion.

Artifact URI field.

GCP project field.

Principal field.

Approved staging bucket enrichment.

Approved service-account enrichment.

Approved CI/CD enrichment.

Approved maintenance-window enrichment.

Engineering Implementation Instructions

Convert to the target SIEM.

Map service name, method name, principal email, project ID, caller IP, artifact URI, model ID, endpoint ID, bucket name, and timestamp.

Extract the bucket name from gs:// artifact URIs after conversion if the backend cannot do this inside SIGMA.

Add approved staging bucket enrichment after conversion.

Add approved service-account, approved CI/CD, approved model-hash, approved endpoint, and approved maintenance-window exceptions after conversion.

Do not deploy as high or critical severity without SIEM-native correlation to storage, endpoint, SDK, artifact, service-account, or runtime evidence.

Treat target-SIEM conversion, field mapping, host/project enrichment, exception logic, and correlation-layer promotion as required local deployment work.

DRI Assessment

Medium to high after conversion and GCP enrichment.

DRI

7.9 / 10

TCR Assessment

Good for portable event detection. Stronger when joined with Cloud Storage Data Access logs, CI/CD dependency inventory, model provenance, endpoint deployment telemetry, and service-account activity.

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.7 / 10

Limitations

SIGMA cannot reliably express bucket ownership verification, package-version comparison, artifact hash validation, maintenance windows, or multi-source model-hijack correlation by itself. Use it as an event-rule template only.

Detection Query Pattern

Use the following as a SIGMA event-rule template only. This rule identifies candidate GCP Vertex AI model upload, model creation, model import, or model deployment events that reference a Cloud Storage artifact URI. It does not prove staging-bucket abuse, model artifact tampering, cloud data access, or downstream compromise by itself.

Promotion beyond medium severity must happen in the target SIEM after backend conversion, local field mapping, approved-staging-bucket enrichment, staging-bucket extraction from artifact_uri, and SIEM-native correlation with Cloud Storage, dependency, identity, endpoint, or network evidence.

title: GCP Vertex AI Model Upload With Cloud Storage Artifact URI

id: 8c8e5b2f-04bd-4e7f-a2aa-6a5b1ce0d712

status: test

description: Detects GCP Vertex AI model upload, model creation, model import, or model deployment activity referencing a Cloud Storage artifact URI. This is a candidate event-rule template that requires local extraction of the staging bucket from artifact_uri and local approved-staging-bucket validation after backend conversion.

references:

  - https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/

author: CyberDax

date: 2026/06/18

logsource:

  product: gcp

  service: audit

detection:

  selection_vertex_service:

    service_name|contains: 'aiplatform.googleapis.com'

  selection_model_methods:

    method_name|contains:

      - 'UploadModel'

      - 'CreateModel'

      - 'ImportModel'

      - 'DeployModel'

  selection_artifact_uri:

    artifact_uri|contains: 'gs://'

  condition: selection_vertex_service and selection_model_methods and selection_artifact_uri

fields:

  - service_name

  - method_name

  - principal_email

  - project_id

  - caller_ip

  - artifact_uri

  - staging_bucket

  - model_id

  - endpoint_id

  - event_time

falsepositives:

  - Approved Vertex AI model uploads using approved Cloud Storage staging buckets

  - Approved ML experimentation

  - Approved notebook workflows

  - Approved CI/CD model releases

  - Approved incident response rebuilds

level: medium

LOCAL BACKEND REQUIREMENTS:
Extract staging_bucket from artifact_uri.
Compare extracted staging_bucket against approved Vertex AI staging buckets.
Map GCP audit fields to the target SIEM schema before deployment.
Validate field names after SIGMA backend conversion.
Add local suppression for approved ML workflows, approved CI/CD runners, approved service accounts, approved staging buckets, and approved maintenance windows.

CORRELATION REQUIREMENT:
Use SIEM-native correlation to promote this candidate event only when one or more of the following is observed within a bounded time window:

·        Cloud Storage object activity against the same extracted staging bucket

·        Cloud Storage bucket IAM change against the same extracted staging bucket

·        affected or unvalidated google-cloud-aiplatform SDK usage tied to the same workflow

·        model artifact hash mismatch

·        suspicious service-account activity

·        endpoint deployment or endpoint traffic shift

·        unsafe model-load behavior

·        credential access

·        confirmed malicious serialized artifact evidence

ATT&CK MAPPING NOTE:
Do not attach ATT&CK technique tags directly to this SIGMA event-rule template unless the target deployment enriches or correlates the event with downstream behavior that supports those techniques. The broader report may map downstream correlated behavior separately, but this standalone event rule only identifies candidate Vertex AI activity referencing a Cloud Storage artifact URI.

YARA

Detection Viability Assessment

Production-usable for artifact triage and model repository scanning. YARA should not be treated as primary detection for Vertex AI staging bucket abuse. It is viable for identifying suspicious pickle or model artifacts containing combinations of code execution, network retrieval, file access, cloud metadata access, credential access, or model-load abuse patterns.

Rule

Suspicious Serialized Model Artifact With Execution or Cloud Access Logic

Rule Format

YARA artifact-scanning rule for model artifacts, CI/CD build outputs, staging bucket exports, model registry exports, notebook artifacts, and forensic collections.

Detection Purpose

Detect suspicious serialized model artifacts that may execute commands, retrieve remote payloads, access cloud metadata, read credentials, or manipulate files during model load.

Detection Logic

Trigger when model artifacts contain combinations of pickle serialization markers, Python execution primitives, shell invocation, cloud metadata access, credential paths, remote retrieval, or file-management logic.

Assign medium severity for standalone matches.

Promote to high severity when the matched artifact is newly uploaded, located in an unapproved staging bucket, associated with suspicious Vertex AI model upload activity, has a hash mismatch, or was deployed to an endpoint.

Promote to critical only when the matched artifact is tied to unsafe model loading, endpoint execution behavior, credential access, service-account misuse, or confirmed production endpoint exposure.

Do not use this YARA rule as standalone proof of compromise. Treat it as an artifact-triage accelerator requiring bucket, object generation, hash, upload principal, model ID, endpoint ID, and deployment correlation.

Required Telemetry

Model artifact exports.

Staging bucket exports.

Model registry exports.

CI/CD build artifacts.

File hashes.

Object generation metadata.

Approved model artifact inventory.

Approved staging bucket inventory.

Approved model release records.

Forensic collection workflow.

Engineering Implementation Instructions

Use this rule in controlled scanning workflows and forensic triage, not as primary live exploit detection.

Scan pickle files, serialized Python model artifacts, joblib files, model archives, custom prediction routines, notebooks, exported staging bucket contents, and model registry exports.

Tune approved frameworks, known model formats, internal loaders, legitimate custom prediction routines, security tools, benign framework serialization artifacts, and approved model-validation test files before alerting.

Correlate YARA hits with Vertex AI audit logs, Cloud Storage Data Access logs, artifact hash drift, endpoint deployment, CI/CD logs, service-account activity, and model registry metadata.

Treat file collection, scanner integration, artifact format scoping, approved-model exceptions, hash review, owner validation, object-generation review, and triage routing as required local deployment work.

DRI Assessment

Moderate for artifact review and suspicious model triage. Low for live staging bucket abuse detection.

DRI

7.1 / 10

TCR Assessment

Useful when matched artifacts are newly created, unapproved, hash-mismatched, staged in suspicious buckets, or deployed to Vertex AI endpoints. Not sufficient as standalone proof of compromise.

Operational TCR

6.8 / 10

Full-Telemetry TCR

8.3 / 10

Limitations

YARA cannot reliably detect bucket squatting, model upload hijack, or runtime execution without recoverable artifacts. Legitimate ML artifacts may contain Python, pickle, network, file, or framework-loading functionality.

Detection Query Pattern

Use the following YARA rule for controlled artifact triage and retrospective model repository scanning. Correlate matches with cloud audit, Cloud Storage object activity, model registry events, endpoint activity, service-account behavior, staging-bucket validation, and model-hash evidence before escalation.

This rule should not be treated as proof of Vertex AI staging-bucket abuse by itself. It identifies serialized or model-adjacent artifacts that contain suspicious combinations of model serialization, execution, shell, credential, cloud metadata, Google Cloud API, or outbound access indicators.

rule Suspicious_Serialized_Model_Artifact_Execution_Cloud_Access

{

  meta:

    description = "Detects serialized ML artifacts or model-adjacent files with suspicious execution, shell, credential, Google Cloud metadata, or cloud API access indicators for Vertex AI model artifact triage."

    author = "CyberDax"

    date = "2026-06-18"

    scope = "Controlled artifact triage and retrospective model repository scanning"

    confidence = "Medium when found in model repositories; medium to high when correlated with unapproved staging bucket, Vertex AI upload, model hash drift, endpoint deployment, or service-account activity"

  strings:

    $serializer_1 = "pickle" ascii wide

    $serializer_2 = "__reduce__" ascii wide

    $serializer_3 = "__reduce_ex__" ascii wide

    $serializer_4 = "joblib" ascii wide

    $serializer_5 = "cloudpickle" ascii wide

    $serializer_6 = "torch.load" ascii wide

    $serializer_7 = "tensorflow" ascii wide

    $serializer_8 = "sklearn" ascii wide

    $pickle_opcode_1 = "cos\nsystem\n" ascii

    $pickle_opcode_2 = "posix\nsystem\n" ascii

    $pickle_opcode_3 = "subprocess\nPopen\n" ascii

    $pickle_opcode_4 = "builtins\neval\n" ascii

    $pickle_opcode_5 = "builtins\nexec\n" ascii

    $exec_1 = "os.system" ascii wide

    $exec_2 = "subprocess.Popen" ascii wide

    $exec_3 = "subprocess.call" ascii wide

    $exec_4 = "subprocess.run" ascii wide

    $exec_5 = "eval(" ascii wide

    $exec_6 = "exec(" ascii wide

    $exec_7 = "compile(" ascii wide

    $exec_8 = "__import__(" ascii wide

    $shell_1 = "/bin/sh" ascii wide

    $shell_2 = "/bin/bash" ascii wide

    $shell_3 = "bash -c" ascii wide

    $shell_4 = "sh -c" ascii wide

    $shell_5 = "cmd.exe" ascii wide

    $shell_6 = "powershell" ascii wide

    $net_1 = "urllib.request" ascii wide

    $net_2 = "requests.get" ascii wide

    $net_3 = "requests.post" ascii wide

    $net_4 = "socket.create_connection" ascii wide

    $net_5 = "http://" ascii wide

    $net_6 = "https://" ascii wide

    $cloud_1 = "metadata.google.internal" ascii wide

    $cloud_2 = "computeMetadata/v1" ascii wide

    $cloud_3 = "Metadata-Flavor: Google" ascii wide

    $cloud_4 = "secretmanager.googleapis.com" ascii wide

    $cloud_5 = "storage.googleapis.com" ascii wide

    $cloud_6 = "bigquery.googleapis.com" ascii wide

    $cloud_7 = "artifactregistry.googleapis.com" ascii wide

    $cloud_8 = "iam.googleapis.com" ascii wide

    $cred_1 = "GOOGLE_APPLICATION_CREDENTIALS" ascii wide

    $cred_2 = "service_account" ascii wide

    $cred_3 = "private_key" ascii wide

    $cred_4 = "client_email" ascii wide

    $cred_5 = "access_token" ascii wide

    $cred_6 = "refresh_token" ascii wide

  condition:

    filesize < 500MB and

    (

      (

        1 of ($serializer_*) and

        (

          1 of ($exec_*) or

          1 of ($shell_*) or

          1 of ($pickle_opcode_*) or

          (

            1 of ($cloud_*) and

            (

              1 of ($net_*) or

              1 of ($cred_*) or

              1 of ($exec_*) or

              1 of ($shell_*)

            )

          )

        )

      )

      or

      (

        1 of ($pickle_opcode_*) and

        (

          1 of ($cloud_*) or

          1 of ($cred_*) or

          1 of ($net_*)

        )

      )

    )

}

Correlation should promote severity only when a match is tied to one or more of the following:

·        Vertex AI model upload, model creation, model import, or endpoint deployment

·        unapproved or newly seen Cloud Storage staging bucket

·        Cloud Storage object write, overwrite, read, delete, rewrite, or bucket IAM change

·        model artifact hash mismatch

·        affected or unvalidated google-cloud-aiplatform SDK usage

·        suspicious service-account activity

·        Secret Manager, BigQuery, Artifact Registry, or IAM access

·        unsafe model-load behavior on a scoped ML workflow host

·        production endpoint deployment or endpoint traffic shift

·        confirmed malicious serialized artifact evidence

AWS

Detection Viability Assessment

Supporting-only. AWS telemetry is relevant only where AWS-hosted CI/CD, notebook, ML build, model validation, artifact handling, or deployment systems participate in the Vertex AI workflow. AWS does not directly observe GCP Vertex AI Model.upload behavior, GCP Cloud Storage bucket ownership, GCP model registry state, or GCP endpoint deployment state. Use this rule to identify AWS-side workflow exposure and supporting evidence, not to independently confirm the GCP staging-bucket abuse path.

Rule

AWS CI/CD or ML Build Workflow Vertex AI Upload Exposure With Cross-Cloud Artifact or Secret Activity

Rule Format

AWS CloudTrail / CloudWatch / VPC Flow / DNS / proxy / CI/CD / endpoint supporting-correlation pattern requiring cross-cloud workflow mapping, dependency enrichment, approved GCP destination baselining, and GCP-side corroboration.

Detection Purpose

Detect AWS-hosted CI/CD, notebook, or ML build systems that perform Vertex AI model-upload workflows and then show suspicious package exposure, artifact access, secret access, cross-cloud credential use, or unusual egress consistent with Vertex AI staging bucket abuse investigation.

Detection Logic

Trigger when AWS-hosted ML build, notebook, validation, artifact-handling, or CI/CD infrastructure shows affected or unvalidated google-cloud-aiplatform workflow exposure and can be correlated to GCP-side Vertex AI model upload, model creation, model import, model deployment, unapproved staging bucket use, same-bucket Cloud Storage activity, model artifact evidence, service-account activity, or endpoint deployment evidence.

Assign medium severity when AWS-hosted CI/CD or ML build workflow evidence is correlated with GCP-side Vertex AI upload activity through a reliable local join key and supporting AWS egress, GCP-related secret access, affected SDK usage, or artifact-handling context is present.

Assign high severity only when the AWS workflow is correlated with GCP-side Vertex AI upload activity and same-bucket Cloud Storage object activity, bucket IAM change, model artifact hash drift, unusual service-account activity, endpoint deployment, or GCP-related AWS secret access tied to the same build, runner, repository, workload, or service-account mapping.

Promote to critical only when GCP-corroborated activity includes confirmed unsafe model-load behavior, credential misuse, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, model artifact tampering, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence.

Do not promote AWS-only telemetry to high-confidence Vertex AI staging-bucket abuse without GCP-side Vertex AI, Cloud Storage, model artifact, service-account, or endpoint correlation.

Required Telemetry

AWS CloudTrail.

AWS VPC Flow Logs.

Route 53 Resolver logs where applicable.

AWS Secrets Manager audit logs.

AWS CodeBuild, CodePipeline, GitHub Actions, GitLab, Jenkins, or CI/CD logs.

Endpoint telemetry from AWS-hosted ML build systems.

Dependency inventory.

Approved AWS ML build host lookup.

Approved CI/CD workflow lookup.

Approved Google service-account credential lookup.

Approved GCP destination lookup.

Approved maintenance-window lookup.

GCP correlation feed where available.

Engineering Implementation Instructions

Map AWS account ID, region, principal ARN, role session, source IP, user agent, instance ID, CI/CD job ID, repository, commit SHA, package_name, package_version, package_version_status, destination domain, destination IP, secret name, artifact path, and timestamp.

Create local inventories for AWS-hosted Vertex AI workflow hosts, AWS-hosted Vertex AI CI/CD runners, approved GCP destinations, approved Google service-account credentials, approved Vertex AI release workflows, and approved maintenance windows.

Create package_version_status as local enrichment from SCA, SBOM, CI/CD package telemetry, endpoint package inventory, notebook dependency exports, or dependency inventory.

Correlate AWS-side findings with GCP-side Vertex AI model-upload events, Cloud Storage object activity, unapproved staging bucket findings, model artifact hash drift, endpoint deployment events, or service-account activity before raising confidence above supporting evidence.

Do not attribute AWS-only events to Vertex AI staging bucket abuse unless there is a workflow-level link to Vertex AI Model.upload, GCP Cloud Storage, Google service-account credentials, model artifacts, or GCP-side unapproved staging bucket activity.

Treat AWS-to-GCP workflow mapping, CI/CD log retention, package enrichment, secrets mapping, egress baselining, and cross-cloud correlation as required local deployment work.

DRI Assessment

Moderate where AWS-hosted CI/CD or ML build systems are part of the Vertex AI model upload path. Low where AWS has no role in ML build, upload, validation, or deployment workflows.

DRI

7.0 / 10

TCR Assessment

Moderate for cross-cloud workflow exposure. High only when AWS workflow evidence is correlated with GCP Vertex AI upload, Cloud Storage object activity, unapproved staging bucket use, or model artifact drift.

Operational TCR

6.7 / 10

Full-Telemetry TCR

8.1 / 10

Limitations

AWS cannot directly validate GCP bucket ownership, Vertex AI audit methods, GCP model registry state, GCP model artifact generation, or GCP endpoint deployment state. AWS telemetry is supporting evidence only unless AWS-hosted systems participate in the Vertex AI build, upload, validation, or deployment workflow and correlate to GCP-side evidence.

Detection Query Pattern

Use the following as an AWS supporting-correlation pattern. This pattern should not be treated as proof of the GCP Vertex AI staging-bucket path from AWS telemetry alone. Production alerting should require GCP-side corroboration from Vertex AI audit logs, Cloud Storage activity, service-account activity, model registry activity, endpoint deployment evidence, or model artifact evidence.

AWS-only matches should be routed to hunt or investigation context unless they are correlated with a GCP-side Vertex AI or Cloud Storage signal through a reliable local join key.

WITH aws_vertex_workflows AS (

  SELECT

    job_time,

    account_id,

    principal_arn,

    ci_job_id,

    build_id,

    runner_id,

    repository,

    commit_sha,

    workload_id,

    service_account_hint,

    package_name,

    package_version,

    package_version_status,

    artifact_path

  FROM ENV_AWS_CICD_DEPENDENCY_LOGS

  WHERE package_name = 'google-cloud-aiplatform'

    AND package_version_status IN ('affected','unvalidated')

),

aws_gcp_egress AS (

  SELECT

    flow_time,

    account_id,

    principal_arn,

    ci_job_id,

    build_id,

    runner_id,

    workload_id,

    srcaddr,

    dstaddr,

    dstport,

    destination_domain,

    action,

    rare_destination_for_workflow

  FROM ENV_AWS_VPC_OR_PROXY_LOGS

  WHERE action IN ('ACCEPT','allowed','proxied')

    AND destination_domain IS NOT NULL

    AND destination_domain NOT IN (

      SELECT destination_domain

      FROM ENV_APPROVED_GCP_DESTINATIONS

    )

    AND (

      destination_domain LIKE '%aiplatform.googleapis.com'

      OR destination_domain LIKE '%storage.googleapis.com'

      OR destination_domain LIKE '%secretmanager.googleapis.com'

      OR destination_domain LIKE '%iam.googleapis.com'

      OR destination_domain LIKE '%artifactregistry.googleapis.com'

      OR rare_destination_for_workflow = true

    )

),

aws_secret_access AS (

  SELECT

    event_time,

    account_id,

    principal_arn,

    ci_job_id,

    build_id,

    runner_id,

    event_name,

    secret_id,

    secret_name,

    secret_tags

  FROM ENV_AWS_CLOUDTRAIL

  WHERE event_source = 'secretsmanager.amazonaws.com'

    AND event_name IN ('GetSecretValue','UpdateSecret','PutSecretValue')

    AND (

      LOWER(secret_name) LIKE '%gcp%'

      OR LOWER(secret_name) LIKE '%google%'

      OR LOWER(secret_name) LIKE '%vertex%'

      OR LOWER(secret_name) LIKE '%aiplatform%'

      OR LOWER(secret_name) LIKE '%service-account%'

      OR LOWER(secret_tags) LIKE '%gcp%'

      OR LOWER(secret_tags) LIKE '%vertex%'

      OR LOWER(secret_tags) LIKE '%aiplatform%'

    )

),

gcp_vertex_upload AS (

  SELECT

    event_time,

    gcp_project_id,

    principal_email,

    service_account,

    method_name,

    model_id,

    endpoint_id,

    artifact_uri,

    staging_bucket,

    ci_job_id,

    build_id,

    repository,

    commit_sha,

    workload_id

  FROM ENV_GCP_VERTEX_AUDIT_LOGS

  WHERE service_name = 'aiplatform.googleapis.com'

    AND (

      method_name LIKE '%UploadModel%'

      OR method_name LIKE '%CreateModel%'

      OR method_name LIKE '%ImportModel%'

      OR method_name LIKE '%DeployModel%'

    )

    AND artifact_uri LIKE 'gs://%'

    AND staging_bucket IS NOT NULL

    AND staging_bucket NOT IN (

      SELECT staging_bucket

      FROM ENV_APPROVED_VERTEX_STAGING_BUCKETS

    )

),

gcp_same_bucket_storage AS (

  SELECT

    event_time,

    gcp_project_id,

    principal_email,

    service_account,

    method_name,

    bucket_name,

    object_name,

    object_hash,

    ci_job_id,

    build_id,

    workload_id

  FROM ENV_GCP_STORAGE_AUDIT_LOGS

  WHERE service_name = 'storage.googleapis.com'

    AND (

      method_name LIKE '%storage.objects.create%'

      OR method_name LIKE '%storage.objects.update%'

      OR method_name LIKE '%storage.objects.delete%'

      OR method_name LIKE '%storage.objects.get%'

      OR method_name LIKE '%storage.objects.rewrite%'

      OR method_name LIKE '%storage.buckets.setIamPolicy%'

    )

)

SELECT

  w.job_time,

  w.account_id,

  w.principal_arn,

  w.ci_job_id,

  w.build_id,

  w.runner_id,

  w.repository,

  w.commit_sha,

  w.workload_id,

  w.package_version,

  w.package_version_status,

  w.artifact_path,

  e.flow_time,

  e.destination_domain,

  e.dstaddr,

  e.dstport,

  s.event_time AS secret_time,

  s.event_name AS secret_event_name,

  s.secret_id,

  s.secret_name,

  g.event_time AS gcp_vertex_time,

  g.gcp_project_id,

  g.principal_email AS gcp_principal_email,

  g.service_account AS gcp_service_account,

  g.method_name AS gcp_vertex_method,

  g.model_id,

  g.endpoint_id,

  g.artifact_uri,

  g.staging_bucket,

  gs.event_time AS gcp_storage_time,

  gs.method_name AS gcp_storage_method,

  gs.bucket_name,

  gs.object_name,

  gs.object_hash,

  CASE

    WHEN g.event_time IS NOT NULL

      AND gs.event_time IS NOT NULL

      AND gs.bucket_name = g.staging_bucket

      AND s.event_name IS NOT NULL

      THEN 'high'

    WHEN g.event_time IS NOT NULL

      AND gs.event_time IS NOT NULL

      AND gs.bucket_name = g.staging_bucket

      THEN 'high'

    WHEN g.event_time IS NOT NULL

      AND (

        e.destination_domain IS NOT NULL

        OR s.event_name IS NOT NULL

      )

      THEN 'medium'

    ELSE 'investigation_context'

  END AS severity,

  CASE

    WHEN g.event_time IS NOT NULL

      AND gs.event_time IS NOT NULL

      AND gs.bucket_name = g.staging_bucket

      THEN 'AWS affected or unvalidated Vertex AI SDK workflow correlated with GCP Vertex AI upload and same-bucket Cloud Storage activity'

    WHEN g.event_time IS NOT NULL

      AND s.event_name IS NOT NULL

      THEN 'AWS affected or unvalidated Vertex AI SDK workflow correlated with GCP Vertex AI upload and AWS GCP-related secret access'

    WHEN g.event_time IS NOT NULL

      AND e.destination_domain IS NOT NULL

      THEN 'AWS affected or unvalidated Vertex AI SDK workflow correlated with GCP Vertex AI upload and scoped GCP API egress'

    ELSE 'AWS-only supporting context without sufficient GCP-side corroboration'

  END AS correlation_reason,

  'AWS CI/CD or ML Build Workflow Vertex AI Upload Exposure With GCP-Corroborated Artifact or Secret Activity' AS detection_rule

FROM aws_vertex_workflows w

LEFT JOIN aws_gcp_egress e

  ON w.account_id = e.account_id

  AND (

    w.principal_arn = e.principal_arn

    OR w.ci_job_id = e.ci_job_id

    OR w.build_id = e.build_id

    OR w.runner_id = e.runner_id

    OR w.workload_id = e.workload_id

  )

  AND e.flow_time BETWEEN w.job_time AND w.job_time + INTERVAL '120' MINUTE

LEFT JOIN aws_secret_access s

  ON w.account_id = s.account_id

  AND (

    w.principal_arn = s.principal_arn

    OR w.ci_job_id = s.ci_job_id

    OR w.build_id = s.build_id

    OR w.runner_id = s.runner_id

  )

  AND s.event_time BETWEEN w.job_time AND w.job_time + INTERVAL '120' MINUTE

LEFT JOIN gcp_vertex_upload g

  ON (

    w.ci_job_id = g.ci_job_id

    OR w.build_id = g.build_id

    OR w.workload_id = g.workload_id

    OR w.service_account_hint = g.service_account

    OR (

      w.repository = g.repository

      AND w.commit_sha = g.commit_sha

    )

    OR (

      w.repository = g.repository

      AND w.build_id = g.build_id

    )

    OR (

      w.repository = g.repository

      AND w.ci_job_id = g.ci_job_id

    )

  )

  AND g.event_time BETWEEN w.job_time - INTERVAL '30' MINUTE

                       AND w.job_time + INTERVAL '120' MINUTE

LEFT JOIN gcp_same_bucket_storage gs

  ON gs.gcp_project_id = g.gcp_project_id

  AND gs.bucket_name = g.staging_bucket

  AND (

    gs.service_account = g.service_account

    OR gs.principal_email = g.principal_email

    OR gs.ci_job_id = g.ci_job_id

    OR gs.build_id = g.build_id

    OR gs.workload_id = g.workload_id

  )

  AND gs.event_time BETWEEN g.event_time

                        AND g.event_time + INTERVAL '120' MINUTE

WHERE g.event_time IS NOT NULL

  AND (

    e.destination_domain IS NOT NULL

    OR s.event_name IS NOT NULL

    OR gs.event_time IS NOT NULL

  );

IMPLEMENTATION REQUIREMENTS:
Populate package_version_status from SCA, SBOM, dependency inventory, CI/CD dependency telemetry, notebook dependency exports, or endpoint software inventory.
Populate rare_destination_for_workflow from local egress baselines for the CI/CD job, runner, workload identity, repository, or AWS account.
Populate service_account_hint only when AWS workflow telemetry reliably maps to the GCP service account, workload identity, secret, deployment profile, or build workflow used for Vertex AI operations.
Normalize ci_job_id, build_id, runner_id, repository, commit_sha, workload_id, and service-account fields across AWS and GCP telemetry before enabling alert mode.
Do not allow repository alone or commit_sha alone to join AWS workflow telemetry to GCP Vertex AI activity.
Require same-bucket matching for Cloud Storage follow-on activity by enforcing gs.bucket_name = g.staging_bucket.
Treat AWS-only results without GCP Vertex AI or same-bucket Cloud Storage corroboration as hunt context, not a production alert.

SEVERITY:
medium when affected or unvalidated google-cloud-aiplatform SDK usage in an AWS CI/CD or ML build workflow is correlated with a GCP Vertex AI upload or model registration event, and supporting AWS egress or GCP-related secret access is present.

high when the AWS workflow is correlated with GCP Vertex AI upload activity and same-bucket Cloud Storage object activity, bucket IAM change, model artifact hash drift, unusual service-account activity, or GCP-related AWS secret access tied to the same build, runner, repository, workload, or service-account mapping.

critical only when GCP-corroborated activity includes confirmed unsafe model-load behavior, credential misuse, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, model artifact tampering, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence.

SUPPRESSION:
suppress when the AWS workflow is an approved model release, rebuild, validation, or incident-response workflow.
suppress when ci_job_id, build_id, or runner_id maps to an approved CI/CD runner and approved deployment record.
suppress when principal_arn maps to an approved release role and the activity matches approved workflow behavior.
suppress when destination_domain is in approved GCP API or artifact destinations for the workflow.
suppress when the GCP staging_bucket is in approved Vertex AI staging buckets.
suppress when the correlated GCP service_account is approved and activity matches the expected release workflow.
suppress when maintenance_window = true.

OUTPUT:
first_seen
last_seen
severity
correlation_reason
account_id
principal_arn
ci_job_id
build_id
runner_id
repository
commit_sha
workload_id
package_version
package_version_status
destination_domain
dstaddr
dstport
secret_event_name
secret_id
secret_name
gcp_project_id
gcp_principal_email
gcp_service_account
gcp_vertex_method
model_id
endpoint_id
artifact_uri
staging_bucket
gcp_storage_method
bucket_name
object_name
object_hash
detection_rule

AZURE

Detection Viability Assessment

Supporting-only. Azure telemetry is relevant only where Azure-hosted CI/CD, notebook, ML build, model validation, artifact handling, or deployment systems participate in the Vertex AI workflow. Azure does not directly observe GCP Vertex AI Model.upload behavior, GCP Cloud Storage bucket ownership, GCP model registry state, or GCP endpoint deployment state. Use this rule to identify Azure-side workflow exposure and supporting evidence, not to independently confirm the GCP staging-bucket abuse path.

Rule

Azure CI/CD or ML Build Workflow Vertex AI Upload Exposure With Cross-Cloud Artifact or Secret Activity

Rule Format

Azure Monitor / Log Analytics / Key Vault / CI/CD / endpoint supporting-correlation pattern requiring cross-cloud workflow mapping, dependency enrichment, approved GCP destination baselining, and GCP-side corroboration.

Detection Purpose

Detect Azure-hosted CI/CD, notebook, or ML build systems that perform Vertex AI model-upload workflows and then show suspicious package exposure, artifact access, secret access, cross-cloud credential use, or unusual egress consistent with Vertex AI staging bucket abuse investigation.

Detection Logic

Trigger when Azure-hosted ML build, notebook, validation, artifact-handling, or CI/CD infrastructure shows affected or unvalidated google-cloud-aiplatform workflow exposure and can be correlated to GCP-side Vertex AI model upload, model creation, model import, model deployment, unapproved staging bucket use, same-bucket Cloud Storage activity, model artifact evidence, service-account activity, or endpoint deployment evidence.

Assign medium severity when Azure-hosted CI/CD or ML build workflow evidence is correlated with GCP-side Vertex AI upload activity through a reliable local join key and supporting Azure egress, GCP-related Key Vault access, affected SDK usage, or artifact-handling context is present.

Assign high severity only when the Azure workflow is correlated with GCP-side Vertex AI upload activity and same-bucket Cloud Storage object activity, bucket IAM change, model artifact hash drift, unusual service-account activity, endpoint deployment, or GCP-related Key Vault access tied to the same build, runner, repository, workload, managed identity, or service-account mapping.

Promote to critical only when GCP-corroborated activity includes confirmed unsafe model-load behavior, credential misuse, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, model artifact tampering, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence.

Do not promote Azure-only telemetry to high-confidence Vertex AI staging-bucket abuse without GCP-side Vertex AI, Cloud Storage, model artifact, service-account, or endpoint correlation.

Required Telemetry

Azure Activity Logs.

Azure Monitor logs.

NSG Flow Logs or firewall logs.

Azure DNS or proxy logs.

Key Vault audit logs.

Azure DevOps, GitHub Actions, GitLab, Jenkins, or CI/CD logs.

Defender for Endpoint telemetry from Azure-hosted ML build systems.

Dependency inventory.

Approved Azure ML build host lookup.

Approved CI/CD workflow lookup.

Approved Google service-account credential lookup.

Approved GCP destination lookup.

Approved maintenance-window lookup.

GCP correlation feed where available.

Engineering Implementation Instructions

Map subscription ID, resource group, principal, caller IP, VM name, host name, CI/CD job ID, repository, commit SHA, package_name, package_version, package_version_status, destination domain, destination IP, Key Vault secret name, artifact path, and timestamp.

Create local inventories for Azure-hosted Vertex AI workflow hosts, Azure-hosted Vertex AI CI/CD runners, approved GCP destinations, approved Google service-account credentials, approved Vertex AI release workflows, and approved maintenance windows.

Create package_version_status as local enrichment from SCA, SBOM, CI/CD package telemetry, endpoint package inventory, notebook dependency exports, or dependency inventory.

Correlate Azure-side findings with GCP-side Vertex AI model-upload events, Cloud Storage object activity, unapproved staging bucket findings, model artifact hash drift, endpoint deployment events, or service-account activity before raising confidence above supporting evidence.

Do not attribute Azure-only events to Vertex AI staging bucket abuse unless there is a workflow-level link to Vertex AI Model.upload, GCP Cloud Storage, Google service-account credentials, model artifacts, or GCP-side unapproved staging bucket activity.

Treat Azure-to-GCP workflow mapping, CI/CD log retention, package enrichment, Key Vault mapping, egress baselining, and cross-cloud correlation as required local deployment work.

DRI Assessment

Moderate where Azure-hosted CI/CD or ML build systems are part of the Vertex AI model upload path. Low where Azure has no role in ML build, upload, validation, or deployment workflows.

DRI

7.0 / 10

TCR Assessment

Moderate for cross-cloud workflow exposure. High only when Azure workflow evidence is correlated with GCP Vertex AI upload, Cloud Storage object activity, unapproved staging bucket use, or model artifact drift.

Operational TCR

6.7 / 10

Full-Telemetry TCR

8.1 / 10

Limitations

Azure cannot directly validate GCP bucket ownership, Vertex AI audit methods, GCP model registry state, GCP model artifact generation, or GCP endpoint deployment state. Azure telemetry is supporting evidence only unless Azure-hosted systems participate in the Vertex AI build, upload, validation, or deployment workflow and correlate to GCP-side evidence.

Detection Query Pattern

Use the following as an Azure supporting-correlation pattern. This pattern should not be treated as proof of the GCP Vertex AI staging-bucket path from Azure telemetry alone. Production alerting should require GCP-side corroboration from Vertex AI audit logs, Cloud Storage activity, service-account activity, model registry activity, endpoint deployment evidence, or model artifact evidence.

Azure-only matches should be routed to hunt or investigation context unless they are correlated with a GCP-side Vertex AI or Cloud Storage signal through a reliable local join key.

let VertexWorkflows =

ENV_AZURE_CICD_DEPENDENCY_LOGS

| where PackageName == "google-cloud-aiplatform"

| where PackageVersionStatus in ("affected","unvalidated")

| extend WorkflowRecordId = hash_sha256(strcat(

    tostring(TimeGenerated), "|",

    tostring(SubscriptionId), "|",

    tostring(CiJobId), "|",

    tostring(BuildId), "|",

    tostring(WorkflowId), "|",

    tostring(RunnerId), "|",

    tostring(Repository), "|",

    tostring(CommitSha)

))

| project

    WorkflowRecordId,

    JobTime = TimeGenerated,

    SubscriptionId,

    AzurePrincipal = Principal,

    AzureManagedIdentity = ManagedIdentity,

    AzureHostName = HostName,

    CiJobId,

    BuildId,

    WorkflowId,

    RunnerId,

    Repository,

    CommitSha,

    ServiceAccountHint,

    PackageName,

    PackageVersion,

    PackageVersionStatus,

    ArtifactPath;

let WorkflowJoinKeys =

union

(

    VertexWorkflows

    | where isnotempty(CiJobId)

    | project WorkflowRecordId, SubscriptionId, JoinType = "ci_job_id", JoinValue = tostring(CiJobId)

),

(

    VertexWorkflows

    | where isnotempty(BuildId)

    | project WorkflowRecordId, SubscriptionId, JoinType = "build_id", JoinValue = tostring(BuildId)

),

(

    VertexWorkflows

    | where isnotempty(WorkflowId)

    | project WorkflowRecordId, SubscriptionId, JoinType = "workflow_id", JoinValue = tostring(WorkflowId)

),

(

    VertexWorkflows

    | where isnotempty(RunnerId)

    | project WorkflowRecordId, SubscriptionId, JoinType = "runner_id", JoinValue = tostring(RunnerId)

),

(

    VertexWorkflows

    | where isnotempty(AzureManagedIdentity)

    | project WorkflowRecordId, SubscriptionId, JoinType = "managed_identity", JoinValue = tostring(AzureManagedIdentity)

),

(

    VertexWorkflows

    | where isnotempty(ServiceAccountHint)

    | project WorkflowRecordId, SubscriptionId, JoinType = "service_account", JoinValue = tostring(ServiceAccountHint)

),

(

    VertexWorkflows

    | where isnotempty(Repository) and isnotempty(CommitSha)

    | project WorkflowRecordId, SubscriptionId, JoinType = "repository_commit", JoinValue = strcat(tostring(Repository), "|", tostring(CommitSha))

);

let GcpEgress =

ENV_AZURE_PROXY_OR_FLOW_LOGS

| where Action in ("Allowed","allowed","proxied","connected")

| where isnotempty(DestinationDomain)

| where DestinationDomain !in (ENV_APPROVED_GCP_DESTINATIONS)

| where DestinationDomain has "aiplatform.googleapis.com"

    or DestinationDomain has "storage.googleapis.com"

    or DestinationDomain has "secretmanager.googleapis.com"

    or DestinationDomain has "iam.googleapis.com"

    or DestinationDomain has "artifactregistry.googleapis.com"

    or RareDestinationForWorkflow == true

| extend EgressRecordId = hash_sha256(strcat(

    tostring(TimeGenerated), "|",

    tostring(SubscriptionId), "|",

    tostring(HostName), "|",

    tostring(DestinationDomain), "|",

    tostring(DestinationIp), "|",

    tostring(DestinationPort)

))

| project

    EgressRecordId,

    EgressTime = TimeGenerated,

    SubscriptionId,

    EgressPrincipal = Principal,

    EgressManagedIdentity = ManagedIdentity,

    EgressHostName = HostName,

    CiJobId,

    BuildId,

    WorkflowId,

    RunnerId,

    DestinationDomain,

    DestinationIp,

    DestinationPort,

    RareDestinationForWorkflow;

let EgressJoinKeys =

union

(

    GcpEgress

    | where isnotempty(CiJobId)

    | project EgressRecordId, SubscriptionId, JoinType = "ci_job_id", JoinValue = tostring(CiJobId)

),

(

    GcpEgress

    | where isnotempty(BuildId)

    | project EgressRecordId, SubscriptionId, JoinType = "build_id", JoinValue = tostring(BuildId)

),

(

    GcpEgress

    | where isnotempty(WorkflowId)

    | project EgressRecordId, SubscriptionId, JoinType = "workflow_id", JoinValue = tostring(WorkflowId)

),

(

    GcpEgress

    | where isnotempty(RunnerId)

    | project EgressRecordId, SubscriptionId, JoinType = "runner_id", JoinValue = tostring(RunnerId)

),

(

    GcpEgress

    | where isnotempty(EgressManagedIdentity)

    | project EgressRecordId, SubscriptionId, JoinType = "managed_identity", JoinValue = tostring(EgressManagedIdentity)

),

(

    GcpEgress

    | where isnotempty(EgressHostName)

    | project EgressRecordId, SubscriptionId, JoinType = "host_name", JoinValue = tostring(EgressHostName)

);

let KeyVaultAccess =

AzureDiagnostics

| where ResourceProvider == "MICROSOFT.KEYVAULT"

| where OperationName in ("SecretGet","SecretSet","SecretList")

| extend SecretName = tostring(parse_json(Properties).secretName)

| extend SecretTags = tostring(parse_json(Properties).tags)

| extend KeyVaultCaller = tostring(identity_claim_appid_g)

| where SecretName has_any ("gcp","google","vertex","aiplatform","service-account")

    or SecretTags has_any ("gcp","google","vertex","aiplatform","service-account")

| extend SecretRecordId = hash_sha256(strcat(

    tostring(TimeGenerated), "|",

    tostring(SubscriptionId), "|",

    tostring(ResourceId), "|",

    tostring(SecretName), "|",

    tostring(OperationName)

))

| project

    SecretRecordId,

    SecretTime = TimeGenerated,

    SubscriptionId,

    KeyVaultCaller,

    KeyVaultPrincipal = Principal,

    KeyVaultManagedIdentity = ManagedIdentity,

    KeyVaultHostName = HostName,

    CiJobId,

    BuildId,

    WorkflowId,

    RunnerId,

    ResourceId,

    SecretName,

    OperationName;

let KeyVaultJoinKeys =

union

(

    KeyVaultAccess

    | where isnotempty(CiJobId)

    | project SecretRecordId, SubscriptionId, JoinType = "ci_job_id", JoinValue = tostring(CiJobId)

),

(

    KeyVaultAccess

    | where isnotempty(BuildId)

    | project SecretRecordId, SubscriptionId, JoinType = "build_id", JoinValue = tostring(BuildId)

),

(

    KeyVaultAccess

    | where isnotempty(WorkflowId)

    | project SecretRecordId, SubscriptionId, JoinType = "workflow_id", JoinValue = tostring(WorkflowId)

),

(

    KeyVaultAccess

    | where isnotempty(RunnerId)

    | project SecretRecordId, SubscriptionId, JoinType = "runner_id", JoinValue = tostring(RunnerId)

),

(

    KeyVaultAccess

    | where isnotempty(KeyVaultManagedIdentity)

    | project SecretRecordId, SubscriptionId, JoinType = "managed_identity", JoinValue = tostring(KeyVaultManagedIdentity)

),

(

    KeyVaultAccess

    | where isnotempty(KeyVaultHostName)

    | project SecretRecordId, SubscriptionId, JoinType = "host_name", JoinValue = tostring(KeyVaultHostName)

);

let GcpVertexUpload =

ENV_GCP_VERTEX_AUDIT_LOGS

| where ServiceName == "aiplatform.googleapis.com"

| where MethodName has_any ("UploadModel","CreateModel","ImportModel","DeployModel")

| where ArtifactUri startswith "gs://"

| where isnotempty(StagingBucket)

| where StagingBucket !in (ENV_APPROVED_VERTEX_STAGING_BUCKETS)

| extend GcpVertexRecordId = hash_sha256(strcat(

    tostring(TimeGenerated), "|",

    tostring(GcpProjectId), "|",

    tostring(PrincipalEmail), "|",

    tostring(ServiceAccount), "|",

    tostring(MethodName), "|",

    tostring(ArtifactUri), "|",

    tostring(StagingBucket)

))

| project

    GcpVertexRecordId,

    GcpVertexTime = TimeGenerated,

    GcpProjectId,

    GcpPrincipalEmail = PrincipalEmail,

    GcpServiceAccount = ServiceAccount,

    GcpMethodName = MethodName,

    ModelId,

    EndpointId,

    ArtifactUri,

    StagingBucket,

    CiJobId,

    BuildId,

    WorkflowId,

    Repository,

    CommitSha,

    ManagedIdentity,

    WorkloadId;

let GcpVertexJoinKeys =

union

(

    GcpVertexUpload

    | where isnotempty(CiJobId)

    | project GcpVertexRecordId, JoinType = "ci_job_id", JoinValue = tostring(CiJobId)

),

(

    GcpVertexUpload

    | where isnotempty(BuildId)

    | project GcpVertexRecordId, JoinType = "build_id", JoinValue = tostring(BuildId)

),

(

    GcpVertexUpload

    | where isnotempty(WorkflowId)

    | project GcpVertexRecordId, JoinType = "workflow_id", JoinValue = tostring(WorkflowId)

),

(

    GcpVertexUpload

    | where isnotempty(ManagedIdentity)

    | project GcpVertexRecordId, JoinType = "managed_identity", JoinValue = tostring(ManagedIdentity)

),

(

    GcpVertexUpload

    | where isnotempty(GcpServiceAccount)

    | project GcpVertexRecordId, JoinType = "service_account", JoinValue = tostring(GcpServiceAccount)

),

(

    GcpVertexUpload

    | where isnotempty(Repository) and isnotempty(CommitSha)

    | project GcpVertexRecordId, JoinType = "repository_commit", JoinValue = strcat(tostring(Repository), "|", tostring(CommitSha))

);

let GcpSameBucketStorage =

ENV_GCP_STORAGE_AUDIT_LOGS

| where ServiceName == "storage.googleapis.com"

| where MethodName has_any (

    "storage.objects.create",

    "storage.objects.update",

    "storage.objects.delete",

    "storage.objects.get",

    "storage.objects.rewrite",

    "storage.buckets.setIamPolicy"

)

| project

    GcpStorageTime = TimeGenerated,

    StorageGcpProjectId = GcpProjectId,

    StoragePrincipalEmail = PrincipalEmail,

    StorageServiceAccount = ServiceAccount,

    GcpStorageMethod = MethodName,

    BucketName,

    ObjectName,

    ObjectHash,

    StorageCiJobId = CiJobId,

    StorageBuildId = BuildId,

    StorageWorkflowId = WorkflowId,

    StorageWorkloadId = WorkloadId;

let WorkflowToGcpVertex =

WorkflowJoinKeys

| join kind=inner GcpVertexJoinKeys on JoinType, JoinValue

| join kind=inner VertexWorkflows on WorkflowRecordId

| join kind=inner GcpVertexUpload on GcpVertexRecordId

| where GcpVertexTime between (JobTime - 30m .. JobTime + 120m)

| summarize

    GcpVertexTime = min(GcpVertexTime),

    GcpProjectId = any(GcpProjectId),

    GcpPrincipalEmail = any(GcpPrincipalEmail),

    GcpServiceAccount = any(GcpServiceAccount),

    GcpMethodName = any(GcpMethodName),

    ModelId = any(ModelId),

    EndpointId = any(EndpointId),

    ArtifactUri = any(ArtifactUri),

    StagingBucket = any(StagingBucket),

    VertexJoinTypes = make_set(JoinType)

  by

    WorkflowRecordId,

    GcpVertexRecordId;

let WorkflowEgress =

WorkflowJoinKeys

| join kind=inner EgressJoinKeys on SubscriptionId, JoinType, JoinValue

| join kind=inner VertexWorkflows on WorkflowRecordId

| join kind=inner GcpEgress on EgressRecordId

| where EgressTime between (JobTime .. JobTime + 120m)

| summarize

    EgressTime = min(EgressTime),

    DestinationDomain = any(DestinationDomain),

    DestinationIp = any(DestinationIp),

    DestinationPort = any(DestinationPort),

    RareDestinationForWorkflow = any(RareDestinationForWorkflow),

    EgressJoinTypes = make_set(JoinType)

  by WorkflowRecordId;

let WorkflowKeyVault =

WorkflowJoinKeys

| join kind=inner KeyVaultJoinKeys on SubscriptionId, JoinType, JoinValue

| join kind=inner VertexWorkflows on WorkflowRecordId

| join kind=inner KeyVaultAccess on SecretRecordId

| where SecretTime between (JobTime .. JobTime + 120m)

| summarize

    SecretTime = min(SecretTime),

    OperationName = any(OperationName),

    ResourceId = any(ResourceId),

    SecretName = any(SecretName),

    KeyVaultJoinTypes = make_set(JoinType)

  by WorkflowRecordId;

let GcpStorageCorroboration =

GcpVertexUpload

| join kind=inner GcpSameBucketStorage

    on $left.GcpProjectId == $right.StorageGcpProjectId,

       $left.StagingBucket == $right.BucketName

| where GcpStorageTime between (GcpVertexTime .. GcpVertexTime + 120m)

| where StorageServiceAccount == GcpServiceAccount

    or StoragePrincipalEmail == GcpPrincipalEmail

    or StorageCiJobId == CiJobId

    or StorageBuildId == BuildId

    or StorageWorkflowId == WorkflowId

    or StorageWorkloadId == WorkloadId

| summarize

    GcpStorageTime = min(GcpStorageTime),

    GcpStorageMethod = any(GcpStorageMethod),

    BucketName = any(BucketName),

    ObjectName = any(ObjectName),

    ObjectHash = any(ObjectHash)

  by GcpVertexRecordId;

VertexWorkflows

| join kind=inner WorkflowToGcpVertex on WorkflowRecordId

| join kind=leftouter WorkflowEgress on WorkflowRecordId

| join kind=leftouter WorkflowKeyVault on WorkflowRecordId

| join kind=leftouter GcpStorageCorroboration on GcpVertexRecordId

| where isnotempty(GcpVertexTime)

| where isnotempty(EgressTime)

    or isnotempty(SecretTime)

    or isnotempty(GcpStorageTime)

| extend Severity = case(

    isnotempty(GcpStorageTime)

        and BucketName == StagingBucket,

        "high",

    isnotempty(EgressTime)

        or isnotempty(SecretTime),

        "medium",

    "investigation_context"

)

| extend CorrelationReason = case(

    isnotempty(GcpStorageTime)

        and BucketName == StagingBucket,

        "Azure affected or unvalidated Vertex AI SDK workflow correlated with GCP Vertex AI upload and same-bucket Cloud Storage activity",

    isnotempty(SecretTime),

        "Azure affected or unvalidated Vertex AI SDK workflow correlated with GCP Vertex AI upload and GCP-related Key Vault access",

    isnotempty(EgressTime),

        "Azure affected or unvalidated Vertex AI SDK workflow correlated with GCP Vertex AI upload and scoped GCP API egress",

    "Azure-only supporting context without sufficient GCP-side corroboration"

)

| extend DetectionRule = "Azure CI/CD or ML Build Workflow Vertex AI Upload Exposure With GCP-Corroborated Artifact or Secret Activity"

| project

    JobTime,

    SubscriptionId,

    AzurePrincipal,

    AzureManagedIdentity,

    AzureHostName,

    CiJobId,

    BuildId,

    WorkflowId,

    RunnerId,

    Repository,

    CommitSha,

    PackageVersion,

    PackageVersionStatus,

    ArtifactPath,

    DestinationDomain,

    DestinationIp,

    DestinationPort,

    SecretTime,

    OperationName,

    ResourceId,

    SecretName,

    GcpVertexTime,

    GcpProjectId,

    GcpPrincipalEmail,

    GcpServiceAccount,

    GcpMethodName,

    ModelId,

    EndpointId,

    ArtifactUri,

    StagingBucket,

    GcpStorageTime,

    GcpStorageMethod,

    BucketName,

    ObjectName,

    ObjectHash,

    VertexJoinTypes,

    EgressJoinTypes,

    KeyVaultJoinTypes,

    Severity,

    CorrelationReason,

    DetectionRule

Implementation Requirements

Populate PackageVersionStatus from SCA, SBOM, dependency inventory, CI/CD dependency telemetry, notebook dependency exports, or endpoint software inventory.

Populate RareDestinationForWorkflow from local egress baselines for the CI/CD job, runner, workload identity, repository, host, managed identity, or Azure subscription.

Populate ServiceAccountHint only when Azure workflow telemetry reliably maps to the GCP service account, workload identity, secret, deployment profile, or build workflow used for Vertex AI operations.

Normalize CiJobId, BuildId, WorkflowId, RunnerId, Repository, CommitSha, ManagedIdentity, ServiceAccountHint, and workload identity fields across Azure and GCP telemetry before enabling alert mode.

Do not allow Repository alone or CommitSha alone to join Azure workflow telemetry to GCP Vertex AI activity. Use repository_commit only when both values are present and normalized.

Do not rely on KQL auto-suffixed fields such as Principal1, CiJobId3, or WorkloadId1. Project explicit aliases before joins and validate final field names in the customer tenant.

Require same-bucket matching for Cloud Storage follow-on activity by enforcing BucketName = StagingBucket.

Treat Azure-only results without GCP Vertex AI or same-bucket Cloud Storage corroboration as hunt context, not a production alert.

Severity

medium when affected or unvalidated google-cloud-aiplatform SDK usage in an Azure CI/CD or ML build workflow is correlated with a GCP Vertex AI upload or model registration event, and supporting Azure egress or GCP-related Key Vault access is present.

high when the Azure workflow is correlated with GCP Vertex AI upload activity and same-bucket Cloud Storage object activity, bucket IAM change, model artifact hash drift, unusual service-account activity, or GCP-related Key Vault access tied to the same build, runner, repository, workload, managed identity, or service-account mapping.

critical only when GCP-corroborated activity includes confirmed unsafe model-load behavior, credential misuse, Secret Manager access, BigQuery access, Artifact Registry modification, IAM change, production endpoint traffic shift, model artifact tampering, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence.

Suppression

suppress when the Azure workflow is an approved model release, rebuild, validation, or incident-response workflow.

suppress when CiJobId, BuildId, WorkflowId, or RunnerId maps to an approved CI/CD runner and approved deployment record.

suppress when AzurePrincipal or AzureManagedIdentity maps to an approved release identity and the activity matches approved workflow behavior.

suppress when DestinationDomain is in approved GCP API or artifact destinations for the workflow.

suppress when the GCP StagingBucket is in approved Vertex AI staging buckets.

suppress when the correlated GCP GcpServiceAccount is approved and activity matches the expected release workflow.

suppress when maintenance_window = true.

Output

first_seen
last_seen
severity
correlation_reason
SubscriptionId
AzurePrincipal
AzureManagedIdentity
AzureHostName
CiJobId
BuildId
WorkflowId
RunnerId
Repository
CommitSha
PackageVersion
PackageVersionStatus
DestinationDomain
DestinationIp
DestinationPort
OperationName
ResourceId
SecretName
GcpProjectId
GcpPrincipalEmail
GcpServiceAccount
GcpMethodName
ModelId
EndpointId
ArtifactUri
StagingBucket
GcpStorageMethod
BucketName
ObjectName
ObjectHash
VertexJoinTypes
EgressJoinTypes
KeyVaultJoinTypes
DetectionRule

GCP

Detection Viability Assessment

Production-deployable where Google Cloud audit logs, Cloud Storage Data Access logs, Vertex AI audit logs, Cloud Asset Inventory, CI/CD logs, dependency inventory, IAM policy logs, endpoint logs, DNS/proxy logs, and model registry metadata can be joined by project, bucket, region, model ID, endpoint ID, service account, artifact URI, CI/CD job, and bounded time window. GCP-native telemetry is the primary detection surface for this TTD. The rule requires Cloud Storage Data Access logging for staging and model artifact buckets.

Rule

Vertex AI Model Upload Using Unapproved Staging Bucket With Artifact or Deployment Correlation

Rule Format

BigQuery / Cloud Logging / Security Command Center custom detection pattern requiring local table names, asset lookups, dependency enrichment, artifact URI parsing, and deployment workflow mapping.

Detection Purpose

Detect Vertex AI model upload activity where staging bucket ownership, artifact object activity, dependency exposure, endpoint deployment behavior, model artifact drift, or service-account activity indicates possible predictable staging bucket abuse or model upload hijack exposure.

Detection Logic

Trigger when Vertex AI model upload, model creation, model import, or endpoint deployment activity occurs from a project, service account, notebook, or CI/CD workflow using an unapproved staging bucket, unverified artifact URI, affected or unvalidated SDK version, or unexpected Cloud Storage object activity.

Assign medium severity when model upload activity uses an unapproved or newly seen staging bucket.

Assign high severity when unapproved staging bucket use aligns with object write, overwrite, read, delete, rewrite, metadata change, unusual principal access, affected or unvalidated SDK exposure, endpoint deployment, or artifact hash mismatch within 120 minutes.

Promote to critical only when suspicious staging or artifact activity is followed by service-account access to sensitive resources, unsafe serialized artifact execution evidence, model poisoning evidence, model theft evidence, Secret Manager access, BigQuery access, Artifact Registry modification, IAM changes, production endpoint deployment, or production endpoint traffic shift.

Required Telemetry

Cloud Audit Logs.

Cloud Storage Admin Activity logs.

Cloud Storage Data Access logs.

Vertex AI audit logs.

Cloud Asset Inventory.

IAM policy change logs.

Secret Manager audit logs.

BigQuery audit logs.

Artifact Registry audit logs.

Cloud DNS logs where applicable.

VPC Flow Logs where applicable.

CI/CD logs.

Dependency inventory.

Model artifact hash inventory.

Approved Vertex AI project lookup.

Approved staging bucket lookup.

Approved service-account lookup.

Approved CI/CD runner lookup.

Approved model artifact hash lookup.

Approved endpoint lookup.

Approved maintenance-window lookup.

Engineering Implementation Instructions

Map protoPayload.methodName, protoPayload.serviceName, protoPayload.authenticationInfo.principalEmail, protoPayload.requestMetadata.callerIp, resource.labels.project_id, resource.labels.bucket_name, resource.labels.location, storage.object.name, storage.object.generation, storage.object.hash, vertex_ai.model_id, vertex_ai.endpoint_id, artifact_uri, staging_bucket, service_account, ci_job_id, package_name, package_version, package_version_status, endpoint_traffic_split, and timestamp.

Create approved inventories for Vertex AI projects, approved staging buckets, approved service accounts, approved CI/CD runners, approved model hashes, approved endpoints, approved egress destinations, and approved maintenance windows.

Validate Cloud Storage Data Access logging for all approved staging buckets, model artifact buckets, and sensitive ML project buckets.

Validate Vertex AI audit-log method names in the customer tenant before production deployment because method naming can differ by API surface and log sink configuration.

Create enrichment that maps bucket names to project owners, organization ownership, bucket location, IAM policy, retention policy, and approved staging status.

Create enrichment that maps model artifact URI to model ID, endpoint ID, CI/CD job, source repository, commit SHA, build ID, artifact hash, and deployment approval.

Create package_version_status as a local enrichment field from SCA, SBOM, CI/CD package telemetry, notebook dependency exports, endpoint package inventory, or dependency inventory. Do not treat package_version_status as a native GCP audit field.

Run in hunt mode against 30 to 90 days of history to baseline normal model upload, endpoint deployment, batch prediction, notebook experimentation, and CI/CD release behavior.

Treat Cloud Logging sink configuration, BigQuery table mapping, Data Access log enablement, model artifact hash collection, approved bucket inventory, service-account mapping, CI/CD job mapping, package-version enrichment, and SOC triage workflow as required local deployment work.

DRI Assessment

High where Cloud Storage Data Access logs, Vertex AI audit logs, asset inventory, CI/CD records, package enrichment, and model provenance data are available.

DRI

9.1 / 10

TCR Assessment

Operational confidence is moderate for unapproved staging bucket use alone and high when unapproved staging aligns with object manipulation, affected or unvalidated SDK usage, model artifact hash drift, endpoint deployment, service-account activity, or runtime evidence.

Operational TCR

8.6 / 10

Full-Telemetry TCR

9.6 / 10

Limitations

Cloud Storage Data Access logs may be absent or incomplete. SDK version visibility may be weak for developer workstations and notebooks. Model poisoning may not be detectable from cloud logs alone. Critical promotion requires artifact, endpoint, service-account, runtime, or model-integrity evidence beyond one suspicious bucket or one model upload. Field names in exported Cloud Logging datasets must be validated locally.

Detection Query Pattern

Use the following as a BigQuery / Cloud Logging SQL-style detection pattern after validating exported log schema, Vertex AI method names, artifact URI extraction, dependency enrichment, approved-bucket lookup structure, service-account mapping, CI/CD workflow identifiers, model identifiers, endpoint identifiers, and bounded time-window correlation.

This pattern should not be treated as proof of model artifact compromise by itself. It identifies Vertex AI model upload, creation, import, or deployment activity that references an unapproved or newly seen Cloud Storage staging bucket, then correlates that activity with same-bucket Cloud Storage behavior, affected or unvalidated Vertex AI SDK usage, endpoint deployment context, service-account activity, or artifact evidence.

Storage activity before the Vertex AI event may be valid and relevant when it represents pre-staged model artifact placement. Storage activity after the Vertex AI event may represent follow-on reads, rewrites, deletes, IAM changes, deployment preparation, or artifact manipulation. Both directions require same-bucket matching and should be interpreted with method type, identity, object path, and workflow context.

WITH approved_staging_buckets AS (

  SELECT

    bucket_name,

    project_id,

    approved_purpose

  FROM ENV_APPROVED_VERTEX_STAGING_BUCKETS

),

vertex_model_activity AS (

  SELECT

    timestamp AS event_time,

    resource.labels.project_id AS project_id,

    protoPayload.authenticationInfo.principalEmail AS principal_email,

    protoPayload.requestMetadata.callerIp AS caller_ip,

    protoPayload.methodName AS method_name,

    JSON_VALUE(protoPayload.request, '$.model.name') AS model_name,

    JSON_VALUE(protoPayload.request, '$.model.artifactUri') AS artifact_uri,

    JSON_VALUE(protoPayload.request, '$.endpoint') AS endpoint_id,

    JSON_VALUE(protoPayload.request, '$.model.containerSpec.imageUri') AS container_image,

    JSON_VALUE(protoPayload.request, '$.model.labels.ci_job_id') AS ci_job_id,

    JSON_VALUE(protoPayload.request, '$.model.labels.build_id') AS build_id,

    JSON_VALUE(protoPayload.request, '$.model.labels.workflow_id') AS workflow_id,

    JSON_VALUE(protoPayload.request, '$.model.labels.repository') AS repository,

    JSON_VALUE(protoPayload.request, '$.model.labels.commit_sha') AS commit_sha,

    COALESCE(

      protoPayload.authenticationInfo.serviceAccountDelegationInfo[SAFE_OFFSET(0)].firstPartyPrincipal.principalEmail,

      protoPayload.authenticationInfo.serviceAccountDelegationInfo[SAFE_OFFSET(0)].principalSubject,

      protoPayload.authenticationInfo.principalSubject

    ) AS service_account_or_subject,

    'vertex_model_activity' AS signal

  FROM ENV_GCP_AUDIT_LOGS

  WHERE protoPayload.serviceName = 'aiplatform.googleapis.com'

    AND (

      protoPayload.methodName LIKE '%UploadModel%'

      OR protoPayload.methodName LIKE '%CreateModel%'

      OR protoPayload.methodName LIKE '%DeployModel%'

      OR protoPayload.methodName LIKE '%ImportModel%'

    )

),

suspicious_vertex_upload AS (

  SELECT

    v.*,

    REGEXP_EXTRACT(v.artifact_uri, r'^gs://([^/]+)') AS staging_bucket,

    REGEXP_EXTRACT(v.artifact_uri, r'^gs://[^/]+/(.*)$') AS artifact_path

  FROM vertex_model_activity v

  WHERE v.artifact_uri LIKE 'gs://%'

),

unapproved_staging AS (

  SELECT

    s.*

  FROM suspicious_vertex_upload s

  LEFT JOIN approved_staging_buckets a

    ON s.staging_bucket = a.bucket_name

    AND (

      s.project_id = a.project_id

      OR a.project_id IS NULL

    )

  WHERE a.bucket_name IS NULL

),

storage_activity AS (

  SELECT

    timestamp AS event_time,

    resource.labels.project_id AS bucket_project_id,

    resource.labels.bucket_name AS bucket_name,

    protoPayload.authenticationInfo.principalEmail AS principal_email,

    protoPayload.requestMetadata.callerIp AS caller_ip,

    protoPayload.methodName AS method_name,

    protoPayload.resourceName AS resource_name,

    JSON_VALUE(protoPayload.request, '$.name') AS object_name,

    JSON_VALUE(protoPayload.request, '$.metadata.md5Hash') AS object_hash,

    JSON_VALUE(protoPayload.request, '$.metadata.crc32c') AS object_crc32c,

    JSON_VALUE(protoPayload.request, '$.metadata.ci_job_id') AS ci_job_id,

    JSON_VALUE(protoPayload.request, '$.metadata.build_id') AS build_id,

    JSON_VALUE(protoPayload.request, '$.metadata.workflow_id') AS workflow_id,

    COALESCE(

      protoPayload.authenticationInfo.serviceAccountDelegationInfo[SAFE_OFFSET(0)].firstPartyPrincipal.principalEmail,

      protoPayload.authenticationInfo.serviceAccountDelegationInfo[SAFE_OFFSET(0)].principalSubject,

      protoPayload.authenticationInfo.principalSubject

    ) AS service_account_or_subject,

    'storage_activity' AS signal

  FROM ENV_GCP_AUDIT_LOGS

  WHERE protoPayload.serviceName = 'storage.googleapis.com'

    AND (

      protoPayload.methodName LIKE '%storage.objects.create%'

      OR protoPayload.methodName LIKE '%storage.objects.update%'

      OR protoPayload.methodName LIKE '%storage.objects.delete%'

      OR protoPayload.methodName LIKE '%storage.objects.get%'

      OR protoPayload.methodName LIKE '%storage.objects.rewrite%'

      OR protoPayload.methodName LIKE '%storage.buckets.setIamPolicy%'

    )

),

dependency_activity AS (

  SELECT

    timestamp AS event_time,

    project_id,

    ci_job_id,

    build_id,

    workflow_id,

    repository,

    commit_sha,

    principal_email,

    service_account_or_subject,

    model_id,

    endpoint_id,

    artifact_uri,

    artifact_path,

    package_name,

    package_version,

    package_version_status,

    'affected_or_unvalidated_sdk_usage' AS signal

  FROM ENV_VERTEX_AI_DEPENDENCY_INVENTORY

  WHERE package_name = 'google-cloud-aiplatform'

    AND package_version_status IN ('affected','unvalidated')

),

same_bucket_storage_activity AS (

  SELECT

    u.event_time AS vertex_time,

    u.project_id,

    u.principal_email AS vertex_principal,

    u.service_account_or_subject AS vertex_service_account_or_subject,

    u.caller_ip AS vertex_caller_ip,

    u.method_name AS vertex_method,

    u.model_name,

    u.artifact_uri,

    u.artifact_path,

    u.endpoint_id,

    u.container_image,

    u.staging_bucket,

    u.ci_job_id AS vertex_ci_job_id,

    u.build_id AS vertex_build_id,

    u.workflow_id AS vertex_workflow_id,

    u.repository AS vertex_repository,

    u.commit_sha AS vertex_commit_sha,

    o.event_time AS storage_time,

    o.principal_email AS storage_principal,

    o.service_account_or_subject AS storage_service_account_or_subject,

    o.caller_ip AS storage_caller_ip,

    o.method_name AS storage_method,

    o.bucket_name,

    o.object_name,

    o.object_hash,

    o.object_crc32c,

    CASE

      WHEN o.event_time < u.event_time THEN 'pre_staged_artifact_activity'

      WHEN o.event_time >= u.event_time THEN 'post_upload_storage_activity'

      ELSE 'unknown_storage_timing'

    END AS storage_timing,

    CASE

      WHEN o.service_account_or_subject = u.service_account_or_subject

        AND o.service_account_or_subject IS NOT NULL

        THEN true

      WHEN o.principal_email = u.principal_email

        AND o.principal_email IS NOT NULL

        THEN true

      WHEN o.ci_job_id = u.ci_job_id

        AND o.ci_job_id IS NOT NULL

        THEN true

      WHEN o.build_id = u.build_id

        AND o.build_id IS NOT NULL

        THEN true

      WHEN o.workflow_id = u.workflow_id

        AND o.workflow_id IS NOT NULL

        THEN true

      WHEN u.artifact_path IS NOT NULL

        AND LENGTH(u.artifact_path) >= 8

        AND (

          o.object_name = u.artifact_path

          OR STARTS_WITH(o.object_name, CONCAT(u.artifact_path, '/'))

        )

        THEN true

      ELSE false

    END AS storage_has_reliable_join

  FROM unapproved_staging u

  LEFT JOIN storage_activity o

    ON u.staging_bucket = o.bucket_name

    AND o.event_time BETWEEN TIMESTAMP_SUB(u.event_time, INTERVAL 120 MINUTE)

                         AND TIMESTAMP_ADD(u.event_time, INTERVAL 120 MINUTE)

),

dependency_correlation AS (

  SELECT

    u.event_time AS vertex_time,

    u.project_id,

    d.event_time AS dependency_time,

    d.package_version,

    d.package_version_status,

    d.ci_job_id,

    d.build_id,

    d.workflow_id,

    d.repository,

    d.commit_sha,

    d.principal_email,

    d.service_account_or_subject,

    CASE

      WHEN d.ci_job_id = u.ci_job_id

        AND d.ci_job_id IS NOT NULL

        THEN true

      WHEN d.build_id = u.build_id

        AND d.build_id IS NOT NULL

        THEN true

      WHEN d.workflow_id = u.workflow_id

        AND d.workflow_id IS NOT NULL

        THEN true

      WHEN d.service_account_or_subject = u.service_account_or_subject

        AND d.service_account_or_subject IS NOT NULL

        THEN true

      WHEN d.principal_email = u.principal_email

        AND d.principal_email IS NOT NULL

        THEN true

      WHEN d.repository = u.repository

        AND d.commit_sha = u.commit_sha

        AND d.repository IS NOT NULL

        AND d.commit_sha IS NOT NULL

        THEN true

      WHEN d.artifact_uri = u.artifact_uri

        AND d.artifact_uri IS NOT NULL

        THEN true

      WHEN d.artifact_path = u.artifact_path

        AND d.artifact_path IS NOT NULL

        AND LENGTH(d.artifact_path) >= 8

        THEN true

      WHEN d.model_id = u.model_name

        AND d.model_id IS NOT NULL

        THEN true

      WHEN d.endpoint_id = u.endpoint_id

        AND d.endpoint_id IS NOT NULL

        THEN true

      ELSE false

    END AS dependency_has_reliable_join

  FROM unapproved_staging u

  LEFT JOIN dependency_activity d

    ON u.project_id = d.project_id

    AND d.event_time BETWEEN TIMESTAMP_SUB(u.event_time, INTERVAL 24 HOUR)

                         AND TIMESTAMP_ADD(u.event_time, INTERVAL 120 MINUTE)

),

correlated_activity AS (

  SELECT

    s.vertex_time,

    s.project_id,

    s.vertex_principal,

    s.vertex_service_account_or_subject,

    s.vertex_caller_ip,

    s.vertex_method,

    s.model_name,

    s.artifact_uri,

    s.artifact_path,

    s.endpoint_id,

    s.container_image,

    s.staging_bucket,

    s.vertex_ci_job_id,

    s.vertex_build_id,

    s.vertex_workflow_id,

    s.vertex_repository,

    s.vertex_commit_sha,

    s.storage_time,

    s.storage_principal,

    s.storage_service_account_or_subject,

    s.storage_caller_ip,

    s.storage_method,

    s.bucket_name,

    s.object_name,

    s.object_hash,

    s.object_crc32c,

    s.storage_timing,

    s.storage_has_reliable_join,

    d.dependency_time,

    d.package_version,

    d.package_version_status,

    d.dependency_has_reliable_join

  FROM same_bucket_storage_activity s

  LEFT JOIN dependency_correlation d

    ON s.vertex_time = d.vertex_time

    AND s.project_id = d.project_id

)

SELECT

  vertex_time,

  project_id,

  vertex_principal,

  vertex_service_account_or_subject,

  vertex_caller_ip,

  vertex_method,

  model_name,

  artifact_uri,

  artifact_path,

  endpoint_id,

  container_image,

  staging_bucket,

  vertex_ci_job_id,

  vertex_build_id,

  vertex_workflow_id,

  vertex_repository,

  vertex_commit_sha,

  storage_time,

  storage_principal,

  storage_service_account_or_subject,

  storage_caller_ip,

  storage_method,

  bucket_name,

  object_name,

  object_hash,

  object_crc32c,

  storage_timing,

  dependency_time,

  package_version,

  package_version_status,

  CASE

    WHEN storage_method LIKE '%storage.buckets.setIamPolicy%'

      AND storage_has_reliable_join = true

      THEN 'high'

    WHEN storage_method LIKE '%storage.objects.create%'

      AND storage_has_reliable_join = true

      THEN 'high'

    WHEN storage_method LIKE '%storage.objects.update%'

      AND storage_has_reliable_join = true

      THEN 'high'

    WHEN storage_method LIKE '%storage.objects.rewrite%'

      AND storage_has_reliable_join = true

      THEN 'high'

    WHEN endpoint_id IS NOT NULL

      AND storage_method IS NOT NULL

      AND storage_has_reliable_join = true

      THEN 'high'

    WHEN package_version_status IN ('affected','unvalidated')

      AND dependency_has_reliable_join = true

      THEN 'medium'

    WHEN storage_method LIKE '%storage.objects.get%'

      AND storage_has_reliable_join = true

      THEN 'medium'

    WHEN endpoint_id IS NOT NULL

      THEN 'medium'

    ELSE 'medium'

  END AS severity,

  CASE

    WHEN storage_method IS NOT NULL

      AND storage_has_reliable_join = true

      THEN 'Vertex AI model activity using an unapproved staging bucket correlated with same-bucket Cloud Storage activity and reliable identity, workflow, service-account, or object-path context'

    WHEN package_version_status IN ('affected','unvalidated')

      AND dependency_has_reliable_join = true

      THEN 'Vertex AI model activity using an unapproved staging bucket correlated with affected or unvalidated Vertex AI SDK usage through reliable workflow context'

    WHEN endpoint_id IS NOT NULL

      AND storage_method IS NULL

      AND package_version_status IS NULL

      THEN 'Vertex AI model activity using an unapproved staging bucket with endpoint context only; treat as investigation context before promotion'

    WHEN storage_method IS NOT NULL

      THEN 'Vertex AI model activity using an unapproved staging bucket correlated with same-bucket Cloud Storage activity without strong identity or workflow join; review before promotion'

    WHEN package_version_status IN ('affected','unvalidated')

      THEN 'Vertex AI model activity using an unapproved staging bucket correlated with project-level affected or unvalidated SDK context; treat as investigation context'

    ELSE 'Vertex AI model activity using an unapproved staging bucket'

  END AS correlation_reason,

  'Vertex AI Model Upload Using Unapproved Staging Bucket With Same-Bucket Artifact or SDK Correlation' AS detection_rule

FROM correlated_activity

WHERE staging_bucket IS NOT NULL

  AND (

    storage_method IS NOT NULL

    OR (

      package_version_status IN ('affected','unvalidated')

      AND dependency_has_reliable_join = true

    )

    OR endpoint_id IS NOT NULL

  );

Implementation Requirements

Validate Cloud Logging export schema before deployment, including the local paths for artifact_uri, model_name, endpoint_id, container_image, service-account delegation fields, principal-subject fields, request labels, and Cloud Storage object metadata.

Extract staging_bucket from artifact_uri and validate that it represents the bucket referenced by the Vertex AI model artifact URI.

Populate approved staging buckets from a customer-owned lookup or table and include project ownership where available.

Populate package_version_status from SCA, SBOM, dependency inventory, CI/CD dependency telemetry, notebook dependency exports, endpoint package inventory, or endpoint software inventory.

Normalize ci_job_id, build_id, workflow_id, repository, commit_sha, service_account_or_subject, principal_email, model_id, endpoint_id, artifact_uri, and artifact_path across Vertex AI, Cloud Storage, and dependency telemetry before enabling alert mode.

Validate the local service-account path before deployment. If protoPayload.authenticationInfo.serviceAccountDelegationInfo is not populated in the customer export, use the locally mapped service-account, workload-identity, principal-subject, or build-identity field instead.

Require same-bucket matching for Cloud Storage correlation by enforcing bucket_name = staging_bucket.

Treat dependency activity joined only by project_id as weak investigation context, not high-confidence follow-on evidence.

Treat same-bucket Cloud Storage activity without a reliable identity, workflow, service-account, object-path, or CI/CD join as review context before severity promotion.

Treat endpoint-only results as medium investigation context unless supported by same-bucket Cloud Storage behavior, reliable SDK/dependency correlation, service-account activity, model hash drift, or confirmed deployment impact.

Interpret pre-upload storage activity as possible staged-artifact placement only when it is same-bucket and has reliable identity, object-path, service-account, or workflow context.

Severity

medium when unapproved Vertex AI staging bucket use is present with affected or unvalidated SDK usage that has a reliable workflow, identity, repository, commit, service-account, model, endpoint, or artifact-path join.

medium when same-bucket Cloud Storage read activity is present with reliable workflow or identity context but without object write, rewrite, bucket IAM change, endpoint deployment, model hash drift, credential access, or stronger impact evidence.

medium when unapproved Vertex AI staging bucket use includes endpoint context only, without same-bucket Cloud Storage behavior, reliable SDK/dependency correlation, service-account activity, model hash drift, or confirmed deployment impact.

high when unapproved Vertex AI staging bucket use is correlated with same-bucket Cloud Storage object creation, update, rewrite, bucket IAM change, endpoint deployment with reliable storage correlation, model artifact hash drift, or unusual service-account activity through a reliable local join key.

critical only when correlated activity includes unsafe model-load behavior, credential misuse, Secret Manager access, BigQuery access, Artifact Registry modification, IAM policy change, production endpoint traffic shift, model artifact tampering, model theft evidence, model poisoning evidence, or confirmed malicious artifact evidence.

Suppression

suppress when the staging_bucket is in approved Vertex AI staging buckets.

suppress when the activity occurs during an approved maintenance window.

suppress when the service account is approved and activity matches an approved model release, rebuild, validation, incident-response, notebook, or CI/CD workflow.

suppress when ci_job_id, build_id, or workflow_id maps to an approved deployment record.

suppress when the repository and commit SHA map to an approved model-release workflow.

suppress when the object path, object hash, or artifact URI matches an approved model artifact inventory.

Output

first_seen
last_seen
severity
correlation_reason
project_id
vertex_principal
vertex_service_account_or_subject
vertex_caller_ip
vertex_method
model_name
endpoint_id
container_image
artifact_uri
artifact_path
staging_bucket
storage_time
storage_principal
storage_service_account_or_subject
storage_method
bucket_name
object_name
object_hash
object_crc32c
storage_timing
package_version
package_version_status
vertex_ci_job_id
vertex_build_id
vertex_workflow_id
vertex_repository
vertex_commit_sha
detection_rule

S26 Threat-to-Rule Traceability

Predictable or Untrusted Staging Bucket Use

Covered by GCP, Splunk, Elastic, QRadar, and SIGMA where Vertex AI audit logs and artifact URI extraction are available.

Attacker-Controlled Bucket Pre-Creation or Bucket Ownership Drift

Covered by GCP, Splunk, Elastic, and QRadar where Cloud Storage Admin Activity logs, Cloud Asset Inventory, bucket ownership enrichment, and approved staging bucket inventories are available.

Model Artifact Upload, Object Manipulation, or Object Access

Covered by GCP, Splunk, Elastic, and QRadar where Cloud Storage Data Access logs are enabled for staging and model artifact buckets.

Affected or Unvalidated SDK Usage

Covered by Splunk, Elastic, and QRadar where CI/CD, dependency inventory, notebook, or software composition telemetry is available.

Model Artifact Replacement or Poisoning

Partially covered. Direct coverage requires model artifact hashes, model signing, registry provenance, build records, or artifact scanning. Without these controls, detections infer risk from unapproved staging, object manipulation, and deployment sequence.

Unsafe Serialized Model Artifact

Covered by YARA for artifact triage and partially by endpoint or runtime telemetry where model loading produces process, network, credential, or file-access behavior.

Vertex AI Model Registration and Endpoint Deployment

Covered by GCP, Splunk, Elastic, and QRadar where Vertex AI audit logs and endpoint deployment records are available.

Service-Account Abuse and Downstream Cloud Access

Covered by GCP, Splunk, Elastic, and QRadar where IAM, Secret Manager, BigQuery, Artifact Registry, Cloud Storage, and cloud audit telemetry can be joined to Vertex AI-linked service accounts and bounded time windows.

Model Provenance and Post-Fix Validation

Covered through dependency review, bucket ownership validation, model artifact hashing, endpoint review, CI/CD review, service-account review, and controlled rebuild guidance.

Evidence and Visibility Gaps

Covered by telemetry requirements, detection gaps, non-coverage conditions, GCP telemetry limitations, and local implementation guidance.

S29 Detection Coverage Summary

Coverage is strongest where Cloud Storage Data Access logs, Vertex AI audit logs, Cloud Asset Inventory, CI/CD logs, dependency inventory, model artifact hashes, service-account mappings, and endpoint deployment records can be joined by project, region, bucket, artifact URI, model ID, endpoint ID, service account, CI/CD job, and time window.

Minimum viable coverage requires visibility into Vertex AI model upload events and approved staging bucket inventory.

Stronger coverage requires Cloud Storage object-level activity, bucket ownership validation, dependency inventory, CI/CD logs, and model artifact hash records.

Highest confidence requires correlation across affected or unvalidated SDK usage, unapproved staging bucket use, Cloud Storage object manipulation, model artifact hash drift, Vertex AI model registration, endpoint deployment, service-account activity, and runtime or model-integrity evidence.

Cloud-native logs alone are insufficient to prove malicious model execution unless combined with artifact, endpoint, service-account, runtime, model validation, or deployment evidence.

Customer-specific telemetry validation is expected and does not reduce production-readiness when Required Telemetry, Engineering Implementation Instructions, Limitations, and Notes / Next Suggested Steps provide the engineer or administrator with a clear implementation path.

S33 Defensive Control & Hardening Improvements

Update google-cloud-aiplatform to a fixed version that includes staging bucket ownership verification for model-upload workflows, and validate the target version against Google’s current advisory and the organization’s internal dependency inventory.

Explicitly configure trusted Vertex AI staging buckets instead of relying on default or SDK-generated staging behavior.

Maintain an approved staging bucket inventory by project, region, owner, service account, purpose, and model workflow.

Enable Cloud Storage Data Access logs for staging buckets, model artifact buckets, and sensitive ML projects.

Preserve Cloud Audit Logs, Vertex AI audit logs, Cloud Storage logs, CI/CD logs, notebook logs, and model registry records before rotation.

Review historical model upload workflows during the exposure window.

Identify model uploads using affected or unvalidated SDK versions.

Validate bucket ownership for all staging buckets referenced by model upload jobs.

Review Cloud Storage object access, overwrite, delete, rewrite, compose, and metadata events around model upload times.

Compare model artifact hashes between build outputs, staging objects, registry entries, and deployed model versions.

Rebuild and redeploy sensitive models where staging bucket trust or artifact integrity cannot be proven.

Avoid unsafe deserialization of pickle or similar model artifacts where possible.

Require model signing, artifact provenance, build attestations, and release approval for production model deployment.

Restrict Vertex AI, notebook, and CI/CD service-account permissions to least privilege.

Remove broad project-level permissions from model build, upload, and serving identities.

Review Secret Manager, BigQuery, Artifact Registry, Cloud Storage, IAM, GKE, Cloud Run, and Cloud Build access by Vertex AI-linked service accounts.

Separate development, staging, and production ML projects.

Require controlled endpoint deployment approval and traffic-split review.

Monitor endpoint deployment changes and unexpected model version activation.

Add CI/CD dependency pinning and automated vulnerable package checks.

Block unapproved staging bucket use in ML deployment pipelines.

Add policy-as-code checks for bucket ownership, IAM, logging, retention, and encryption.

Document approved model release windows, release owners, and rollback procedures.

S39 Economic Impact & Organizational Exposure

Vertex AI staging bucket abuse creates organizational exposure by increasing uncertainty around AI model integrity, cloud storage trust, SDK-managed deployment behavior, ML pipeline provenance, service-account permissions, model registry reliability, endpoint deployment legitimacy, and production inference trust. Exposure rises when Vertex AI supports customer-facing inference, regulated workflows, AI-assisted decisions, fraud detection, security automation, healthcare analytics, financial analytics, or operationally critical services.

Estimated Economic Exposure

Estimated exposure should be scenario-based and tied to whether activity remains limited to affected SDK exposure or untrusted staging bucket risk, becomes model artifact access or replacement, or expands into unsafe model execution, model poisoning, endpoint manipulation, service-account misuse, sensitive data access, customer-impacting inference changes, or AI governance failure.

Low Impact Scenario

Estimated $20K - $100K.

This scenario applies when vulnerable SDK exposure or suspicious staging configuration is identified quickly, affected workflows are updated, approved bucket ownership is validated, model artifacts match trusted hashes, and audit review confirms no object manipulation, endpoint drift, service-account misuse, or customer impact.

Moderate Impact Scenario

Estimated $100K - $600K.

This scenario applies when unapproved staging bucket use, ambiguous object activity, incomplete SDK inventory, missing Data Access logs, model hash gaps, or uncertain model provenance prevents the organization from quickly ruling out artifact replacement, model theft, model poisoning, or unsafe model deployment.

High Impact Scenario

Estimated $600K - $3.5M+.

This scenario applies when attacker-controlled storage was used, model artifacts were accessed or replaced, unsafe serialized content was loaded, production endpoints deployed untrusted models, service accounts accessed sensitive resources, regulated workflows were affected, model outputs became unreliable, or the organization must suspend, rebuild, retrain, revalidate, and redeploy critical AI systems.

Annualized Risk Exposure

Estimated $100K - $750K for organizations with active Vertex AI adoption, incomplete SDK inventory, weak model artifact provenance, broad service-account permissions, incomplete Cloud Storage Data Access logging, and limited model deployment governance.

Exposure may exceed $750K - $3.5M+ where Vertex AI compromise affects regulated decisions, customer-facing inference, financial modeling, healthcare analytics, fraud detection, security automation, production operations, sensitive data access, legal review, customer communications, or public restoration of AI trust.

Operational Dependency

Operational dependency is high where Vertex AI supports production inference, automated decisions, analytics pipelines, business-critical forecasting, security operations, customer engagement, fraud prevention, or regulated data processing.

Control Trust

Control trust is reduced when the organization cannot prove that staging buckets, model artifacts, model hashes, CI/CD jobs, notebook uploads, service accounts, endpoint deployments, and downstream cloud-resource access remained legitimate during the exposure window.

Visibility Confidence

Visibility confidence is highest when Cloud Storage Data Access logs, Vertex AI audit logs, Cloud Audit Logs, Cloud Asset Inventory, CI/CD logs, dependency inventory, model hashes, endpoint deployment records, service-account access logs, and maintenance records can be joined reliably.

Change-Control Confidence

Change-control confidence is high when SDK upgrades, staging bucket configuration, model uploads, model approvals, endpoint deployments, service-account changes, bucket IAM updates, and emergency rebuilds are documented and attributable.

Downstream Dependency

Downstream dependency is high when Vertex AI models connect to BigQuery, Cloud Storage, Secret Manager, Artifact Registry, Cloud Build, GKE, Cloud Run, customer applications, business analytics, data pipelines, security automation, or customer-facing services.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious Vertex AI activity may affect regulated decisions, customer-facing outputs, sensitive data processing, model confidentiality, training data exposure, production inference integrity, or AI governance obligations.

Residual Economic Risk

Residual economic risk remains if the organization cannot prove that affected SDK versions were removed, staging buckets are trusted, model artifacts are intact, endpoint deployments are legitimate, service-account permissions were not misused, sensitive resources were not accessed, and model behavior remains valid.

Behavioral Coverage Assessment

This TTD covers Vertex AI SDK staging bucket abuse aligned with predictable cloud resource naming, untrusted Cloud Storage staging, model artifact upload hijack, artifact replacement, model poisoning, unsafe serialized model exposure, endpoint deployment drift, service-account misuse, and model provenance failure.

The TTD is not limited to one CVE string, SDK version, bucket name, exploit payload, object hash, model framework, proof-of-concept, or public advisory.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage where observable activity falls inside the TTD’s detection model: unapproved staging bucket use, Vertex AI model upload activity, Cloud Storage object manipulation, bucket ownership drift, affected or unvalidated SDK usage, model artifact hash mismatch, endpoint deployment changes, and service-account activity.

The S25 detection content provides coverage with adaptation for related AI platform, ML pipeline, cloud SDK, model registry, serialized model artifact, bucket squatting, model poisoning, and cloud storage trust-boundary abuse where observable behavior aligns to untrusted staging, model artifact manipulation, or model deployment integrity failure.

Non-Coverage Conditions

Non-coverage applies where related activity does not produce observable Vertex AI model upload behavior, untrusted staging bucket use, Cloud Storage object activity, model artifact drift, endpoint deployment change, service-account activity, artifact scanning evidence, or model-integrity impact.

Activity limited to unrelated GCP storage misconfiguration, unrelated Vertex AI misuse, benign notebook experimentation, unrelated AI model poisoning, cloud-only anomalies, identity-only anomalies, network-only anomalies, or unrelated CI/CD dependency issues should not be represented as covered by this TTD unless behavior aligns to the detection model.

Coverage Qualification

This is a behavioral detection-readiness statement, not a universal Vertex AI, Google Cloud, AI security, model poisoning, bucket squatting, SDK vulnerability, CVE, or proof-of-concept coverage ledger. A related issue should only be considered aligned when it shares enough observable behavior with the TTD’s detection model to support credible detection or detection-readiness coverage.

CVE status, vendor severity, exploit availability, SDK version, or public proof-of-concept status should be treated as urgency and remediation-prioritization signals, not as the basis for coverage by themselves. Coverage remains based on observable Vertex AI model-upload-to-staging-bucket-to-artifact-deployment behavior aligned to the TTD’s S21 through S25 detection strategy.

Executive Exposure Statement

The organization’s economic exposure is highest when Vertex AI model upload activity creates uncertainty around whether staging buckets, model artifacts, model registries, service accounts, endpoint deployments, and production inference outputs remain trustworthy. The strategic risk is not one SDK version or one bucket name; it is the possibility that attackers can convert a trusted AI development workflow into a model artifact hijack path and leave poisoned, stolen, or unsafe model content behind after remediation.

S40 References

Vendor / Platform Documentation

·        Google Cloud Vertex AI Documentation - hxxps://cloud[.]google[.]com/vertex-ai/docs

·        Google Cloud Storage Documentation - hxxps://cloud[.]google[.]com/storage/docs

·        Google Cloud Audit Logs Documentation - hxxps://cloud[.]google[.]com/logging/docs/audit

·        Google Cloud Storage Data Access Audit Logs - hxxps://cloud[.]google[.]com/storage/docs/audit-logging

·        Google Cloud Python Client Libraries Changelog - hxxps://docs[.]cloud[.]google[.]com/python/docs/reference/aiplatform/latest/changelog

Primary Vulnerability and Technical Analysis

·        Unit 42 - Pickle in the Middle: Hijacking Vertex AI Model Uploads for Cross-Tenant RCE - hxxps://unit42[.]paloaltonetworks[.]com/hijacking-vertex-ai-model/

·        The Hacker News - Google Vertex AI SDK Flaw Let Attackers Hijack Model Uploads via Bucket Squatting - hxxps://thehackernews[.]com/2026/06/google-vertex-ai-sdk-flaw-let-attackers.html

·        CSO Online - Google’s Vertex AI SDK could allow RCE through bucket squatting - hxxps://www[.]csoonline[.]com/article/4186193/googles-vertex-ai-sdk-could-allow-rce-through-bucket-squatting.html

Related Predictable-Bucket Context

·        NVD - CVE-2026-2473 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-2473

·        Google Cloud Security Bulletin - GCP-2026-012 - hxxps://docs[.]cloud[.]google[.]com/support/bulletins#gcp-2026-012

Threat Technique Framework

·        MITRE ATT&CK Enterprise Matrix / Techniques Catalog - hxxps://attack[.]mitre[.]org/

Detection Platform Documentation

·        Splunk Search Reference - hxxps://docs[.]splunk[.]com/Documentation/Splunk/latest/SearchReference/WhatsInThisManual

·        Elastic Security Detection Rules Documentation - hxxps://www[.]elastic[.]co/guide/en/security/current/rules-ui-management.html

·        IBM QRadar Documentation - hxxps://www[.]ibm[.]com/docs/en/qradar-common

·        Sigma Rule Specification - hxxps://sigmahq[.]io/docs/basics/rules.html

·        YARA Documentation - hxxps://yara[.]readthedocs[.]io/

·        Google Cloud Logging Documentation - hxxps://cloud[.]google[.]com/logging/docs