Kubernetes Secret Access via Unusual User Agent

This detection rule identifies instances where Kubernetes secrets are accessed through atypical means, specifically flagging requests originating from unusual user agents, usernames, or source IPs. The underlying assumption is that after compromising a pod or stealing a kubeconfig file, adversaries often attempt to harvest sensitive information stored as secrets within the Kubernetes cluster. This includes service account tokens, registry credentials, cloud keys, and other critical data. This activity can lead to privilege escalation and lateral movement within the cluster or the wider cloud environment. The rule focuses on identifying deviations from established access patterns to Kubernetes secrets to detect potentially malicious activity. The rule leverages data from kubernetes.audit_logs.

Attack Chain

1. Initial Compromise: An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.
2. Discovery: The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using kubectl get secrets --all-namespaces.
3. Credential Theft: The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using curl from a compromised pod to access the Kubernetes API.
4. Data Exfiltration: The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.
5. Lateral Movement: With stolen credentials, the attacker attempts to move laterally within the cluster or the connected cloud environment. They might use the credentials to access other pods, services, or cloud resources.
6. Privilege Escalation: The attacker uses the stolen credentials to escalate their privileges within the Kubernetes cluster or the cloud environment. For example, creating new roles or role bindings.
7. Persistence: The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.
8. Impact: The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.

Impact

Successful exploitation can lead to the compromise of sensitive data stored within Kubernetes secrets. This could include database credentials, API keys, and service account tokens. The impact can range from unauthorized access to sensitive data, to complete compromise of the Kubernetes cluster and the connected cloud environment. This can affect any organization using Kubernetes to manage their applications, potentially leading to data breaches, service disruptions, and financial losses. The severity depends on the sensitivity of the data stored in the compromised secrets and the level of access the attacker gains.

Recommendation

• Deploy the Sigma rule Kubernetes Secret Access via Unusual User Agent to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.
• Investigate and validate any alerts generated by the deployed Sigma rule, focusing on the requesting identity, source IP, and user agent to confirm whether they align with approved access records.
• Implement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.
• Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for suspicious activity, including unusual API calls and access patterns to sensitive resources.
• Regularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.