Kubernetes Privileged Pod Created

  1[metadata]
  2creation_date = "2022/07/05"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has
 11access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the
 12privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with
 13the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the
 14environment, or setting up a command and control channel on the host.
 15"""
 16false_positives = [
 17    """
 18    By default a container is not allowed to access any devices on the host, but a "privileged" container is given
 19    access to all devices on the host. This allows the container nearly all the same access as processes running on the
 20    host. An administrator may want to run a privileged container to use operating system administrative capabilities
 21    such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for
 22    trusted container images using the query field "kubernetes.audit.requestObject.spec.container.image"
 23    """,
 24]
 25index = ["logs-kubernetes.*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "Kubernetes Privileged Pod Created"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating Kubernetes Privileged Pod Created
 35
 36Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.
 37
 38### Possible investigation steps
 39
 40- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields.
 41- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.
 42- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.
 43- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.
 44- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.
 45
 46### False positive analysis
 47
 48- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.
 49- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.
 50- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.
 51- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.
 52
 53### Response and remediation
 54
 55- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.
 56- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.
 57- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.
 58- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.
 59- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.
 60- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.
 61- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions.
 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://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF",
 68    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/",
 69]
 70risk_score = 47
 71rule_id = "c7908cac-337a-4f38-b50d-5eeb78bdb531"
 72severity = "medium"
 73tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 74timestamp_override = "event.ingested"
 75type = "query"
 76
 77query = '''
 78event.dataset : "kubernetes.audit_logs"
 79  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
 80  and kubernetes.audit.objectRef.resource:pods
 81  and kubernetes.audit.verb:create
 82  and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true
 83  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
 84'''
 85
 86
 87[[rule.threat]]
 88framework = "MITRE ATT&CK"
 89[[rule.threat.technique]]
 90id = "T1611"
 91name = "Escape to Host"
 92reference = "https://attack.mitre.org/techniques/T1611/"
 93
 94
 95[rule.threat.tactic]
 96id = "TA0004"
 97name = "Privilege Escalation"
 98reference = "https://attack.mitre.org/tactics/TA0004/"
 99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1610"
103name = "Deploy Container"
104reference = "https://attack.mitre.org/techniques/T1610/"
105
106
107[rule.threat.tactic]
108id = "TA0002"
109name = "Execution"
110reference = "https://attack.mitre.org/tactics/TA0002/"