Elastic medium stable eql

Service Account Token or Certificate Access Followed by Kubernetes API Request

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the access to the service account token or certificate followed by the execution of a direct interactive Kubernetes API request. An adversary may need to access the service account token or certificate to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.

View Source

Detection Logic

sequence with maxspan=60s
  [file where host.os.type == "linux" and event.type == "change" and event.action == "open" and
   file.path in ("/var/run/secrets/kubernetes.io/serviceaccount/token", "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt") and
   process.interactive == true and container.id like "*"] by orchestrator.resource.name
  [any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted")] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name`

False Positives

  • There is a potential for false positives if the access to the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
  • There is a risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.

Field Validations

Loading…

Comments (0)

Loading comments...