Windows Task Scheduler, previously known as Scheduled Tasks, is a powerful job scheduler built into Microsoft Windows. Its primary function is to launch computer programs or scripts at specific times or intervals predetermined by the user. Introduced as System Agent in Microsoft Plus! for Windows 95, Task Scheduler Windows has evolved into a core component of the Windows operating system. In fact, it serves as the foundation for the Windows PowerShell scheduled jobs feature, which was introduced in PowerShell v3.
Comparable to the cron utility in Unix-like operating systems, Task Scheduler offers administrators a legitimate tool for automating various processes. Tasks can be scheduled to run at specific times, triggered when a certain event occurs, or executed repeatedly or once. With its user-friendly graphical user interface (GUI), the Windows Task Scheduler allows users to run scripts, launch applications, and perform various tasks both locally and remotely from another system.
Scheduled tasks are not limited to a single operating system, making them versatile and widely applicable across different environments. However, it’s essential to be aware of the location of scheduled tasks in the Windows Registry. The registry key for scheduled tasks is located in the SOFTWARE registry hive. This knowledge becomes particularly relevant when discussing potential abuse by attackers seeking to evade detection.
Task Scheduler Versions
Task Scheduler is available across multiple Windows versions, ensuring broad compatibility and accessibility for users.
Task scheduler Windows typically include these versions and have Windows specifications such as task scheduler Windows 10:
- Windows 10
- Windows 8.1
- Windows 8
- Windows 7
- Windows Vista
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008
Task Scheduler 1.0
Client requires Windows Vista or Windows XP. Server requires Windows Server 2008 or Windows Server 2003.
Task Scheduler 2.0
Client requires Windows Vista or later. Server requires Windows Server 2008 or later.
How MITRE Attack Mapping & CIS Control Mapping Fortify Your Network
Windows Task Scheduler: A Target for Malicious Cyber Attacks
Windows scheduled task techniques vary across several tactics of the MITRE ATT&CK framework including execution, persistence, and privilege escalation. Because of this, a defender's approach to defending against attacks involving LotL tools must be multi-faceted. There are several ways an attacker can abuse scheduled tasks. Many of them are legitimate use cases such as:
- Using scheduled tasks to initiate infections.
- Setting up scheduled tasks under the SYSTEM account to achieve persistence and enable lateral movement.
- Bypassing User Access Control (UAC) through Task Scheduler by selecting “Run with highest privileges.”
- Evading detection by disguising the process as trusted or signed.
- Evading detection by deleting the Security Descriptor (SD) registry value using SYSTEM privileges.
Attackers can also leverage various parameters with the "schtasks" command, such as change, delete, end, query, run, or create. These commands can be manipulated by attackers, disrupting the normal process of executing the tasks and potentially leading to system compromise. These seemingly harmless parameters grant attackers significant power to inflict damage on a system or network.
Task Scheduler Windows vulnerabilities and threats
From privilege escalation to the deployment of persistent malware, understanding task schedular Windows vulnerabilities is crucial for increasing the security of Windows-based systems. This includes vulnerabilities in the task scheduler library itself, which can be exploited if not properly secured.
- Windows Task Scheduler Elevation of Privilege Vulnerability (CVE-2023-21541) The successful exploitation of this vulnerability could provide an attacker with SYSTEM privileges.
- Task Scheduler Vulnerability (CVE-2010-3338) a vulnerability that affects Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2
- Silk Typhoon (previously HAFNIUM ) continues to be tracked with new activity being uncovered. The Zoho ManageEngine Rest API authentication bypass vulnerability was detected through collaboration between the Microsoft Detection and Response Team (DART) and the Microsoft Threat Intelligence Center (MSTIC) in a multi-stage attack scenario.
Mitre Attack techniques utilizing Windows task scheduler
Adversaries exploit the Windows Task Scheduler to perform task scheduling for executing malicious code, both initially and in a recurring manner. Accessing the Task Scheduler can be achieved through various means in Windows. The schtasks utility allows direct command-line execution, while the GUI interface within the Administrator Tools section of the Control Panel provides another access point. Additionally, adversaries have been known to use a .NET wrapper for the Windows Task Scheduler or leverage the Windows netapi32 library to create scheduled tasks.
The deprecated at utility could also be abused by adversaries (ex: At), though at.exe can not access tasks created with schtasks or the Control Panel.
To establish persistence, adversaries may utilize Windows Task Scheduler to run programs during system startup or at scheduled intervals. Furthermore, they may abuse it for remote execution as part of lateral movement or to execute processes under the context of a specific account, such as SYSTEM. Similar to System Binary Proxy Execution, adversaries exploit the Windows Task Scheduler to potentially mask one-time execution under signed or trusted system processes.
To evade detection, adversaries resort to creating “hidden” scheduled tasks that are not visible to defender tools and manual queries used for enumerating tasks. One method involves deleting the associated Security Descriptor (SD) registry value, which requires SYSTEM permissions for deletion, thus hiding the task from schtasks /query and the Task Scheduler. Alternatively, adversaries may employ alternate techniques to conceal tasks, such as modifying metadata like the Index value within associated registry keys.
Hardening and security configuration of Windows task scheduler
Hardening the Windows Task Scheduler offers significant business benefits. By automating tasks and bolstering security, companies can drive efficiency, save time, and reduce costs associated with potential security breaches. This streamlined approach ensures consistent system performance, compliance with regulations, and a competitive edge in the market. It also allows strategic resource allocation, scalability, and long-term savings while enhancing employee satisfaction by minimizing manual tasks and fostering innovation. Find out more about Task Scheduler Windows Hardening here.
Specifying Credentials for cyber hygiene
You can specify the security context for a task by specifying credentials in the ITaskFolder::RegisterTask or ITaskFolder::RegisterTaskDefinition (TaskFolder.RegisterTask or
TaskFolder.RegisterTaskDefinition for scripting) methods or by assigning a principal to the Principal Property of ITaskDefinition (TaskDefinition.Principal for scripting). If a principal is created for a task definition, and then the task definition is registered using the RegisterTaskDefinition method with different credentials specified in the method parameters, then the credentials specified in the RegisterTaskDefinition method will overwrite the credentials in the principal. If a principal is created for a task definition using XML, and then the XML for the task is registered using the RegisterTask method with different credentials specified in the method parameters, then the credentials specified in the RegisterTask method will overwrite the credentials in the principal.
You specify a user account or group when registering a task or specifying the principle for a task. The security context of the user account or group is used for the security context of the task. In these methods and properties, you also define the logon type. The logon type is defined by one of the constants in the TASK_LOGON_TYPE enumeration.
Tasks registered with the TASK_LOGON_PASSWORD or TASK_LOGON_S4U flag will only launch if the specified user has the Logon as Batch privilege enabled. Administrators and Backup Operators group users have this privilege enabled by default.
It is important to ensure that as part of the credential defnition and configuring the operating system "Log os as a batch job" is set to 'Administrators'. Task Scheduler is often used for administrative purposes. Therefore, its use should be restricted in high-security environments to prevent the misuse of system resources or to prevent attackers from launching malicious code after gaining user-level access to a system. Note that if the enterprise is using optional components (e.g., ASP.NET, IIS7), it may be necessary to assign this user right to additional accounts that are required by those components. If they are not assigned these rights, the components may not be able to run, which can impact functionality.
Ultimate Guide to Hardening User Account Control Settings & Boosting Windows Security (2024)
User Account Control (UAC) Security for Tasks
User Account Control (UAC) lets users exercise general functionality such as running programs and saving and modifying data without exposing administrative privileges. This mechanism plays a crucial role in the local security architecture, particularly in regulating task privileges and execution rights. By default, a task runs with low level privileges when UAC is turned on. Tasks can specify that they will run with elevated privileges or low privileges by setting a privilege level from the TASK_RUNLEVEL_TYPE enumeration for the RunLevel property of IPrincipal (Principal.RunLevel for scripting). The value of the RunLevel property determines the privilege level at which a task’s actions will be run. If a task’s actions must have elevated privileges to run, then you must set the RunLevel property to TASK_RUNLEVEL_HIGHEST. If a task is registered using the Administrators group for the security context of the task, then you must also set the RunLevel property to TASK_RUNLEVEL_HIGHEST if you want to run the task. If a task is registered using the Builtin\Administrator account or the Local System or Local Service accounts, then the RunLevel property will be ignored. The property value will also be ignored if User Account Control (UAC) is turned off. The value of the RunLevel property doesn’t affect the permissions needed to run or delete a task.
Configure who can write, read, update, delete a Windows scheduled task
The DACL file of the task can be changed, in which case the DACL defines which users have file write, read, execute, and delete permission. To set permissions for a task file, use the IRegisteredTask.SetSecurityDescriptor method or set the security descriptor when you register the task using the RegisterTask or RegisterTaskDefinition methods.
A user must have WriteDAC permission in addition to the read/write permissions to update a task if the task update requires a change to the DACL for the task.
Keep in mind that by default, a user who creates a task can read, update, delete, and run the task. Members of the Administrators group or the SYSTEM account can read, update, delete, and run any tasks. Members of the Users group, the LocalService account, and the NetworkService account can only read, update, delete, and run the tasks that they have created.
Reduce the Ability to Raise the Priority of a Scheduled Task
Raising the priority of a task to "realtime" can cause a DOS attack against the system/application causing operational damage. Therfore it is highly recommended to take the following steps and reduce the ability to raise the priority of scheduled tasks.
Describes the best practices, location, values, policy management, and security considerations for the Increase scheduling priority security policy setting.
Verify that only Administrators and Window Manager\Window Manager Group have the Increase scheduling priority user right assigned to them.
Remove/Limit Access to "schtasks.exe"
When a scheduled task is created, it is assigned a priority. This priority can be modified, authorized or unauthorized, to change it to a higher or lower priority. If a user, who is given this permission, increases the priority level of a process (e.g., to Real-Time), this would leave little processing time for all other processes and could lead to a Denial of Service (DoS) attack. To reduce the chance of an attacker modifying the priority of a scheduled task to a higher level, a Group Policy setting can be configured, under "Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Increase scheduling priority," to allow only administrators to change this priority level
Restrict Access to "at.exe"
To mitigate risks associated with "at.exe", it is recommended to implement the following-
- Control User Permissions: Limiting access to “at.exe” involves managing user permissions. By default, regular users do not have permissions to access or use “at.exe.” Administrators, on the other hand, typically have the necessary permissions to utilize “at.exe.” It is crucial to ensure that only trusted individuals with appropriate privileges have access to this utility.
Group Policy Settings: To restrict access to “at.exe,” administrators can modify Group Policy settings. Specifically, the Group Policy setting “Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Access this computer from the network” can be adjusted to limit access to “at.exe” only to authorized users or groups.
Auditing Windows tasks scheduler
When it comes to the Windows OS, events are generated and stored in event logs for storage and review, including those associated with scheduled tasks. The Windows Task Scheduler Operational Event Log (“%SystemRoot\Windows\System32\winevt\Logs\Microsoft-WindowsTaskScheduler%4Operational.evtx”) stores these events, as depicted in Figure 8.
As mentioned earlier, all activity related to scheduled tasks is logged in either the Windows Task Scheduler Operational Event Log or the Windows Security Event Log. Once the GPO setting for auditing object access events is activated, the system begins logging events. Here are some Event IDs that are useful to monitor during or before an incident:
- Windows > Task Scheduler > Operational Event Log:
-
- 100: A scheduled task was started
- 4698: A scheduled task was created
- 101: A scheduled task has failed
- 4699: A scheduled task was deleted
- 102: A scheduled task has completed
- 4700: A scheduled task was enabled
- 106: A scheduled task was registered
- 4701: A scheduled task was disabled
- 107: A scheduled task triggered on scheduler
- 4702: A scheduled task was updated
- 108: A scheduled task triggered on event
- 110: A scheduled task triggered by user
- 111: A scheduled task was terminated
- 141: A scheduled task was updated
- 142: A scheduled task was deleted
It’s important to note that Windows does not enable auditing for these events by default. The mentioned GPO must be enabled to ensure event logging. Additionally, enabling this auditing feature may result in a large number of events being generated. Enterprises should ensure sufficient log storage capacity and establish retention policies. Storage requirements and retention policies will vary for each enterprise. Furthermore, it’s worth considering that scheduled tasks can also be created using PowerShell or Windows Management Instrumentation (WMI), which may require additional logging. CIS Controls provides separate documentation for protecting against attacks utilizing PowerShell and/or WMI.
