The Windows Task Scheduler runs programs at startup, at a set time or on a repeating schedule. MITRE tracks its abuse as Scheduled Task (T1053.005), a sub-technique of Scheduled Task/Job. The tactics are Execution, Persistence and Privilege Escalation, and the platform is Windows.
It is a favorite because it is built in, it supports remote creation and it can run as SYSTEM. It is also one of the best documented places to look, which gives defenders plenty to work with.
How attackers use it
MITRE lists several ways to create a task. The schtasks utility can be run from the command line, or the Task Scheduler can be opened in the GUI under Administrator Tools. Some adversaries use a .NET wrapper for the Task Scheduler, the Windows netapi32 library or Windows Management Instrumentation (WMI). MITRE also names the PowerShell cmdlet Invoke-CimMethod, which uses the WMI class PS_ScheduledTask to create a task from an XML path.
Once a task exists, MITRE describes three uses:
- Persistence, by running programs at system startup or on a schedule.
- Remote execution as part of lateral movement.
- Running a process under a chosen account, such as SYSTEM.
As with the parent technique, tasks can also mask one time execution under signed and trusted system processes.
Hidden tasks
The part defenders most often miss is hiding. MITRE explains that an adversary may create hidden tasks that do not show up in defender tools or manual queries. Specifically, a task can be hidden from schtasks /query and from the Task Scheduler by deleting the associated Security Descriptor (SD) registry value. MITRE notes that deleting that value requires SYSTEM permissions. Other approaches alter metadata, such as the Index value, in the related registry keys.
The lesson is that listing tasks through the scheduler is not enough. If the only source of truth is the tool an attacker has tampered with, the answer will be incomplete.
How to detect it
MITRE's analytic for Windows covers the creation, modification or deletion of scheduled tasks through Task Scheduler, WMI, PowerShell or API based methods, followed by execution from svchost.exe or taskeng.exe. It explicitly includes hidden or anomalous tasks, especially those created under SYSTEM or suspicious user contexts.
Build your detection around these data points:
- Task creation, update and deletion events. The Windows Security log records these as events 4698, 4699 and 4702 when the relevant audit policy is on.
- Process creation for schtasks.exe, with command lines. Sysmon event ID 1 and Windows event 4688 with command line auditing both capture this.
- Registry changes under the Task Scheduler TaskCache keys, including deletion of the SD value.
- Remote creation, where the source host or account differs from the usual administrators.
- The process tree of whatever the task launches, since execution appears as a child of the scheduler service.
Compare the registry view of tasks against the scheduler's own list. A task present in one and missing from the other is a strong lead.
How to reduce the risk
MITRE lists four mitigations.
- Privileged account management. Allow only the Administrators group the Increase scheduling priority right through Group Policy: Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment.
- User account management. Limit privileges and fix escalation paths so only authorized administrators can create scheduled tasks on remote systems.
- Audit. MITRE notes that toolkits such as PowerSploit include PowerUp modules that explore systems for permission weaknesses in scheduled tasks, and that defenders can use the same idea to find those weaknesses first.
- Operating system configuration. Force tasks to run under the authenticated account instead of SYSTEM, using the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\SubmitControl and the setting Domain Controller: Allow server operators to schedule tasks, set to disabled.
Check your own environment
Read-only checks on Windows:
- PowerShell:
Get-ScheduledTask | Select-Object TaskPath, TaskName, Statelists tasks. - PowerShell:
(Get-ScheduledTask).Actions | Select-Object Execute, Argumentsshows what they run. - Command Prompt:
schtasks /query /fo LIST /vshows each task with its run as user. - Command Prompt:
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree"lists the registry side, which you can compare with the scheduler's list.
Then work through a short checklist:
- Is audit policy set to record task creation and changes?
- Do your logs capture command lines for schtasks.exe?
- Does any task run a program from a user writable folder?
- Can anyone other than named administrators create tasks on remote hosts?
If a task's program path is writable by ordinary users, fix that first. It turns a scheduled task into an escalation path.
Quick check
How can a scheduled task be hidden from schtasks /query?
By deleting its Security Descriptor registry value, which needs SYSTEM permissions, or by altering other registry metadata such as the Index value.
Which processes should you expect to see executing a task?
svchost.exe or taskeng.exe, according to MITRE's analytic. The thing to examine is what they launch.
Which mitigation helps when attackers schedule tasks on other machines?
User account management: only authorized administrators should be able to create scheduled tasks on remote systems.
Sources
- MITRE ATT&CK: Scheduled Task/Job: Scheduled Task (T1053.005)
