AWS EKS Suspicious Assignment of Controller Service Account

  1[metadata]
  2creation_date = "2026/08/03"
  3integration = ["aws"]
  4maturity = "production"
  5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
  6min_stack_version = "9.6.0"
  7updated_date = "2026/10/21"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system
 13namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in
 14the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate
 15adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system
 16namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate
 17privileges and gain complete cluster control.
 18"""
 19false_positives = [
 20    """
 21    Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few
 22    legitimate use-cases and should result in very few false positives.
 23    """,
 24]
 25from = "now-6m"
 26index = ["logs-aws.eks_audit-*"]
 27language = "kuery"
 28license = "Elastic License v2"
 29name = "AWS EKS Suspicious Assignment of Controller Service Account"
 30note = """## Triage and analysis
 31
 32> **Disclaimer**:
 33> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 34
 35### Investigating AWS EKS Suspicious Assignment of Controller Service Account
 36Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.
 37
 38### Possible investigation steps
 39
 40- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller".
 41- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.
 42- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.
 43- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.
 44- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.
 45- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies.
 46
 47### False positive analysis
 48
 49- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.
 50- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.
 51- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.
 52- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.
 53- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.
 54
 55### Response and remediation
 56
 57- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.
 58- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.
 59- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.
 60- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.
 61- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.
 62- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.
 63- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly."""
 64references = [
 65    "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
 66]
 67risk_score = 47
 68rule_id = "745e8569-609d-5abd-92fb-13dddc901a65"
 69setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 70into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 71pipelines normalize each audit record under `aws.eks.audit.*`.
 72
 73Enable the `audit` control-plane log type on the EKS cluster, send its
 74CloudWatch log group through the AWS integration, and confirm events carry
 75`data_stream.dataset: aws.eks_audit` and
 76`cloud.provider: aws` before enabling this rule.
 77"""
 78severity = "medium"
 79tags = [
 80    "Domain: Cloud",
 81    "Domain: Containers",
 82    "Platform: AWS",
 83    "Platform: Kubernetes",
 84    "Data Source: AWS",
 85    "Data Source: Amazon Web Services",
 86    "Data Source: Kubernetes API Server Audit Logs",
 87    "Service: AWS EKS",
 88    "Use Case: Threat Detection",
 89    "Tactic: Privilege Escalation",
 90    "Rule Type: Custom Query (KQL)",
 91    "Resources: Investigation Guide",
 92    "Profile: Beta",
 93]
 94timestamp_override = "event.ingested"
 95type = "query"
 96
 97query = '''
 98data_stream.dataset : "aws.eks_audit" and aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
 99aws.eks.audit.verb : "create" and aws.eks.audit.objectRef.resource : "pods" and
100aws.eks.audit.objectRef.namespace : "kube-system" and aws.eks.audit.requestObject.spec.serviceAccountName:*controller and
101not aws.eks.audit.requestObject.spec.containers.image:(
102  mirror.gcr.io/aquasec/trivy* or *amazonaws.com/eks/snapshot-controller* or rancher/mirrored-sig-storage-snapshot-controller* or
103  public.ecr.aws/eks/aws-load-balancer-controller* or docker.io/bitnami/sealed-secrets-controller* or
104  registry.k8s.io/autoscaling/vpa-admission-controller* or registry.k8s.io/sig-storage/csi-attacher* or registry.k8s.io/sig-storage/csi-provisioner*
105)
106'''
107
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1078"
113name = "Valid Accounts"
114reference = "https://attack.mitre.org/techniques/T1078/"
115[[rule.threat.technique.subtechnique]]
116id = "T1078.001"
117name = "Default Accounts"
118reference = "https://attack.mitre.org/techniques/T1078/001/"
119
120
121
122[rule.threat.tactic]
123id = "TA0004"
124name = "Privilege Escalation"
125reference = "https://attack.mitre.org/tactics/TA0004/"