Skip Navigation
Get a Demo

Sub-Technique T1053.005

Scheduled Task

Scheduled tasks offer adversaries a fantastic opportunity to inconspicuously conduct an array of malicious activity, ranging from execution to persistence.

Pairs with this song

Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2022.


Analysis Icon


Why do adversaries use scheduled tasks?

As is the case with every legitimate Windows utility in this report, benign software and operating system functions routinely use scheduled tasks for a variety of reasons, ranging from provisioning to backup maintenance to health checks to updates and everything in between. Ultimately, you can’t turn off scheduled tasks, and therefore they enable adversaries to inconspicuously conduct an array of malicious activity.

How do adversaries use scheduled tasks?

Adversaries use scheduled tasks to accomplish two primary objectives:

  • establish persistence in an environment
  • execute processes—ideally with elevated privileges and at customized intervals

Importantly, these things aren’t mutually exclusive, and a majority of the scheduled task-leveraging threats we detect every year are set to run as SYSTEM—the most privileged account on Windows systems. By default, however, a scheduled task will run with the privilege level of the user who created it. Considering this, the following examples of scheduled task abuse are largely intended to establish persistence, but they can also do so at elevated privilege levels.

We often see adversaries using the task scheduler to execute binaries—arbitrary or native (albeit relocated)—from user-writable directories like appdata/roaming. This is ostensibly an effort to schedule the execution of code from directories that can be manipulated by other users, regardless of their privilege level. Another common behavior involves leveraging scheduled tasks to open the Windows Command Shell, generally in an effort to establish persistence or otherwise call on the command shell’s versatility to execute code or launch other system binaries. Adversaries also abuse scheduled tasks to call on regsvr32.exe to download and execute a DLL, a behavior that we’ve previously associated with crimeware like Qbot.

In terms of specific scheduled task commands that adversaries abuse, we most frequently see them execute tasks with the /Create flag of schtasks.exe to create a scheduled task, generally in the service of establishing persistence. Adversaries also abuse the /Change, /Run, /Delete, and /Query flags to change, run, delete, or display information about one or more scheduled task, respectively. Adversaries can also schedule tasks to run at set times—including any one of the 84,600 seconds in the day—or in response to a triggering event on the endpoint by leveraging the /st command. Further, they can also choose to repeat that task execution at set intervals (hourly, daily weekly, at logon, etc.). Since adversaries often reuse code, we commonly observe them scheduling their tasks to execute at the same time across each endpoint targeted by their campaigns.

Visibility icon


You can gain a lot of visibility into scheduled task activity via EDR and other security tooling. The following data sources might be useful for developing detection analytics in your environment. We’ll start with the two most important to us: process and command monitoring.

Process monitoring

Process monitoring once again is the foundation of detection for malicious scheduled task activity. You’ll want to watch for the execution of the task scheduler and the commands it calls, but you can get a lot of benefit out of process lineage as well, since it’s inherently suspicious for certain processes to spawn—or spawn from—a scheduled task.

Command monitoring

Scheduled tasks almost always fire with a corresponding command line, and scheduled task commands are invaluable for detection enrichment along with processes.

File monitoring

File monitoring can also help uproot malicious scheduled task activity. As we described above, scheduled tasks executing binaries from certain directories can signify malice. While you can sometimes gather this information from command lines, you can also get it from file monitoring.

Module loads

Module monitoring may provide supplemental detection or investigatory value in certain instances. Take for example a threat that’s using a scheduled task to execute regsvr32.exe and run a malicious DLL. Being able to observe the creation of that DLL—or inspect the contents of it—could provide valuable insights.

Collection Icon



Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Task-Scheduler/Operational log

For Windows systems, the Microsoft-Windows-Task-Scheduler/Operational log is a good source for monitoring the creation, modification, deletion, and use of scheduled tasks. Event IDs 106 and 140 record when a new scheduled task is created or updated respectively, along with the name of the task. For creation events, the user context is captured. Event ID 141 in this same log source will capture deletion of scheduled tasks.

Other logging options require enabling Object Access auditing and creating specific Security Access Control Lists (SACL). When enabled, the Windows Security Event Log will collect Event IDs 4698, 4699, 4700, and 4701 for scheduled task creation, deletion, enabling, and disabling events, respectively.

Process auditing

Enabling process auditing, including the capturing of command-line arguments via Group Policy, can also provide significant visibility into scheduled task creation and modification events. Forward these events to a SIEM or other log aggregation system and so you can regularly review them.

Get-ScheduledTask cmdlet and schtasks.exe

Another option for collecting information about existing scheduled tasks on Windows is the PowerShell Get-ScheduledTask cmdlet. If PowerShell remoting is enabled in the environment, this cmdlet can be run against remote systems to collect scheduled tasks in a somewhat scalable manner. Similarly, you can gather a great deal of information directly from schtasks.exe by running the following command:

schtasks.exe /query /fo csv /v

Icon-threat detection


We have approximately 35 detection analytics mapped to Scheduled Task. The following section offers a synthesis of strategies we’ve deployed to develop detection coverage for malicious and suspicious scheduled task activity.

Note: These detection analytics may require tuning.

Processes behaving improperly

We routinely detect adversaries abusing the Windows Task Scheduler’s /create command to execute other processes and gain persistence or delay the execution of a payload. Some of the usual suspects include cmd.exe, powershell.exe, regsvr32.exe, rundll32.exe, and mshta.exe. Given this, and depending on the nature of your environment, developing detection logic that looks for scheduled tasks running with the /create flag and a reference to the above processes in the command line might help uncover malicious or suspicious activity. Word of caution: this will almost certainly require tuning and exclusions for legitimate software.

process == schtasks.exe
command_line_includes ('/create') && ( 'cmd.exe' || 'powershell.exe' || 'regsvr32.exe' || 'rundll32.exe' || 'mshta.exe')

Scheduled tasks with suspicious network connections

Adversaries occasionally leverage scheduled tasks to reach out to external domains and download arbitrary binaries on a set or recurring schedule. Like most of the adversary actions described in this section, this is a way of establishing persistence. Keep an eye out for scheduled tasks running with the /create command and a reference to a URL in the command line.

process == schtasks.exe
command_line_includes ('create') && ('https://' || 'http://')

Weeding out false positives

Any detection strategy should start with a baseline understanding of what is normal in your environment. Current Windows systems commonly include more than 100 scheduled tasks by default. As more software packages are installed, they may create additional scheduled tasks for regular updates and other reasons. Knowing what these tasks are, their normal schedules, and their taskrun values will be essential to filtering expected behaviors out of your detection logic.

Testing Icon


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.005: 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 /F /SC MINUTE /MO 3 /ST 07:00 /TN CMDTestTask /TR "cmd /c date /T > C:\Windows\Temp\current_date.txt"

schtasks /Delete /TN CMDTestTask /F

What to expect

Running this test will create a scheduled task named CMDTestTask that runs cmd.exe every three minutes.

Useful telemetry will include:

Process monitoring


An schtasks.exe process will start. When the CMDTestTask task is triggered, cmd.exe will launch as a child process of svchost.exe (command-line: C:\WINDOWS\system32\svchost.exe -k netsvcs -p).


EDR, the Task-Scheduler Operational log, the Get-ScheduledTask cmdlet, and schtasks.exe should collect relevant telemetry.


Command monitoring


Command-line logging will capture the context of what is executed.


EDR, the Task-Scheduler Operational log, the Get-ScheduledTask cmdlet, and schtasks.exe should collect relevant telemetry.


File monitoring


Task XML registration is written to %windir%System32\Tasks\CMDTestTask by svchost.exe (command-line: C:\WINDOWS\system32\svchost.exe -k netsvcs -p).


EDR, the Task-Scheduler Operational log, the Get-ScheduledTask cmdlet, and schtasks.exe should collect relevant telemetry.

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.

Back to Top