Kubernetes Secrets List Across Cluster or Sensitive Namespaces

This detection rule identifies potential malicious activity within Kubernetes environments by monitoring API requests for listing secrets. Specifically, it focuses on list operations against Kubernetes Secrets originating from non-loopback clients. The rule triggers when these requests target cluster-wide secrets or attempt to enumerate secrets within the kube-system or default namespaces. Such behavior can indicate an attacker attempting to broadly discover and access sensitive credentials stored as Kubernetes secrets. This is critical for defenders because successful enumeration of secrets can lead to privilege escalation and data breaches. This rule is part of the Elastic detection rules and was last updated on 2026/05/11.

Attack Chain

1. The attacker gains initial access to a compromised pod or node within the Kubernetes cluster.
2. The attacker executes commands within the compromised resource to interact with the Kubernetes API.
3. The attacker attempts to enumerate Kubernetes secrets using kubectl or a similar API client.
4. The attacker constructs a list operation targeting /api/v1/secrets to enumerate all secrets in the cluster.
5. Alternatively, the attacker targets secrets within sensitive namespaces such as /api/v1/namespaces/kube-system/secrets or /api/v1/namespaces/default/secrets.
6. The Kubernetes API server processes the request and returns a list of secrets to the attacker.
7. The attacker extracts sensitive information such as passwords, API keys, or certificates from the enumerated secrets.
8. The attacker uses the acquired credentials to further compromise the cluster or access external resources.

Impact

Successful exploitation can lead to the exposure of sensitive credentials stored as Kubernetes secrets. This can enable attackers to gain unauthorized access to other resources within the cluster, escalate privileges, and potentially compromise the entire environment. Sensitive data stored within the secrets could be exfiltrated.

Recommendation

• Deploy the Sigma rule Kubernetes Secrets List in Cluster or Sensitive Namespaces to your SIEM and tune it to your environment by adjusting the filter conditions to avoid false positives from legitimate administrative activities.
• Review and harden the RBAC policies in your Kubernetes cluster to limit access to secrets based on the principle of least privilege, mitigating the impact of successful T1552.007.
• Investigate any alerts generated by the Kubernetes Secrets List in Cluster or Sensitive Namespaces rule, focusing on the actor (user.name, groups), request URI (kubernetes.audit.requestURI), and client information to determine if the activity is legitimate.
• Monitor Kubernetes audit logs for suspicious API requests related to secrets using the logs-kubernetes.audit_logs-* index as described in the rule configuration.