AN1304: Analytic 1304
Correlate the creation or modification of containers using restart policies (e.g., 'always') or DaemonSets with elevated host access, service account misuse, or privileged container contexts. Watch for manipulation of systemd units involving containers or pod scheduling targeting specific nodes or namespaces.
Analyst context for executives and security teams
This analytic matters because container restart policies, DaemonSets, privileged container settings, service account misuse, and node or namespace targeting can turn a container workload change into durable access inside a container environment. For leaders, the decision point is whether the organization can distinguish normal platform operations from changes that increase persistence or host-level exposure.
Executive priority
Prioritize this as a cloud/container resilience and audit-readiness question: can teams prove who changed container or pod scheduling behavior, whether privileged or host-access configurations are justified, and whether service account use aligns with approved operations? This is especially important where container platforms support critical applications, because persistence-oriented configuration changes may survive workload restarts and complicate incident response.
Technical view
Validate monitoring for the Containers platform around creation or modification of containers using restart policies such as 'always', DaemonSets with elevated host access, privileged container contexts, service account misuse, systemd unit manipulation involving containers, and pod scheduling changes that target specific nodes or namespaces. Because no ATT&CK tactics, relationships, or official detection logic are supplied, detection engineering should treat this as a behavior-focused correlation requirement rather than a finished rule.
Likely telemetry
- Container or orchestration audit logs for workload creation and modification
- Pod, container, DaemonSet, namespace, and node scheduling metadata
- Service account usage and authorization events
- Container security context and privileged-mode configuration records
- Host access configuration evidence, such as hostPath or equivalent mount/use patterns where available
Detection direction
- Correlate container or pod changes with risky persistence-related settings, including restart policies and DaemonSets, rather than alerting on each setting in isolation.
- Baseline legitimate platform automation, deployment controllers, and cluster administration activity to reduce false positives.
- Review privileged container contexts, elevated host access, and service account use together; the combination is more material than any single field alone.
- Validate visibility into specific node and namespace targeting, as gaps here can hide selective scheduling behavior.
- Confirm whether host telemetry covers systemd unit manipulation involving containers; container-only logs may miss this blind spot.
Mitigation priorities
- Establish policy and review gates for privileged containers, elevated host access, DaemonSets, restart policies, and node or namespace targeting.
- Apply least privilege to service accounts and routinely review service account permissions used by container workloads.
- Require auditable approval for workload configurations that create persistence-like behavior or host-level access.
- Ensure container platform audit logging and relevant host logging are retained for incident response and compliance evidence.
- Include these configuration patterns in container security posture reviews and incident response playbooks.
Analyst notes and limits
The supplied object is a detection analytic for the Containers platform, with no relationship context and no official detection text beyond the behavior description. The most useful interpretation is as a validation checklist for container persistence-oriented configuration monitoring and correlation.
ATT&CK does not supply tactics, related techniques, detections, mitigations, threat actors, or campaigns for this object in the provided data. Local cluster architecture, orchestration platform configuration, CI/CD practices, and logging coverage are required to determine actual risk and detection feasibility.
Analytic 1304
Correlate the creation or modification of containers using restart policies (e.g., 'always') or DaemonSets with elevated host access, service account misuse, or privileged container contexts. Watch for manipulation of systemd units involving containers or pod scheduling targeting specific nodes or namespaces.
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 | 1.0 | Current bundle | 668b5b2a1fdd… |
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 AN1304Open 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.