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_valuesto identify which projects were enumerated and whether they include high-value or production workloads. - Confirm whether
client.user.email,source.ip, andEsql.user_agent_original_valuesmatch expected administrators, CI/CD, or approved security scanners. - Check
Esql.event_outcome_valuesfor 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_timestampandEsql.latest_timestamp, then pivot in Discover on the sameclient.user.email/source.ipfor 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.listacross 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
- GCP IAM Service Account Impersonation Role Granted
- GKE Endpoint Permission Enumeration
- GKE Multi-Resource Discovery
- GKE Anonymous Endpoint Permission Enumeration
- GKE Forbidden Request from Unusual User Agent