Kubernetes Pod Created With HostPIDedit
This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root.
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 Added (Elastic Stack release): 8.4.0
Last modified (Elastic Stack release): 8.4.0
Rule authors: Elastic
Rule license: Elastic License v2
Potential false positivesedit
An administrator or developer may want to use a pod that runs as root and shares the host�s IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host’s perspective.
Investigation guideedit
Rule queryedit
kubernetes.audit.objectRef.resource:"pods" and
kubernetes.audit.verb:("create" or "update" or "patch") and
kubernetes.audit.requestObject.spec.hostPID:true
Threat mappingedit
Framework: MITRE ATT&CKTM
-
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/