Kubernetes Suspicious Assignment of Controller Service Account

  1[metadata]
  2creation_date = "2022/09/13"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system
 11namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in
 12the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate
 13adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system
 14namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate
 15privileges and gain complete cluster control.
 16"""
 17false_positives = [
 18    """
 19    Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few
 20    legitimate use-cases and should result in very few false positives.
 21    """,
 22]
 23index = ["logs-kubernetes.*"]
 24language = "kuery"
 25license = "Elastic License v2"
 26name = "Kubernetes Suspicious Assignment of Controller Service Account"
 27note = """## Triage and analysis
 28
 29> **Disclaimer**:
 30> 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.
 31
 32### Investigating Kubernetes Suspicious Assignment of Controller Service Account
 33
 34Kubernetes 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.
 35
 36### Possible investigation steps
 37
 38- 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".
 39- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.
 40- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.
 41- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.
 42- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.
 43- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies.
 44
 45### False positive analysis
 46
 47- 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.
 48- 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.
 49- 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.
 50- 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.
 51- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.
 52
 53### Response and remediation
 54
 55- 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.
 56- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.
 57- 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.
 58- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.
 59- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.
 60- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.
 61- 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.
 62
 63## Setup
 64
 65The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 66references = [
 67    "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
 68]
 69risk_score = 47
 70rule_id = "63c05204-339a-11ed-a261-0242ac120002"
 71severity = "medium"
 72tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 73timestamp_override = "event.ingested"
 74type = "query"
 75
 76query = '''
 77event.dataset : "kubernetes.audit_logs"
 78  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
 79  and kubernetes.audit.verb : "create"
 80  and kubernetes.audit.objectRef.resource : "pods"
 81  and kubernetes.audit.objectRef.namespace : "kube-system"
 82  and kubernetes.audit.requestObject.spec.serviceAccountName:*controller
 83'''
 84
 85
 86[[rule.threat]]
 87framework = "MITRE ATT&CK"
 88[[rule.threat.technique]]
 89id = "T1078"
 90name = "Valid Accounts"
 91reference = "https://attack.mitre.org/techniques/T1078/"
 92[[rule.threat.technique.subtechnique]]
 93id = "T1078.001"
 94name = "Default Accounts"
 95reference = "https://attack.mitre.org/techniques/T1078/001/"
 96
 97
 98
 99[rule.threat.tactic]
100id = "TA0004"
101name = "Privilege Escalation"
102reference = "https://attack.mitre.org/tactics/TA0004/"