Kubernetes Static Pod Manifest File Access
editKubernetes Static Pod Manifest File Access
editDetects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads.
Rule type: query
Rule indices:
- auditbeat-*
- logs-auditd_manager.auditd-*
- logs-endpoint.events.process*
Severity: medium
Risk score: 47
Runs every: 5m
Searches indices from: now-9m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
Tags:
- Data Source: Auditd Manager
- Data Source: Elastic Defend
- Domain: Endpoint
- Domain: Kubernetes
- Domain: Container
- OS: Linux
- Use Case: Threat Detection
- Tactic: Persistence
- Tactic: Privilege Escalation
- Resources: Investigation Guide
Version: 1
Rule authors:
- Elastic
Rule license: Elastic License v2
Investigation guide
editTriage and analysis
Investigating Kubernetes Static Pod Manifest File Access
Review the full command line (process.args, process.command_line), user.id, user.name, process.parent, and whether the session was interactive. Confirm if the host is a Kubernetes node or admin jump host where manifest edits are expected.
Possible investigation steps
- Compare activity to change windows and identity baselines; prioritize events without matching change tickets.
- Inspect subsequent process and file events on the same host for writes under /etc/kubernetes/manifests or kubelet restarts.
- Correlate with Kubernetes audit logs and node/agent telemetry for related compromise indicators.
Response and remediation
- If unauthorized, restore manifests from known-good sources, isolate the host, and review cluster integrity per incident policy.
Setup
editSetup
Requires Elastic Defend and/or Auditd Manager process telemetry (logs-endpoint.events.process*,
logs-auditd_manager.auditd-*, auditbeat-*) with command-line argument capture for exec events.
Elastic Defend
Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with arguments.
Auditd Manager
Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so process.args and
process.executable populate for monitored binaries.
Rule query
edithost.os.type:linux and event.category:process and event.action:(exec or executed) and process.name:( bash or sh or dash or zsh or cat or cp or mv or touch or tee or dd or sed or awk or curl or wget or scp or vi or vim or nano or echo or busybox or python* or perl* or ruby* or node or lua* or openssl or base64 or xxd or .*) and process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*))
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
-
Technique:
- Name: Scheduled Task/Job
- ID: T1053
- Reference URL: https://attack.mitre.org/techniques/T1053/
-
Sub-technique:
- Name: Container Orchestration Job
- ID: T1053.007
- Reference URL: https://attack.mitre.org/techniques/T1053/007/
-
Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
-
Technique:
- Name: Create or Modify System Process
- ID: T1543
- Reference URL: https://attack.mitre.org/techniques/T1543/
-
Sub-technique:
- Name: Container Service
- ID: T1543.005
- Reference URL: https://attack.mitre.org/techniques/T1543/005/