Kubernetes Rapid Secret GET Activity Against Multiple Objects

This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined 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 also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/04/22"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client 
 11fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster
 12reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry 
 13credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, 
 14confirm the existence of targeted secrets, or reflect automated probing activity.
 15"""
 16from = "now-6m"
 17language = "esql"
 18license = "Elastic License v2"
 19name = "Kubernetes Rapid Secret GET Activity Against Multiple Objects"
 20note = """## Triage and analysis
 21
 22### Investigating Kubernetes Rapid Secret GET Activity Against Multiple Objects
 23
 24This rule surfaces clusters of `get` operations on the `secrets` API where the same identity and client path
 25(`user.name`, `source.ip`, `user_agent.original`) touch several different secret names within the rule lookback window.
 26**Allowed and denied** outcomes are included: successful reads may indicate harvesting; repeated **forbidden** or
 27**unauthorized** responses can still signal reconnaissance, RBAC probing, or scripted spray against secret names that
 28exist in the cluster.
 29
 30### Investigation steps
 31
 32- Inspect `Esql.outcome` for a mix of allow vs deny and whether failures cluster on sensitive namespaces.
 33- Map the identity to RBAC and namespace scope; review `Esql.secrets_names` and `Esql.namespaces` for high-value
 34  targets (tokens, registry credentials, TLS bundles, application secrets).
 35- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets).
 36- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.
 37
 38### False positives
 39
 40- Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by user, namespace, or IP
 41  allowlists when baselined.
 42"""
 43references = [
 44    "https://attack.mitre.org/techniques/T1552/007/",
 45]
 46risk_score = 73
 47rule_id = "b4c8e2a1-9f3d-4e7c-a2b1-0d5e6f7a8b9c"
 48severity = "high"
 49tags = [
 50    "Data Source: Kubernetes",
 51    "Domain: Kubernetes",
 52    "Use Case: Threat Detection",
 53    "Tactic: Credential Access",
 54    "Resources: Investigation Guide",
 55    "Noise: Medium",
 56    "Performance: Fast",
 57    "Rule Type: ES|QL",
 58    "Platform: Kubernetes",
 59    "Domain: Containers",
 60    "Domain: Cloud",
 61]
 62timestamp_override = "event.ingested"
 63type = "esql"
 64query = '''
 65from logs-kubernetes.audit_logs-* metadata _id, _index, _version
 66| where event.dataset == "kubernetes.audit_logs"
 67    and event.action == "get"
 68    and kubernetes.audit.objectRef.resource == "secrets"
 69    and source.ip is not null and user.name is not null 
 70    and not to_string(source.ip) in ("127.0.0.1", "::1") and 
 71    not user.name in ("system:kube-controller-manager", "system:kube-scheduler") and 
 72    not kubernetes.audit.objectRef.name like "sh.helm.release.*" and 
 73    not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator")
 74| stats
 75    Esql.unique_credentials = count_distinct(kubernetes.audit.objectRef.name),
 76    Esql.secrets_names = values(kubernetes.audit.objectRef.name),
 77    Esql.namespaces = values(kubernetes.audit.objectRef.namespace),
 78    Esql.outcome = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
 79  by user.name, kubernetes.audit.user.username, source.ip, user_agent.original
 80| where Esql.unique_credentials >= 3
 81| KEEP user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.*
 82'''
 83
 84[[rule.threat]]
 85framework = "MITRE ATT&CK"
 86
 87[[rule.threat.technique]]
 88id = "T1552"
 89name = "Unsecured Credentials"
 90reference = "https://attack.mitre.org/techniques/T1552/"
 91
 92[[rule.threat.technique.subtechnique]]
 93id = "T1552.007"
 94name = "Container API"
 95reference = "https://attack.mitre.org/techniques/T1552/007/"
 96
 97[rule.threat.tactic]
 98id = "TA0006"
 99name = "Credential Access"
100reference = "https://attack.mitre.org/tactics/TA0006/"

Triage and analysis

Investigating Kubernetes Rapid Secret GET Activity Against Multiple Objects

This rule surfaces clusters of get operations on the secrets API where the same identity and client path (user.name, source.ip, user_agent.original) touch several different secret names within the rule lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated forbidden or unauthorized responses can still signal reconnaissance, RBAC probing, or scripted spray against secret names that exist in the cluster.

Investigation steps

  • Inspect Esql.outcome for a mix of allow vs deny and whether failures cluster on sensitive namespaces.
  • Map the identity to RBAC and namespace scope; review Esql.secrets_names and Esql.namespaces for high-value targets (tokens, registry credentials, TLS bundles, application secrets).
  • Pivot on the same source.ip and user for follow-on API activity (exec, pod create, role changes, broad list on secrets).
  • Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.

False positives

  • Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by user, namespace, or IP allowlists when baselined.

References

Related rules

to-top