DC0030: Pod Modification
Changes made to a pod’s configuration or control data within a containerized cluster. This can include updating settings such as resource limits, environment variables, annotations, labels, or even the containers running within the pod. Pod modifications are often executed using commands like kubectl set, kubectl patch, or kubectl edit.
*Data Collection Measures:*
- Kubernetes API Server Audit Logs: - Capture all API calls related to pod modification, such as PATCH, PUT, or UPDATE methods on v1/pods. - Runtime Security Tools: - Tools like Falco, Sysdig, and Kube-bench can monitor pod modifications at runtime and alert on policy violations. - Container Orchestration Logs: - Monitor events logged by Kubernetes itself (e.g., `kubectl logs -n kube-system kube-controller-manager`). - SIEM and EDR Solutions: - Use SIEM platforms (e.g., Splunk) to aggregate API server logs and detect patterns of unauthorized or suspicious pod modifications. - Endpoint Detection and Response (EDR) tools configured with container visibility can monitor commands like `kubectl` set or `kubectl patch`. - Host-Based Monitoring: - Collect and analyze logs for processes executing `kubectl` commands or interacting with Kubernetes configuration files (e.g., `.kube/config`).
Analyst context for executives and security teams
Pod Modification is evidence that something changed how a workload is defined inside a containerized cluster, such as its resource limits, environment variables, labels, annotations, or containers. For leaders, this matters because unauthorized or poorly governed pod changes can affect service reliability, incident scope, compliance evidence, and the integrity of cloud-native operations.
Executive priority
Treat pod modification visibility as a control-validation issue for Kubernetes governance and incident readiness. Executives should ask whether security teams can prove who changed pods, what changed, when it changed, and whether the change was authorized. This evidence supports operational resilience, auditability, and faster incident decisions when containerized services behave unexpectedly.
Technical view
SOC, detection, and IR teams should validate collection of Kubernetes API Server audit events for PATCH, PUT, or UPDATE operations against v1/pods, and correlate those events with user, service account, namespace, workload, and source context where available. Host and endpoint monitoring should also be checked for kubectl-driven changes, especially commands such as kubectl set, kubectl patch, or kubectl edit. Because ATT&CK does not provide a specific detection analytic for this data component, teams need to define local baselines for expected pod changes and alert on unauthorized, unusual, or policy-violating modifications.
Likely telemetry
- Kubernetes API Server audit logs for pod PATCH, PUT, and UPDATE activity on v1/pods
- Kubernetes control plane or container orchestration logs, including relevant kube-system component events
- Runtime security tool alerts for pod configuration or policy violations
- SIEM-ingested Kubernetes audit and orchestration logs
- Endpoint or host process telemetry showing kubectl execution
Detection direction
- Confirm API audit logging captures pod modification verbs and retains enough identity, namespace, object, and request detail for investigation.
- Build or tune detections around unexpected pod changes, changes by unusual users or service accounts, and changes outside approved deployment paths.
- Correlate pod modification events with runtime security alerts and host process telemetry to distinguish administrative activity from suspicious behavior.
- Account for false positives from normal deployment, autoscaling, controller, and maintenance activity by using local change windows and authorized automation identities.
- Identify blind spots where kubectl use, API server audit logging, or container runtime/security telemetry is not centrally collected.
Mitigation priorities
- Prioritize governance over pod changes by ensuring only authorized users, service accounts, and automation can modify pods.
- Require centralized collection and retention of Kubernetes API audit logs before relying on detection logic.
- Use policy and runtime monitoring to flag pod changes that violate approved configuration standards.
- Integrate pod modification evidence into incident response playbooks so responders can quickly determine whether a workload change was legitimate.
- Review SIEM and EDR/container visibility coverage for both API-level changes and host-side kubectl activity.
Analyst notes and limits
This object is a data component, not a technique, and no ATT&CK relationships, tactics, platforms, or official detection analytic were supplied. The strongest use is as a telemetry requirement for Kubernetes/containerized-cluster monitoring and as a checklist item for cloud-native detection engineering and IR evidence collection.
Assessment must be validated against the local cluster architecture, audit policy, logging retention, RBAC model, deployment tooling, and runtime security coverage. The supplied ATT&CK content does not support claims about specific adversaries, active exploitation, impact, or guaranteed detection.
Pod Modification
Changes made to a pod’s configuration or control data within a containerized cluster. This can include updating settings such as resource limits, environment variables, annotations, labels, or even the containers running within the pod. Pod modifications are often executed using commands like kubectl set, kubectl patch, or kubectl edit.
*Data Collection Measures:*
- Kubernetes API Server Audit Logs: - Capture all API calls related to pod modification, such as PATCH, PUT, or UPDATE methods on v1/pods. - Runtime Security Tools: - Tools like Falco, Sysdig, and Kube-bench can monitor pod modifications at runtime and alert on policy violations. - Container Orchestration Logs: - Monitor events logged by Kubernetes itself (e.g., `kubectl logs -n kube-system kube-controller-manager`). - SIEM and EDR Solutions: - Use SIEM platforms (e.g., Splunk) to aggregate API server logs and detect patterns of unauthorized or suspicious pod modifications. - Endpoint Detection and Response (EDR) tools configured with container visibility can monitor commands like `kubectl` set or `kubectl patch`. - Host-Based Monitoring: - Collect and analyze logs for processes executing `kubectl` commands or interacting with Kubernetes configuration files (e.g., `.kube/config`).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | c93e5743a455… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0030Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.