Full Report
Gain a deeper understanding of why it's essential to monitor non-standard pods and containers, including static pods, mirror pods, init containers, pause containers, and ephemeral containers within your Kubernetes environment.
Analysis Summary
# Tool/Technique: Kubernetes Pods and Containers (Non-Standard Types)
## Overview
This summary details various types of Kubernetes pods and containers which, due to their creation mechanisms (managed by `kubelet` directly or other non-API processes), can evade or limit visibility provided solely by querying the standard Kubernetes API (e.g., via `kubectl`). Attackers can exploit this lack of comprehensive visibility to blend in or execute malicious activities.
## Technical Details
- Type: Technique (Exploitation of Monitoring Blind Spots)
- Platform: Kubernetes/Containerized Environments
- Capabilities: Evading standard API-based monitoring by leveraging non-standard workloads like static pods, mirror pods, init containers, infra containers, and ephemeral containers.
- First Seen: N/A (These are inherent Kubernetes concepts whose blind spots are being highlighted)
## MITRE ATT&CK Mapping
*Note: Since the focus is on the *blind spot* rather than a specific offensive tool, the mappings relate to the general areas where such evasion enables attacks.*
- **TA0005 - Defense Evasion**
- T1027 - Obfuscated Files or Information
- T1027.004 - Compiled Languages or Interpreted Script (Exploiting object types to blend in)
- **TA0008 - Lateral Movement**
- T1550 - Use Alternate Authentication Material (If persistence mechanisms are hidden in non-API managed objects)
- **TA0011 - Command and Control**
- T1071 - Application Layer Protocol (If custom C2 is hidden within a less-monitored pod type)
## Functionality
### Core Capabilities (of the Blind Spots)
- **Standard Pods**: Logically encapsulated units managed directly by the Kubernetes API (`kubectl get pods`). Queryable.
- **Static Pods**: Pods managed directly by the `kubelet` on a node, not the API server. Used often for bootstrapping control plane components.
- **Init Containers**: Containers that run to completion *before* the main containers in a Pod start.
- **Pod Infra (Pause) Container**: A minimal container in every pod responsible for maintaining the pod's network and IPC namespaces.
### Advanced Features (Evasion Vectors)
- **Mirror Pods**: Created by the `kubelet` to reflect the status of a **Static Pod** back to the API server. While they appear in the API, their ownership structure (owner reference points to the Node, not a controller) makes identification tricky without specialized queries.
- **Ephemeral Containers**: Diagnostic tools that can be attached to a running container *after* the pod is created, often invisible to basic workload monitoring focused only on the initial `spec.containers`.
## Indicators of Compromise
*Note: Indicators listed below relate to finding the objects themselves, which facilitates detection.*
- File Hashes: N/A
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: N/A
- Behavioral Indicators:
- Pods without corresponding owner references (Deployments, ReplicaSets, etc.) in the API response.
- Unexpected processes running from the pause container image (if suspicious modifications are made).
- Unexpected provisioning/creation of objects via Kubelet configuration files outside of standard API flows.
## Associated Threat Actors
- Threat actors targeting Kubernetes environments who seek to maintain persistence or evade standard compliance scanning tools relying solely on API polling. (Specific actors are not named in the source document, only the general motive of attackers is mentioned).
## Detection Methods
- **Signature-based detection**: N/A (Relies on object type identification).
- **Behavioral detection**: Implementing workload runtime agents that inspect the underlying node processes and filesystem, rather than relying exclusively on control plane API calls.
- **YARA rules if available**: N/A
## Mitigation Strategies
- **Prevention measures**: Utilizing runtime security tools/agents that gain visibility directly at the node level, bypassing the API limitations.
- **Hardening recommendations**: Regularly auditing Kubelet configurations (e.g., `--pod-manifest-path`) to ensure only trusted sources can define static pods. Implementing strict network policies and runtime monitoring on what processes are executed within infra or init containers.
## Related Tools/Techniques
- Workload runtime agents (Complementary monitoring solutions).
- `kubectl` commands specialized for querying metadata/owner references that reveal Node ownership (for mirror pods).
- Specialized queries using `jq` to filter for specific object types (e.g., checking `spec.ephemeralContainers` or `metadata.ownerReferences`).