GCP Secret Manager ListSecrets Across Multiple Projects

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/08/12"
  3integration = ["gcp"]
  4maturity = "production"
  5updated_date = "2026/08/12"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a single identity listing Google Cloud Secret Manager secrets across many distinct projects in a short window.
 11ListSecrets does not return secret values, but sweeping many projects is a common reconnaissance step before targeted
 12AccessSecretVersion calls. Legitimate workloads typically list secrets within one project or a small set of projects;
 13cross-project bursts from one user and source IP are uncommon outside security tooling or compromise.
 14"""
 15false_positives = [
 16    """
 17    Organization-wide security scanners, CSPM products, inventory jobs, or approved red-team exercises may list secrets
 18    across many projects. Validate the principal, source IP, user agent, and schedule against known tooling before
 19    treating the activity as malicious, and exclude documented automation identities when baselined.
 20    """,
 21    """
 22    Platform or IAM administrators troubleshooting Secret Manager access across environments may briefly exceed the
 23    project cardinality threshold. Correlate with change tickets and expected administrative clients.
 24    """,
 25]
 26from = "now-6m"
 27interval = "5m"
 28language = "esql"
 29license = "Elastic License v2"
 30name = "GCP Secret Manager ListSecrets Across Multiple Projects"
 31note = """## Triage and analysis
 32
 33### Investigating GCP Secret Manager ListSecrets Across Multiple Projects
 34
 35This rule aggregates Secret Manager `ListSecrets` audit events per `client.user.email` and `source.ip` over the rule
 36lookback. It alerts when the same actor lists secrets in 10 or more distinct `cloud.project.id` values. Listing does
 37not retrieve secret payloads, but multi-project enumeration is a strong discovery signal ahead of credential access.
 38
 39### Possible investigation steps
 40
 41- Review `Esql.cloud_project_id_values` to identify which projects were
 42  enumerated and whether they include high-value or production workloads.
 43- Confirm whether `client.user.email`, `source.ip`, and
 44  `Esql.user_agent_original_values` match expected administrators, CI/CD, or approved security scanners.
 45- Check `Esql.event_outcome_values` for mixed success and failure, which can indicate permission probing across projects
 46  the identity cannot fully access.
 47- Hunt for follow-on Secret Manager activity from the same identity or IP, especially
 48  `AccessSecretVersion`, `GetSecret`, and IAM policy changes on secrets or projects.
 49- Bound the burst with `Esql.earliest_timestamp` and `Esql.latest_timestamp`, then pivot in Discover on the same
 50  `client.user.email` / `source.ip` for related GCP audit activity.
 51
 52### False positive analysis
 53
 54- Documented CSPM, secret inventory, or compliance scanners that walk many projects will match; exclude those
 55  principals after validation.
 56- Break-glass or org-admin troubleshooting can look similar; require change-management correlation before raising
 57  severity.
 58
 59### Response and remediation
 60
 61- If unauthorized, revoke or rotate the implicated credentials, review IAM bindings that grant
 62  `secretmanager.secrets.list` across projects, and inspect for subsequent secret access or exfiltration.
 63- Restrict Secret Manager list permissions to least privilege and prefer per-project roles over org-wide grants for
 64  human users.
 65"""
 66setup = """The GCP Fleet integration (or Filebeat module) with audit logs for Secret Manager is required. `ListSecrets` is a
 67data-access method; enable DATA_READ audit logging for the Secret Manager API so these events are ingested into
 68`logs-gcp.audit-*`.
 69
 70See [Secret Manager audit logging](https://cloud.google.com/secret-manager/docs/audit-logging) and
 71[Configure Data Access audit logs](https://cloud.google.com/logging/docs/audit/configure-data-access).
 72"""
 73references = [
 74    "https://cloud.google.com/secret-manager/docs/reference/rest/v1/projects.secrets/list",
 75]
 76risk_score = 73
 77rule_id = "642ac343-e7d6-4cf2-bb0b-7db412e614ad"
 78severity = "high"
 79tags = [
 80    "Domain: Cloud",
 81    "Data Source: GCP",
 82    "Data Source: Google Cloud Platform",
 83    "Data Source: GCP Audit Logs",
 84    "Use Case: Threat Detection",
 85    "Tactic: Discovery",
 86    "Resources: Investigation Guide",
 87    "Rule Type: ESQL",
 88    "Platform: GCP",
 89    "Service: GCP Secret Manager",
 90]
 91timestamp_override = "event.ingested"
 92type = "esql"
 93
 94query = '''
 95from logs-gcp.audit-* metadata _id, _version, _index
 96| where data_stream.dataset == "gcp.audit"
 97    and event.action == "google.cloud.secretmanager.v1.SecretManagerService.ListSecrets"
 98    and cloud.project.id is not null
 99    and client.user.email is not null
100    and source.ip is not null
101| stats
102    Esql.cloud_project_id_count_distinct = count_distinct(cloud.project.id),
103    Esql.cloud_project_id_values = values(cloud.project.id),
104    Esql.event_count = count(*),
105    Esql.event_outcome_values = values(event.outcome),
106    Esql.client_user_id_values = values(client.user.id),
107    Esql.user_agent_original_values = values(user_agent.original),
108    Esql.earliest_timestamp = min(@timestamp),
109    Esql.latest_timestamp = max(@timestamp)
110  by client.user.email, source.ip, data_stream.namespace
111| where Esql.cloud_project_id_count_distinct >= 10
112| keep
113    client.user.email,
114    source.ip,
115    Esql.cloud_project_id_count_distinct,
116    Esql.cloud_project_id_values,
117    Esql.event_count,
118    Esql.event_outcome_values,
119    Esql.client_user_id_values,
120    Esql.user_agent_original_values,
121    Esql.earliest_timestamp,
122    Esql.latest_timestamp, 
123    data_stream.namespace
124'''
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128
129[[rule.threat.technique]]
130id = "T1526"
131name = "Cloud Service Discovery"
132reference = "https://attack.mitre.org/techniques/T1526/"
133
134[rule.threat.tactic]
135id = "TA0007"
136name = "Discovery"
137reference = "https://attack.mitre.org/tactics/TA0007/"

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.

References

Related rules

to-top