Container Orchestration Job (T1053.007) is the scheduled task technique applied to clusters. MITRE lists it under Execution, Persistence and Privilege Escalation, with Containers as the platform.
In Kubernetes, a CronJob schedules a Job, and a Job runs one or more containers. MITRE's point is that an adversary with the right access can use that machinery to schedule containers that execute malicious code on various nodes. Deployments of this type can also be set to maintain a quantity of containers over time, which automates persistence inside the cluster.
How attackers use it
The mechanism is ordinary. A CronJob works like cron on a Linux host: run this container on this schedule. If someone who should not be creating jobs can create one, the cluster itself becomes the persistence layer, and the job keeps coming back after a single container is removed.
How to detect it
MITRE's detection strategy covers abuse of orchestration platforms where CronJobs are created to maintain persistence or run malicious Jobs across the cluster. In practice that means watching for new or changed CronJobs and Jobs, who created them, and what images they run.
How to reduce the risk
MITRE lists two mitigations.
- Limit account privileges. Remediate privilege escalation vectors so only authorized administrators can create container orchestration jobs.
- Do not run containers as root by default. In Kubernetes, consider Pod Security Standards that prevent pods from running privileged containers.
Check your own environment
Read-only check with kubectl: kubectl get cronjobs --all-namespaces lists every CronJob in the cluster. Compare it against what your teams expect, and look at the image each one runs.
Images are part of the story, because a scheduled job is only as trustworthy as the container it pulls. Scanning the images your jobs use is a sensible control, and you can see how that works below.
Click through it at your own pace, or open it full screen.
Quick check
Why is a CronJob attractive for persistence?
It reschedules itself. Removing one running container does not remove the schedule that creates the next one.
