In April 2022, Microsoft released a report detailing how the “Tarrask” malware manipulated the Security Descriptor of Scheduled Tasks as a defense evasion technique to hide malicious scheduled tasks from discovery using traditional audit tools such as Autoruns, “schtasks /query”, and the Windows Task Scheduler GUI.
To help defenders further understand the security implications of manipulating the SD registry value for a scheduled task, ARC Labs performed further research to expand on potential techniques to hide scheduled tasks that evade the current detection guidance and highlight additional telemetry gaps in traditional auditing mechanisms.
Key Insights:
- Assigning a valid SDDL value denying read access to the task is an effective method to hiding a task from common audit tools without triggering the current detection guidance from Microsoft.
- Creating the requisite registry keys in Windows will bypass Windows Event Log telemetry for scheduled task creation.
- ARC Labs identified an issue within Windows 10, which enables registering a scheduled task while evading Windows registry auditing and Windows Event Log telemetry.
- ARC Labs developed PowerShell script to aid defenders in auditing a system for scheduled tasks which suspicious security descriptors.
“Tarrask” Malware Evasion Overview
To summarize the Microsoft findings on the “Tarrask” evasion techniques:
The “Tarrask” malware leverages a scheduled task and removes the SD value located within “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\{taskname}”. The SD value defines the Security Descriptor of the task setting the permissions for the task. The SD value is represented as the binary representation of the Microsoft Security Descriptor Definition Language settings which is defines the effective access control list (ACL).
When the malware deletes the SD value, common scheduled task auditing tools such as “schtasks.exe”, Autoruns, and Task Scheduler are unable to read the details of the task due to a lack of permissions.
Demonstrating this evasion technique is straightforward as it only requires acquiring adequate privileges (SYSTEM) to delete the SD value within the Windows registry.
Scheduled Task Creation Telemetry Sources:
When a new scheduled task is registered with Windows the following registry keys are created:
- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\TASK_NAME
- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}
- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\{Task Type}\{GUID}
Where task type is associated with the task trigger. For example, if the task is set to trigger during a logon event, a new registry key will be created in the following location:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Logon\{GUID}
In addition to the registry modifications, when a new scheduled task is created a corresponding XML file is created within “%windir%\system32\tasks”.
Finally, two Windows Event Log entries can be leveraged to detect when a new scheduled task is created (the following logs are not enabled by default):
- Security Event ID 4698
- Task Scheduler Operational Event ID 106
Evading Windows Event Monitoring for Scheduled Task Creation:
During ARC Labs’ research, it was noted that creating a scheduled task by directly creating the appropriate keys and values to the registry without the SD value was an effective evasion technique to avoid any events written to the Security or Task Scheduler Operational logs related to scheduled task creation. ARC Labs observed that in Windows 10, the task was immediately available for execution however in Windows 11, the task was would not execute until the Task Scheduler service or target host was restarted.
Evading Registry Monitoring:
Microsoft released a Sentinel detection ScheduledTaskHide which relies on the built-in registry auditing within Windows which generates EID 4657 in the Security log when Object Value Name equals SD and the Object Name contains “Schedule\TaskCache\Tree”.
Through ARC Labs’ research, it was revealed that importing a task that already has the SD value removed or creating the requisite registry entries (like in the previous PowerShell example) excluding the SD value, is an effective bypass to avoid detection through Microsoft’s guidance on monitoring EID 4657 for deletion of the SD value. Additionally, ARC Labs observed that on Microsoft Windows 10, importing a task will bypass registry monitoring completely.
After importing a task from another machine to the target machine, the task executed as expected during the next logon event.
Detecting Scheduled Task Evasion via SD value removal:
As mentioned earlier, Microsoft released a Sentinel detection to alert defenders when the SD value is removed from the registry. ARC Labs observed that while registry auditing will generate the requisite telemetry to detect on SD removal activities, to capture the events, the auditing configuration must be set to audit “Set Value” and cannot be scoped to a particular value name, which will create an event any time, any value is set or modified including when scheduled tasks are created or deleted for legitimate purposes. This could create issues for organizations that must operate within telemetry collection limits.
ARC Labs did find some success leveraging Microsoft’s Sysmon utility with a custom rule set to detect the removal of the specifically the SD value from within the Scheduled Task registry key and confirmed that the rule did not fire when removing scheduled tasks for legitimate purposes such as using the task scheduler GUI. The following Sysmon rule is a sample of real time monitoring specifically for removal of the SD value.
It’s important to note that in the EID 4657 and Sysmon registry monitoring events both the full path of the process and username is captured in the event. By default, only the SYSTEM account has privileges to modify data within the scheduled task registry key.
Microsoft Windows offers various methods to remove registry values using built in tools such as as reg, PowerShell, WMI, and regedit however it is possible to manipulate the registry directly through the Windows API which is likely the method the attacker leveraged in the Microsoft example as the SD value was deleted through the execution of an executable named “winupdate.exe”.
Depending on the environment, modifications to the SD value may occur for legitimate reasons. If defenders implement registry monitoring as part of their detection strategy, ARC Labs recommends baselining the environment paying close attention to the process names which commonly modify the SD value.
Detecting via SD Value Enumeration:
In the Microsoft post one of the pieces of guidance for detecting the SD evasion technique is to enumerate all tasks under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree” looking for any tasks which do not have a SD value.
Enumerating tasks within the Tree key without an SD value is a straightforward process and can be done with a single PowerShell command.
However, hiding the scheduled task from the Task Scheduler GUI, Autoruns, and schtasks can be achieved via setting the SD value to a null value or populating the SD value with fake binary data.
Identifying scheduled tasks with null or fake SD values again can be achieved through PowerShell using the length and Win32_SecurityDescriptorHelper class to convert to evaluate the binary data into human readable SDDL. If the SD data cannot be properly converted into a valid SDDL, it could be an indication that the SD value has been tampered with.
Identifying null SD values can be achieved by evaluating the length of the content within the SD value:
gci -Path “REGISTRY::HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\” -recurse | where {$_.GetValue(“SD”).Length -eq 0}
Converting binary data to human readable data with PowerShell requires passing all the binary data to the Win32_SecurityDescriptorHelper class:
$SDData =(Get-Item -Path “PATH TO TASK REGISTRY KEY “).Getvalue(“SD”);
([WMIClass]”Win32_SecurityDescriptorHelper”).BinarySDToWin32SD($SDData).Descriptor;
If the data stored in the SD value is not a valid SDDL, the Descriptor property will be null.
Evading SD Value Enumeration
To research additional methods of stealth regarding SD value, ARC Labs researched applying legitimate SDDL data to the SD value that would continue to evade the Task Scheduler GUI, Autoruns, and schtasks as well as, evade enumerate the existing detection guidance from Microsoft and others through enumerating task registry keys with missing or null SD values.
At its core, removing the SD value from the registry succeeds as an evasion technique because it removes the permissions to read the properties of the task and display it via common audit tools. ARC Labs observed that the same results could be achieved by assigning a valid SDDL to the task which denies read access to all accounts.
Using PowerShell, it is possible to retrieve the SDDL data from a legitimate task in human readable format from the SD binary data. If we consider, the returned data from the legitimate task, we can see that the SDDL is broken down as the owner and then the access permissions. If you want to learn more about the specific permissions or how SDDL works refer to the Microsoft documentation.
For the purposes of this research, we can assess the SDDL data to covert to the following:
O:BAG:S-1-5-21-1783132455-1203733024-277869146-513D -> Owner
(A;ID;0x1f019f;;;BA) -> Builtin\Administrators Allowed Access
(A;ID;0x1f019f;;;SY) -> NT AUTHORITY\SYSTEM Allowed Access
(A;ID;FA;;;BA) -> Builtin\Administrators Allowed Access
(A;;FR;;;S-1-5-21-1783132455-1203733024-277869146-1001) -> User Admin Account Allowed Access
To evade visibility by schtasks, Autoruns, and the Task Scheduler GUI while setting a valid SDDL within the SD value simply switch the A setting to D. For example, “(A;ID;0x1f019f;;;BA)” becomes “(D;ID;0x1f019f;;;BA)”.
The following PowerShell commands, take the SDDL data with the appropriate deny permissions and set it as the SD value within the “FakeSDValueTest” and the result is a task.
Combined with importing the task, it’s possible to register a task while bypassing the Security and Task Scheduler logs for a new task created, hide the task from schtasks, Autoruns, and the Task Scheduler GUI, evade registry detection for removing the SD value, and on Windows 10, evaded registry monitoring completely.
ARC Labs Detection Guidance
For organizations with Windows 10 deployed, consider implementing a registry monitoring solution that can detect registry changes when tasks are imported.
Monitor for SYSTEM account making changes to the scheduled task registry keys using suspicious executables or living off the land tools such as powershell.exe, reg.exe, wmiprsve.exe, and regedit.exe.
Monitor the windows event log for previously unseen scheduled tasks executing on endpoints that do not have a corresponding scheduled task creation event. Note: For this to be effective, defenders will need the ability to collect EIDs 129, 106, and 4698 and determine what task has not been observed within the environment previously.
Monitor for behaviors of BYOVD or common privilege escalation tools such as psexec.exe and nircmd.exe which enable a user to acquire SYSTEM level privileges.
Monitor for the SYSTEM account spawning command interpreters with the capability to restart the Task Scheduler service such as sc.exe, powershell.exe, psservice.exe, and net.exe.
For incident responders who often leverage tools that are impacted by manipulating the SD value in the registry, it could be worth enumerating and decoding the task actions data from the registry to identify suspicious scheduled task actions with the following PowerShell command.
gci -path “hklm:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\” | %{$action = (Get-Item -Path “REGISTRY::\$_”).Getvalue(“Actions”);[System.Text.Encoding]::Unicode.GetString($action);}
Considering the different mechanisms to evade detection through removal or manipulation of the SD value within the registry, ARC Labs crafted the following script to enumerate all tasks in the scheduled task registry key and check for missing SD values, null SD values, and checking the SDDL for permissions which enable evasion such as removing the SYSTEM account or explicitly denying SYSTEM or Administrators through the DACL.
To aide defenders in developing a scheduled task auditing capability with considerations for SD manipulation, ARC Labs developed PowerShell script named “hunt_hidden_tasks” which is available on the ARC Labs GitHub page here:
https://github.com/BinaryDefense/HiddenTaskHunter
