Scheduled Task

Windows Task Scheduler, doing exactly what it's designed to do: run a program at a specified time or trigger. It's a completely legitimate, heavily used administrative feature, and that is precisely what makes it an attractive persistence mechanism. A scheduled task that survives a reboot and re-launches the attacker's payload looks, at a glance, like any of the dozens of other scheduled tasks already on a typical Windows machine.

Nothing about creating a scheduled task requires elevated exploitation. Any account with the right permissions can create one, and depending on how it's configured, it can also be used to escalate privileges by running as SYSTEM.

Once an attacker has a foothold, a scheduled task is one of the simplest ways to guarantee they keep it. Configure a task to re-launch a payload on logon, on a timer, or on system startup, and the attacker survives a reboot without needing anything more sophisticated than the built-in schtasks.exe utility or its API equivalents.

It also shows up as a lateral movement tool: creating a scheduled task on a remote host (via admin shares or RPC) is a well-worn way to get code running on a different machine using only legitimate, built-in tooling.

Data source: endpoint process-creation telemetry for the scheduling utility (Sysmon Event ID 1), plus the task-definition file the scheduler service then writes (Event ID 11)

{
  "host": {
    "name": "APP01"
  },
  "event": {
    "code": "4698",
    "action": "A scheduled task was created"
  },
  "winlog": {
    "event_data": {
      "TaskName": "\\\\MicrosoftUpdateSvc",
      "SubjectUserName": "jdoe"
    }
  }
}

Prebuilt Elastic rule: A scheduled task was created

Legitimate scheduled tasks are usually created by system accounts (ending in $), by known software installers (Microsoft, Adobe, and similar vendors' update tasks), or by IT staff through documented change processes. Tasks created by interactive user accounts, with names designed to look innocuous or to mimic legitimate Windows tasks, or whose action points at something in a temp or user-writable directory, are the pattern worth chasing.

Hunting manually: filter event.code: "4698" excluding system/computer accounts, then decode the TaskContent field to see what the task actually executes. That is usually where intent becomes obvious.

Software installers, update mechanisms (OneDrive, browser updaters, many enterprise applications), and legitimate IT automation all create scheduled tasks constantly. This is one of the noisier persistence techniques to hunt precisely because it's so heavily used for benign purposes.

The distinguishing signal is the task's actual action and its creator, not the act of creation itself: a task created by a known update mechanism, running a signed binary from Program Files, on a normal update cadence, is routine. A task created by an interactive user account, pointing at a script or binary in a temp/Downloads folder, or with a name deliberately similar to a legitimate Windows task (a single character different, for example) is what warrants a closer look. Maintain an allowlist of expected task-creating processes so unexpected creators stand out.

• MITRE ATT&CK T1053.005: Scheduled Task
• Microsoft Event 4698: A scheduled task was created
• Elastic Security: A scheduled task was created

1 scenario in this catalog covers T1053.005. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →