Kubernetes Secret Access by Node or Pod Service Account

This detection rule identifies suspicious Kubernetes API access patterns where node components (kubelet) or pod service accounts are directly querying the Kubernetes Secrets API. These identities are typically restricted in their API usage. Attackers might compromise a pod’s service account token or node credentials and then attempt to sweep Secret objects to discover credentials, TLS keys, or sensitive application configurations. The rule focuses on get or list operations against the Secrets API. While legitimate controllers might access secrets, unexpected access patterns from nodes or cross-namespace access from service accounts warrant investigation.

Attack Chain

1. An attacker compromises a pod and gains access to its service account token.
2. Alternatively, an attacker compromises a node and obtains node credentials, allowing them to authenticate with the Kubernetes API.
3. The attacker uses the compromised service account or node credentials to authenticate to the Kubernetes API.
4. The attacker attempts to list all secrets in the cluster using kubectl get secrets --all-namespaces or similar API calls.
5. The attacker may target specific secrets by name, attempting to retrieve their contents using kubectl get secret <secret-name> -n <namespace>.
6. The API requests are logged in the Kubernetes audit logs.
7. The attacker identifies secrets containing sensitive information such as API keys, database credentials, or TLS certificates.
8. The attacker exfiltrates the sensitive information for use in lateral movement or external attacks.

Impact

Successful exploitation allows attackers to gain access to sensitive information stored in Kubernetes secrets, such as API keys, database credentials, and TLS certificates. This can lead to further compromise of the cluster, including lateral movement, data exfiltration, and denial-of-service attacks. The rule helps identify unusual access patterns, which can be indicative of malicious activity.

Recommendation

• Deploy the Sigma rule Kubernetes Secret Get or List by Node to your SIEM and tune for your environment.
• Deploy the Sigma rule Kubernetes Secret Get or List by Pod Service Account to your SIEM and tune for your environment, focusing on cross-namespace access.
• Review RBAC RoleBindings and ClusterRoleBindings for the affected node or workload to ensure least privilege, as mentioned in the rule description.
• Investigate source IPs and user agents associated with detected events for anomalous scripts or generic HTTP clients, as described in the rule’s triage section.
• Revoke the compromised token or node credentials and rotate exposed secrets if malicious activity is confirmed, as advised in the response and remediation guidance.