Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1053.007: Container Orchestration Job

Adversaries may abuse task scheduling functionality provided by container orchestration tools such as Kubernetes to schedule deployment of containers configured to execute malicious code. Container orchestration jobs run these automated tasks at a specific date and time, similar to cron jobs on a Linux system. Deployments of this type can also be configured to maintain a quantity of containers over time, automating the process of maintaining persistence within a cluster.

In Kubernetes, a CronJob may be used to schedule a Job that runs one or more containers to perform specific tasks.[1][2] An adversary therefore may utilize a CronJob to schedule deployment of a Job that executes malicious code in various nodes within a cluster.[3]

EnterpriseT1053.007Sub-techniqueObject v1.4 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Container orchestration jobs matter because they can turn a Kubernetes scheduling feature into recurring or delayed execution inside a cluster. For leaders, the risk is not just one malicious container running once; a scheduled Job or CronJob can help maintain execution or persistence across nodes if cluster permissions and monitoring are weak.

Executive priority

Prioritize this behavior where Kubernetes or other container orchestration platforms support business-critical services. The key business question is whether teams can prove who is allowed to create or modify scheduled workloads, whether those actions are logged, and whether SOC/IR teams can quickly distinguish approved automation from suspicious persistence. This is also relevant to audit evidence for account governance, privileged access control, and operational resilience of containerized services.

Technical view

This is an ATT&CK sub-technique of Scheduled Task/Job for Containers, mapped to execution, persistence, and privilege escalation. The supplied ATT&CK object has no official detection text, but relationship context identifies DET0206, Detection of Malicious Kubernetes CronJob Scheduling, as a related detection strategy. SOC and detection teams should validate visibility into Kubernetes Job and CronJob creation, modification, deletion, scheduling patterns, container images, namespaces, service accounts, and the account or identity responsible for the change. IR teams should treat unexpected scheduled workloads as potential persistence mechanisms and review associated permissions and spawned containers.

Likely telemetry

  • Kubernetes API server audit logs for Job and CronJob create, update, patch, and delete events
  • Cluster workload inventory showing Jobs, CronJobs, pods, namespaces, schedules, and container images
  • Identity and access records for users, service accounts, and privileged roles able to manage scheduled workloads
  • Container runtime or orchestration events showing containers launched by Jobs or CronJobs
  • Change-management or deployment records to compare approved automation against observed scheduled workloads

Detection direction

  • Validate whether DET0206-style logic exists for malicious or unexpected Kubernetes CronJob scheduling, especially newly created or modified CronJobs in sensitive namespaces.
  • Tune detections against local baselines because legitimate CronJobs and Jobs are common for maintenance, batch processing, backups, and automation.
  • Correlate scheduled workload creation with the requesting identity, service account, namespace, image, and schedule rather than alerting only on the presence of a CronJob.
  • Look for blind spots where Kubernetes audit logging is disabled, retained too briefly, or not forwarded to the SOC platform.
  • Review whether detections cover both one-time Jobs and recurring CronJobs, since ATT&CK describes both scheduled tasks and maintained container quantities over time.

Mitigation priorities

  • Apply User Account Management by limiting which users and service accounts can create or modify Kubernetes Jobs and CronJobs.
  • Apply Privileged Account Management by restricting privileged roles and enforcing least privilege for workload scheduling permissions.
  • Regularly review privileged Kubernetes roles, service accounts, and namespace-level permissions tied to scheduled workload management.
  • Require operational ownership and change records for approved Jobs and CronJobs so suspicious entries can be triaged quickly.
  • Ensure incident response procedures include disabling or removing unauthorized scheduled workloads and reviewing related identities and permissions.
Analyst notes and limits

The materiality of this technique depends heavily on Kubernetes usage, RBAC design, audit logging, and how much scheduled workload activity is normal in the environment. The relationship to Scheduled Task/Job is important: defenders should think of Kubernetes CronJobs as the container-orchestration equivalent of recurring task execution and persistence.

The official ATT&CK detection field is not provided, and the supplied relationship context gives the name of DET0206 but not its full analytic logic. This take is limited to the Containers platform and the provided Kubernetes Job/CronJob references. Local telemetry, RBAC configuration, and workload baselines are required to determine actual exposure or coverage.

Official MITRE ATT&CK definition

Container Orchestration Job

Adversaries may abuse task scheduling functionality provided by container orchestration tools such as Kubernetes to schedule deployment of containers configured to execute malicious code. Container orchestration jobs run these automated tasks at a specific date and time, similar to cron jobs on a Linux system. Deployments of this type can also be configured to maintain a quantity of containers over time, automating the process of maintaining persistence within a cluster.

In Kubernetes, a CronJob may be used to schedule a Job that runs one or more containers to perform specific tasks.[1][2] An adversary therefore may utilize a CronJob to schedule deployment of a Job that executes malicious code in various nodes within a cluster.[3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1053 Scheduled Task/Job This object subtechnique of Scheduled Task/Job.
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1018: User Account Management Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise detects · Detection Strategy DET0206: Detection of Malicious Kubernetes CronJob Scheduling Enterprise subtechnique of · Technique T1053: Scheduled Task/Job Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Change history

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 .

ATT&CK release
19.1
Object version
1.4
Created
Modified
Raw hash
03242655bbe279a9...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.4 Current bundle 03242655bbe2…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Kubernetes Jobs

    The Kubernetes Authors. (n.d.). Kubernetes Jobs. Retrieved March 30, 2021.

    Open source URL
  2. [2]
    Kubernetes CronJob

    The Kubernetes Authors. (n.d.). Kubernetes CronJob. Retrieved March 29, 2021.

    Open source URL
  3. [3]
    Threat Matrix for Kubernetes

    Weizman, Y. (2020, April 2). Threat Matrix for Kubernetes. Retrieved March 30, 2021.

    Open source URL
  4. [4]
    mitre-attack T1053.007
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use