« GCP Pub/Sub Topic Deletion GCP Service Account Creation »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

GCP Secret Manager ListSecrets Across Multiple Projects

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

GCP Secret Manager ListSecrets Across Multiple Projects

edit

Detects a single identity listing Google Cloud Secret Manager secrets across many distinct projects in a short window. ListSecrets does not return secret values, but sweeping many projects is a common reconnaissance step before targeted AccessSecretVersion calls. Legitimate workloads typically list secrets within one project or a small set of projects; cross-project bursts from one user and source IP are uncommon outside security tooling or compromise.

Rule type: esql

Rule indices: None

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: GCP
  • Data Source: Google Cloud Platform
  • Data Source: GCP Audit Logs
  • Use Case: Threat Detection
  • Tactic: Discovery
  • Resources: Investigation Guide
  • Rule Type: ESQL
  • Platform: GCP
  • Service: GCP Secret Manager

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating GCP Secret Manager ListSecrets Across Multiple Projects

This rule aggregates Secret Manager ListSecrets audit events per client.user.email and source.ip over the rule lookback. It alerts when the same actor lists secrets in 10 or more distinct cloud.project.id values. Listing does not retrieve secret payloads, but multi-project enumeration is a strong discovery signal ahead of credential access.

Possible investigation steps

  • Review Esql.cloud_project_id_values to identify which projects were enumerated and whether they include high-value or production workloads.
  • Confirm whether client.user.email, source.ip, and Esql.user_agent_original_values match expected administrators, CI/CD, or approved security scanners.
  • Check Esql.event_outcome_values for mixed success and failure, which can indicate permission probing across projects the identity cannot fully access.
  • Hunt for follow-on Secret Manager activity from the same identity or IP, especially AccessSecretVersion, GetSecret, and IAM policy changes on secrets or projects.
  • Bound the burst with Esql.earliest_timestamp and Esql.latest_timestamp, then pivot in Discover on the same client.user.email / source.ip for related GCP audit activity.

False positive analysis

  • Documented CSPM, secret inventory, or compliance scanners that walk many projects will match; exclude those principals after validation.
  • Break-glass or org-admin troubleshooting can look similar; require change-management correlation before raising severity.

Response and remediation

  • If unauthorized, revoke or rotate the implicated credentials, review IAM bindings that grant secretmanager.secrets.list across projects, and inspect for subsequent secret access or exfiltration.
  • Restrict Secret Manager list permissions to least privilege and prefer per-project roles over org-wide grants for human users.

Setup

edit

The GCP Fleet integration (or Filebeat module) with audit logs for Secret Manager is required. ListSecrets is a data-access method; enable DATA_READ audit logging for the Secret Manager API so these events are ingested into logs-gcp.audit-*.

See Secret Manager audit logging and Configure Data Access audit logs.

Rule query

edit
from logs-gcp.audit-* metadata _id, _version, _index
| where data_stream.dataset == "gcp.audit"
    and event.action == "google.cloud.secretmanager.v1.SecretManagerService.ListSecrets"
    and cloud.project.id is not null
    and client.user.email is not null
    and source.ip is not null
| stats
    Esql.cloud_project_id_count_distinct = count_distinct(cloud.project.id),
    Esql.cloud_project_id_values = values(cloud.project.id),
    Esql.event_count = count(*),
    Esql.event_outcome_values = values(event.outcome),
    Esql.client_user_id_values = values(client.user.id),
    Esql.user_agent_original_values = values(user_agent.original),
    Esql.earliest_timestamp = min(@timestamp),
    Esql.latest_timestamp = max(@timestamp)
  by client.user.email, source.ip, data_stream.namespace
| where Esql.cloud_project_id_count_distinct >= 10
| keep
    client.user.email,
    source.ip,
    Esql.cloud_project_id_count_distinct,
    Esql.cloud_project_id_values,
    Esql.event_count,
    Esql.event_outcome_values,
    Esql.client_user_id_values,
    Esql.user_agent_original_values,
    Esql.earliest_timestamp,
    Esql.latest_timestamp,
    data_stream.namespace

Framework: MITRE ATT&CKTM

« GCP Pub/Sub Topic Deletion GCP Service Account Creation »