Skip Navigation
Get a Demo

Technique T1053

Scheduled Task

Scheduled Task is another technique that owes its prominence largely to TrickBot, which schedules tasks to launch malicious binaries and persist on host machines.


Overall rank


Organizations affected


Confirmed threats



With an increase in the percentage of customers affected and a decrease in percentage of total threat volume, Scheduled Task was the second most prevalent threat in both 2018 and 2019.

Why do adversaries use Scheduled Tasks?

Scheduled Tasks allow adversaries to carry out certain actions at pre-specified times, enabling execution, persistence, and privilege escalation. Like many of techniques analyzed in this report, Scheduled Tasks are a functionally necessary component of the Windows operating system. They execute routinely, and malicious tasks readily blend in with benign ones.

Scheduled Tasks represent a versatile tool for adversaries. With the requisite privileges, an attacker can schedule tasks remotely. The technique is also useful for execution and persistence in conjunction with a variety of widely used scripting languages, such as PowerShell.

How do adversaries use Scheduled Tasks?

Adversaries create Scheduled Tasks to run scripts, execute processes, or persist on endpoints to execute later.

Behaviors we frequently observe include:

  • Adware updating itself by using Scheduled Tasks to launch unsigned binaries from AppData
  • Malware using the Task Scheduler Engine (taskeng.exe) to launch a malicious binary that then executes the Service Host process (svchost.exe)
  • Scheduled Tasks executing PowerShell payloads for persistent access

The above behaviors triggered thousands of detections across our customer base and are common characteristics of adware, TrickBot, and QBot infections, respectively.

While TrickBot and Emotet influence the prominence of Scheduled Tasks in our detection data, adversaries of every sophistication level—from adware peddlers to national intelligence agencies—rely on Scheduled Tasks.

Sighted with

Scheduled Tasks very commonly occur alongside:

  • Masquerading (T1036)
  • Process Injection (T1055)
  • Disabling Security Tools (T1089)
  • Domain Trust Discovery (T1482)
  • Remote File Copy (T1105)
  • Windows Admin Shares (T1077)

With the possible exception of Masquerading, TrickBot commonly leverages each of these techniques.



MITRE’s data sources

  • File monitoring
  • Process monitoring
  • Process command-line parameters
  • Windows event logs

Collection requirements

API monitoring

API monitoring is an additional data source that is useful in certain contexts for observing adversaries leveraging Scheduled Task. In some attack campaigns, adversaries have used the Windows Component Object Model and Distributed COM technique (T1175) to create a Scheduled Task via macros or other methods. API monitoring provides visibility into this and other covert methods for creating a Scheduled Task.

File monitoring

File monitoring provides a useful data source for observing the malicious use of Scheduled Tasks. Defenders should consider tracking the schtasks.exe or at.exe binary because it will enable them to continue observing Scheduled Tasks, even if the binary has been moved to a different path or renamed entirely. A Scheduled Task that has been moved or renamed can be a good indicator of malice.

Process monitoring

Monitoring process execution of schtasks.exe and at.exe is important because these processes have the ability to set tasks locally or remotely, enabling lateral movement. Historically, adversaries have set Scheduled Tasks to start under a different user context (administrator, for example).

More recently, PowerShell has a cmdlet (new-ScheduledTask) that provides the same functionality as schtasks.exe. Understanding the processes that normally spawn Scheduled Tasks and monitoring parent-child process relationships is useful for observation as well.

Process command-line parameters

Process command-line parameters are another rich source for observing malicious Scheduled Tasks. While they might provide the highest fidelity of alerting, they also offer adversaries the most potential for blending in. Understanding the various parameters and what to look for in a given environment requires extensive research and testing, but tracking via the command-line is ultimately the way that most teams monitor for Scheduled Task abuse.

Windows event logs

Windows event logs may also provide useful information about start and stop times for task execution as well as additional details about the task itself.

Detection suggestions

Security teams should begin by reviewing all process and command-line execution of schtasks.exe and at.exe, ranking the results from most common to least. Where possible, you should also try to collect all Scheduled Tasks across an environment using a tool such as OSQuery or Sysinternals Autoruns. Again, you’ll want to organize the associated processes and command-lines by occurrence, so that you understand which tasks occur often and which do not.

You’ll want to take a close look at less commonly used command-line switches for schtasks.exe. One example might be /XML. It’s entirely possible that searching for this in your environment may turn up nothing, but, if you do happen to find it, you’ll want to examine the contents of that XML file.

It’s also a good idea to monitor for tasks that spawn at seemingly strange intervals. For example, something like /sc minute /mo 20, which means that the task will run every 20 minutes, should be viewed with suspicion. There are few legitimate reasons that a task would need to run every 20 minutes—or at any other fixed interval.

Tracking for Scheduled Tasks that load binaries (.exe, for example) or scripts (.ps1, .vbe, and .vbs to name a few) from suspicious paths is a quick win for detection. The default execution path for schtasks.exe or at.exe is c:\windows\system32\ and c:\windows\syswow64\, so any deviation from those should raise concerns that the binary has been moved. Also consider monitoring for suspicious execution paths such as \appdata\ and \windows\tasks\, as it is pretty suspicious for a Scheduled Task to execute from either of these paths.

As is the case with Masquerading, you should review binary metadata. Binary metadata includes a field for internal names, which are often good indicators of a binary’s true identity. It’s a good idea to raise an alert when it appears that schtasks.exe or at.exe have been renamed.

Ultimately, you’ll want to understand what parent processes normally spawn Scheduled Tasks. Is it normal in your environment for SYSTEM to create a task? If the answer is “no,” then you’ll want to consider alerting on that behavior. Similarly, you may want to track when users spawn schtasks.exe from PowerShell or cmd.exe.

Weeding out false positives

We should note that tracking schtasks.exe command-line parameters may generate a high volume of data and false positives at first. By default, Windows runs a number of common tasks. The same is essentially true at the organizational level, with application and server-specific tasks. Once you identify and tune out the normal, deviations are pretty reliable indicators of maliciousness.

Some automated software deployment utilities (e.g., SCCM, Kaseya) may utilize Scheduled Tasks to deploy software or keep systems up to date—and may contribute to high false positive rates.


Getting Started With Atomic Red Team

Start testing your defenses against Scheduled Task using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View Atomic tests for T1053: Scheduled Task. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using Command Prompt:
SCHTASKS /Create /SC ONCE /TN spawn /TR cmd.exe /ST 21:00
Useful telemetry will include:
Data sourceTelemetry
Data source:

Process monitoring



Data source:

Process command line


“/SC ONCE”, “cmd.exe”, “/ST 21:00”

Data source:

Registry monitoring


for storage of scheduled task details

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.

Michael Haag
Director, advanced threat detection and research
The detection strategies in this section were brought to you by Michael Haag! Michael has more than a decade of experience in security architecture and operations. His specialties include advanced threat hunting and investigations, testing, and technological evaluations and integrations. At Red Canary, he works alongside customers to address their organization’s unique security needs with strategic vision, research, and technical expertise.
The detection strategies in this section were brought to you by Michael Haag! Michael has more than a decade of experience in security architecture and operations. His specialties include advanced threat hunting and investigations, testing, and technological evaluations and integrations. At Red Canary, he works alongside customers to address their organization’s unique security needs with strategic vision, research, and technical expertise.
Back to Top