DET0206: Detection of Malicious Kubernetes CronJob Scheduling
This detection strategy matters because malicious or unauthorized Kubernetes CronJob scheduling can turn a container cluster into a recurring execution and...
Analyst context for executives and security teams
This detection strategy matters because malicious or unauthorized Kubernetes CronJob scheduling can turn a container cluster into a recurring execution and persistence mechanism. For leaders, the key issue is not only whether Kubernetes exists in the environment, but whether security teams can prove who created scheduled workloads, what they run, and whether those jobs are expected business automation or suspicious persistence.
Executive priority
Prioritize this as a cloud/container security and operational resilience question: can the organization detect and investigate scheduled workload creation before it becomes recurring unauthorized execution? Security leaders should ask whether Kubernetes audit evidence is retained, whether cluster role permissions for creating jobs are governed, and whether SOC/IR teams can distinguish approved automation from risky or unexpected scheduled workloads. This also supports compliance readiness where auditability of administrative actions and workload changes is required.
Technical view
DET0206 is linked to ATT&CK technique T1053.007, Container Orchestration Job, which is associated with execution, persistence, and privilege escalation in container environments. Because the detection strategy object provides no official detection text, teams should validate coverage around Kubernetes CronJob and job scheduling activity using local cluster audit data, workload metadata, identity context, and change-management baselines. Detection engineering should focus on creation or modification of scheduled container workloads, unusual schedules, unexpected namespaces, unfamiliar service accounts, and job specifications that launch containers inconsistent with approved operations.
Likely telemetry
- Kubernetes API server audit logs for CronJob, Job, and related workload create/update/delete events
- Identity and authorization context for the user, service account, role, or binding involved in scheduling activity
- Kubernetes object metadata, including namespace, labels, annotations, schedule, image, command, and service account
- Container image and registry metadata associated with scheduled jobs
- Cluster change-management or deployment pipeline records to distinguish approved automation from manual or unexpected changes
Detection direction
- Confirm audit logging captures Kubernetes CronJob and Job creation and modification events with actor, namespace, object, and request details.
- Baseline approved scheduled workloads by namespace, owner, image source, schedule, and deployment path; alert on deviations rather than on CronJob usage alone.
- Correlate scheduled workload creation with identity permissions and recent role or service-account changes, since the related technique includes persistence and privilege-escalation context.
- Tune for false positives from legitimate platform automation, backup jobs, CI/CD systems, and maintenance tasks.
- Identify blind spots where clusters are managed outside central logging, audit logs are short-lived, or workload changes bypass expected deployment pipelines.
Mitigation priorities
- Restrict who and what can create or modify Kubernetes CronJobs and related orchestration jobs using least-privilege access controls.
- Require scheduled workload changes to flow through approved deployment or change-management paths where feasible.
- Maintain inventory and ownership of expected CronJobs, namespaces, service accounts, and container images.
- Retain Kubernetes audit logs and workload metadata long enough to support incident response and compliance evidence.
- Review high-privilege service accounts and role bindings that could allow scheduled jobs to maintain execution or persistence in a cluster.
Analyst notes and limits
The strongest relationship-driven context is that DET0206 detects T1053.007, Container Orchestration Job, which MITRE associates with execution, persistence, and privilege escalation for container orchestration tools such as Kubernetes. Local validation should determine whether CronJob scheduling is common, centrally managed, and observable in each cluster.
The supplied ATT&CK detection strategy has no official description, no official detection text, and no directly specified platforms or tactics. The Kubernetes and container focus is derived from the object name and its relationship to T1053.007. Environment-specific telemetry, baselines, and control design are required before assessing coverage or risk.
Detection of Malicious Kubernetes CronJob Scheduling
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1053.007 | Container Orchestration Job Sub-technique | This object detects Container Orchestration Job. |
All related ATT&CK context
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 | cc270c01c9a9… |
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 DET0206Open 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.