---
{
  "title": "Scheduled Task/Job",
  "summary": "Scheduled task abuse uses operating-system scheduling to run code once or repeatedly.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1053"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1053: Scheduled Task/Job",
      "url": "https://attack.mitre.org/techniques/T1053"
    }
  ],
  "editorialVersion": 2
}
---

## A scheduler can provide one-time or recurring execution

Scheduled tasks and jobs run programs according to defined times, events, or platform scheduling rules. Operating systems and orchestration platforms use these mechanisms for routine maintenance and business processing. Unauthorized scheduling can introduce repeatable execution or run an action under a specified account.

A scheduled job's existence is not proof of persistence or maliciousness. Some jobs run once, fail before executing, or belong to approved software. Investigators should establish the definition, creator, target, execution identity, trigger, and actual results.

## A job references an unfamiliar program

In a fictional company, a new task launches a program from an unexpected location every morning. The analyst preserves the task definition and examines creation records, referenced files, account permissions, and execution history.

An approved updater or reporting tool might explain the schedule. Compare the task with deployment records and the responsible owner. A plausible task name does not establish legitimacy because the action and target can differ from the label.

The team checks whether the task ran successfully and what it did. A registration event shows configuration; scheduler and process records can establish invocation and effects. If the job failed, report the attempted or configured behavior without claiming completed execution.

## Review the authority relationship

Determine who could create or modify the job and which identity executes it. A task running under a privileged account has different implications from one restricted to a user's ordinary context. Platform permissions and credential handling determine the actual opportunity.

[[persistence]] describes retained access, while [[event-triggered-execution]] explains a related trigger model. [[create-or-modify-system-process]] concerns services or daemons and should not be assumed merely because a background process ran.

Preserve referenced artifact information before deletion where practical. Removing the executable but leaving the task can obscure the original behavior or leave a path that can be repopulated later.

## Remove the repeatable mechanism

Disable or remove unauthorized jobs through the approved process and investigate the access that created them. Review other tasks, credentials, and affected systems under the supported scope. Terminating one running instance does not remove future scheduled execution.

Coordinate with operations because maintenance jobs may support backups, updates, and reporting. Verify both the intended scheduler state and required business functions after remediation.

For practice, compare a documented nightly report with a fictional task created after an unexplained administrative session. Identify definition, creator, approval, artifact, and execution evidence. [[logs-and-telemetry]] supports the timeline, while [[incident-reporting]] keeps configuration, invocation, completion, and impact distinct.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]
- [[system-binary-proxy-execution]]