This documentation contains work-in-progress information for future Elastic Stack and Cloud releases. Use the version selector to view supported release docs. It also contains some Elastic Cloud serverless information. Check out our serverless docs for more details.

« Kubernetes Pod created with a Sensitive hostPath Volume Kubernetes Suspicious Assignment of Controller Service Account »

› › ›

Kubernetes Privileged Pod Created

edit

Kubernetes Privileged Pod Created

edit

This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node’s resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.

Rule type: query

Rule indices:

logs-kubernetes.*

Severity: medium

Risk score: 47

Runs every: 5 minutes

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

Elastic
Kubernetes
Continuous Monitoring
Execution
Privilege Escalation

Version: 200 (version history)

Added (Elastic Stack release): 8.4.0

Last modified (Elastic Stack release): 8.6.0

Rule authors: Elastic

Rule license: Elastic License v2

Potential false positives

edit

By default a container is not allowed to access any devices on the host, but a "privileged" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. An administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for trusted container images using the query field "kubernetes.audit.requestObject.spec.container.image"

Investigation guide

edit

Rule query

edit

event.dataset : "kubernetes.audit_logs" and
kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
and kubernetes.audit.objectRef.resource:pods and
kubernetes.audit.verb:create and kubernetes.audit.requestObject.spe
c.containers.securityContext.privileged:true and not
kubernetes.audit.requestObject.spec.containers.image:
("docker.elastic.co/beats/elastic-agent:8.4.0")

Threat mapping

edit

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Escape to Host
- ID: T1611
- Reference URL: https://attack.mitre.org/techniques/T1611/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Deploy Container
- ID: T1610
- Reference URL: https://attack.mitre.org/techniques/T1610/

Rule version history

edit

Version 200 (8.6.0 release)

Updated query, changed from:

kubernetes.audit.objectRef.resource:pods and
kubernetes.audit.verb:create and kubernetes.audit.requestObject.spec
.containers.securityContext.privileged:true

Version 100 (8.5.0 release)

Formatting only

« Kubernetes Pod created with a Sensitive hostPath Volume Kubernetes Suspicious Assignment of Controller Service Account »