GKE Rapid Secret GET Activity Against Multiple Objects
Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/07"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2026/07/07"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client
11fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or
12in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service
13account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and
14can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access
15by a service account may indicate compromise or misconfiguration worth investigating.
16"""
17false_positives = [
18 """
19 Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by client.user.email,
20 namespace, or IP allowlists when baselined.
21 """,
22]
23from = "now-6m"
24language = "esql"
25license = "Elastic License v2"
26name = "GKE Rapid Secret GET Activity Against Multiple Objects"
27note = """## Triage and analysis
28
29### Investigating GKE Rapid Secret GET Activity Against Multiple Objects
30
31This rule surfaces clusters of `get` operations on secrets where the same identity and client path
32(`client.user.email`, `source.ip`, `user_agent.original`) touch several different secret resource paths within the
33lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated
34failure responses can still signal reconnaissance or RBAC probing. System service accounts and core controllers are
35excluded only for successful secret reads, failed attempts from those identities still alert.
36
37### Investigation steps
38
39- Inspect `Esql.event_outcome_values` for a mix of success vs failure and whether failures cluster on sensitive namespaces.
40- Map the identity to RBAC and namespace scope; review `Esql.gcp_audit_resource_name_values` for high-value targets (tokens, registry
41 credentials, TLS bundles, application secrets).
42- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets).
43- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.
44
45### False positives
46
47- Controllers and Helm may legitimately read many secrets in one window; tune exclusions after baselining known automation.
48
49## Setup
50
51The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
52references = [
53 "https://attack.mitre.org/techniques/T1552/007/",
54]
55risk_score = 73
56rule_id = "4780a3d6-e6a7-490c-9afb-9c5fbb220b9a"
57severity = "high"
58tags = [
59 "Domain: Cloud",
60 "Domain: Kubernetes",
61 "Data Source: GCP",
62 "Data Source: Google Cloud Platform",
63 "Use Case: Threat Detection",
64 "Tactic: Credential Access",
65 "Resources: Investigation Guide",
66]
67timestamp_override = "event.ingested"
68type = "esql"
69
70query = '''
71from logs-gcp.audit-* metadata _id, _index, _version
72| where data_stream.dataset == "gcp.audit"
73 and service.name == "k8s.io"
74 and event.action == "io.k8s.core.v1.secrets.get"
75 and source.ip is not null
76 and client.user.email is not null
77 and not to_string(source.ip) in ("127.0.0.1", "::1")
78 and not (
79 (client.user.email in ("system:kube-controller-manager", "system:kube-scheduler") or client.user.email like "system:serviceaccount:*")
80 and event.outcome == "success"
81 )
82 and not gcp.audit.resource_name like "*sh.helm.release.*"
83| stats
84 Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name),
85 Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name),
86 Esql.event_outcome_values = values(event.outcome),
87 Esql.timestamp_values = values(@timestamp)
88 by client.user.email, source.ip, user_agent.original
89| where Esql.gcp_audit_resource_name_count_distinct >= 3
90| keep client.user.email, source.ip, user_agent.original, Esql.gcp_audit_resource_name_count_distinct, Esql.gcp_audit_resource_name_values, Esql.event_outcome_values, Esql.timestamp_values
91'''
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95
96[[rule.threat.technique]]
97id = "T1552"
98name = "Unsecured Credentials"
99reference = "https://attack.mitre.org/techniques/T1552/"
100
101[[rule.threat.technique.subtechnique]]
102id = "T1552.007"
103name = "Container API"
104reference = "https://attack.mitre.org/techniques/T1552/007/"
105
106[rule.threat.tactic]
107id = "TA0006"
108name = "Credential Access"
109reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating GKE Rapid Secret GET Activity Against Multiple Objects
This rule surfaces clusters of get operations on secrets where the same identity and client path
(client.user.email, source.ip, user_agent.original) touch several different secret resource paths within the
lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated
failure responses can still signal reconnaissance or RBAC probing. System service accounts and core controllers are
excluded only for successful secret reads, failed attempts from those identities still alert.
Investigation steps
- Inspect
Esql.event_outcome_valuesfor a mix of success vs failure and whether failures cluster on sensitive namespaces. - Map the identity to RBAC and namespace scope; review
Esql.gcp_audit_resource_name_valuesfor high-value targets (tokens, registry credentials, TLS bundles, application secrets). - Pivot on the same
source.ipand user for follow-on API activity (exec, pod create, role changes, broadliston secrets). - Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.
False positives
- Controllers and Helm may legitimately read many secrets in one window; tune exclusions after baselining known automation.
Setup
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
References
Related rules
- GKE Secret get or list with Suspicious User Agent
- GKE Secrets List from Unusual Source AS Organization
- GKE CoreDNS or Kube-DNS Configuration Modified
- GKE API Request Failure Burst by User
- GKE Admission Webhook Created or Modified