Technique T1053.005

Scheduled Task

Leveraging the primary task-scheduling component of Windows, this technique allows adversarial persistence and execution behaviors to blend in with routine activity emanating from native tools and third-party software.

#4

Parent technique rank

27.6%

Organizations affected

2740

Confirmed threats

Analysis

Why do adversaries use Scheduled Task?

Adversaries use scheduled tasks to accomplish two primary objectives: maintaining access and executing processes in a specific user context, typically one with elevated privileges. As a wide variety of legitimate software uses scheduled tasks for an even wider variety of legitimate reasons, malicious use often blends in with innocuous use. Scheduled tasks are a functionally necessary component of the Windows operating system that can’t just be turned off or blocked.

How do adversaries use Scheduled Task?

Execution and persistence

Of the approximately 3,000 unique schtasks.exe executions in our detection set, 99.5 percent included the /Create flag, which makes sense for adversaries wanting to establish persistence. Closer inspection of the remaining events reveals one obfuscated instance of /Create, as seen in the following image, which comes from a confirmed Dridex detection:

Scheduled Task detection

Let this adversary’s use of both Scheduled Task and Obfuscated Files or Information serve as a general reminder that these techniques rarely walk alone—your scheduled task detections need to account for obfuscation techniques.

After /Create, /Change is the second most common flag passed to schtasks, followed in order by /Run, /Delete, and /Query.

Scheduled tasks can run at a set time or in response to a triggering event on the endpoint. Adversaries can choose any one of the 86,400 seconds in a day to execute their tasks, but due to code reuse, they often schedule their executions for the same time across each endpoint targeted by their campaigns. This is an area where code reuse may play to the defender’s advantage. In our data set, 86 percent of the scheduled task creation events designated specific start times by passing time-of-day arguments to the start time (/ST) parameter. Scheduled task creation events that don’t specify otherwise default to starting at the task’s creation time. Scheduled task activity from detections associated with Blue Mockingbird contributed significantly to the prevalence of this technique.

The following image illustrates scheduled task start times (in UTC) across the environments we monitor:

Scheduled Task start times

In addition to specifying the start time for a given scheduled task, adversaries can use the /SC (Schedule) flag in combination with one of the values in the Y-axis of the chart below (Daily, Minute, etc.) to set the frequency of the task’s execution.

Scheduled Task frequency execution

Note that schedule values can be modified to the scheduled frequency of execution. In other words, just because a task is created with /SC Minute doesn’t mean it will run every minute. If the task is created with the /MO flag, its arguments will modify the frequency of execution. So if /SC Minute and /MO 67 are present when the task is created, it will execute every 67 minutes. Though /MO isn’t commonly observed, it is worth mentioning because of the impact it has on frequency of execution.

The /MO frequency modifier can also be applied to any Onevent scheduled task. Onevent frequencies instruct the scheduled task to execute in response to an event on the endpoint. When Onevent is used, the argument passed to the /MO flag will be an XPath event query string. In 2020, we found seven instances of /SC Onevent, all of which passed the following XPath event query string to the /MO flag:

*[system[provider[@name='microsoft-windows-security-auditing'] and eventid=4801]]

This XPath event query string will match any events in the Windows Security Event Log with Event ID 4801, which may be logged when the workstation is unlocked, depending on the applicable audit policy.

Privilege escalation

In addition to providing adversaries with a means of maintaining access to environments, scheduled tasks can also run under a specified user context. In our data, 81 percent of the created tasks were set to run as SYSTEM—the most privileged account on Windows. When a scheduled task is created without specifying a user context, it will run in the context of the user who created the task. This is the second most common configuration we observed.

Definition

Detection

Collection requirements

Windows event logs

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 and command-line monitoring

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.

Forwarding these events to a SIEM or other log aggregation system and regularly reviewing the events through automation can facilitate detection of suspicious activity.

Other sources

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

Detection opportunities

We commonly observe the following binaries in malicious scheduled task execution:

  • cmd.exe
  • powershell.exe
  • regsvr32.exe
  • rundll32.exe

For defenders and hunt teams, if you find one malicious scheduled task in your environment, consider using properties of that event—task name, start time, task run, etc.—as elements in your hunt or even detection logic. Use available tooling to collect scheduled tasks from across your enterprise and search for specific properties that match the known malicious scheduled task (i.e., recurring start times of unusual scheduled tasks across endpoints). Understanding what is normal in your environment is a tremendous boon for identifying suspicious scheduled task activity.

Tasknames and Taskruns

Two elements of scheduled tasks that may lend themselves to threat hunting and/or detection are taskname and taskrun, which are passed arguments to the /TN and /TR flags respectively,

Tasknames vary widely in our data set. Though Blue Mockingbird dominated our dataset with the taskname Windows Problems Collection, other threat actors and malware families commonly use GUIDs, as is the case with QBot, or names that attempt to blend in with seemingly legitimate system activity (e.g., AdobeFlashSync, setup service Management, WindowsServerUpdateService, etc.). Random strings between seven and nine characters are also common. It’s worth looking out for scheduled task executions containing the taskname or /TN value and any of the above examples. These won’t always be malicious, but with some baselining, you should be able to sort normal and benign from unusual and suspicious.

Taskrun values, on the other hand, specify what should be executed at the scheduled time. Expect attackers to try and blend in here as well, with LOLBINs or by naming their on-disk malware to resemble legitimate system utilities. Blue Mockingbird dominated once again, with more than 2,000 scheduled tasks with a taskrun value of regsvr32.exe /s c:\windows\system32\wercplsupporte.dll. Searching for execution of scheduled tasks with wercplsupporte.dll in the taskrun is a viable method of detecting Blue Mockingbird, but don’t confuse the above DLL with the legitimate wercplsupport.dll in the same directory.

Of all the properties in a scheduled task, taskrun is probably the most critical to scrutinize. If you see a strange binary, investigate it. Any taskrun value that points to a script deserves a closer look, as adversaries may modify an existing benign script by adding malicious code to it. Building automation to return cryptographic hashes of these scripts and monitoring them for changes may be useful in detection efforts.

Scheduling tasks without schtask.exe

Adversaries can create or modify tasks without calling schtasks.exe or taskschd.msc directly with the help of COM objects. Therefore, monitoring for file creation and modification events in \Windows\System32\Tasks and \Windows\SysWow64\Tasks directories may provide added value in identifying interesting activity. This may be particularly useful on critical systems where scheduled tasks should be relatively static.

Unusual module loads

Monitoring for image loads—specifically of \Windows\System32\taskschd.dll by processes that wouldn’t normally load that DLL like Excel or Word—may indicate that a macro is creating or modifying a scheduled task.

Weeding out false positives

Any detection strategy should start with a baseline understanding of what is in your environment normally. 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 them out of the review process.

Testing

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.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:
Data sourceTelemetry
Data source:

Process monitoring

Telemetry:

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).

Data source:

Process command-line parameters

Telemetry:

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

Data source:

Windows Registry

Telemetry:

The HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\CMDTestTask registry key and various sub-keys and values will be created by svchost.exe (command-line: C:\WINDOWS\system32\svchost.exe -k netsvcs -p).

Data source:

File monitoring

Telemetry:

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

Data source:

Windows event logs

Telemetry:

Microsoft-Windows-TaskScheduler/Operational (not enabled by default) Event ID:

  • 106: Task registration
  • 129: Task process creation
  • 100: Task started
  • 102: Task completed
  • 107: Task triggered on scheduler
  • 200: Action started
  • 201: Action completed

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.

Tyler Bohlmann
Incident Handler
Tyler has been working in information technology since 2012. He started his career as a desktop support technician working for small MSPs. He then studied penetration testing, which got him interested in information security. At Red Canary, Tyler helps customers understand threats within their environment and how to leverage their EDR platform to improve their security program.
Tyler has been working in information technology since 2012. He started his career as a desktop support technician working for small MSPs. He then studied penetration testing, which got him interested in information security. At Red Canary, Tyler helps customers understand threats within their environment and how to leverage their EDR platform to improve their security program.
Jason Killam
Detection Engineer
Jason works on Red Canary's Cyber Incident Response Team (CIRT) as a detection engineer. Prior to that, Jason worked as an incident responder for security teams in the financial sector. Outside of work, he obsesses over space, rockets, posting malware indicators on twitter, and building lego sets.
Jason works on Red Canary's Cyber Incident Response Team (CIRT) as a detection engineer. Prior to that, Jason worked as an incident responder for security teams in the financial sector. Outside of work, he obsesses over space, rockets, posting malware indicators on twitter, and building lego sets.