Scheduled Task

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.

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.

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

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.