{"id":112008,"date":"2022-04-12T09:00:00","date_gmt":"2022-04-12T16:00:00","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/?p=112008"},"modified":"2023-09-14T13:17:58","modified_gmt":"2023-09-14T20:17:58","slug":"tarrask-malware-uses-scheduled-tasks-for-defense-evasion","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2022\/04\/12\/tarrask-malware-uses-scheduled-tasks-for-defense-evasion\/","title":{"rendered":"Tarrask malware uses scheduled tasks for defense evasion"},"content":{"rendered":"\n
\n\nApril 2023 update<\/strong> \u2013 Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. HAFNIUM <\/strong>is now tracked as Silk Typhoon<\/strong>.<\/p>\n\n\n
To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy<\/strong><\/a>.<\/p>\n\n<\/blockquote>\n\n\n\n
As Microsoft continues to track the high-priority state-sponsored threat actor HAFNIUM<\/a>, new activity has been uncovered that leverages unpatched zero-day vulnerabilities as initial vectors. The Microsoft Detection and Response Team (DART) in collaboration with the Microsoft Threat Intelligence Center (MSTIC) identified a multi-stage attack targeting the Zoho Manage Engine Rest API authentication bypass vulnerability to initially implant a Godzilla web shell with similar properties detailed by the Unit42 team in a previous blog<\/a>. <\/p>\n\n\n\n
Microsoft observed HAFNIUM from August 2021 to February 2022, target those in the telecommunication, internet service provider and data services sector, expanding on targeted sectors observed from their earlier operations conducted in Spring 2021<\/a>.<\/p>\n\n\n\n
Further investigation reveals forensic artifacts of the usage of Impacket tooling for lateral movement and execution and the discovery of a defense evasion malware called Tarrask that creates \u201chidden\u201d scheduled tasks, and subsequent actions to remove the task attributes, to conceal the scheduled tasks from traditional means of identification.<\/p>\n\n\n\n
The blog outlines the simplicity of the malware technique Tarrask uses, while highlighting that scheduled task abuse is a very common method of persistence and defense evasion\u2014and an enticing one, at that. In this post, we will demonstrate how threat actors create scheduled tasks, how they cover their tracks, how the malware’s evasion techniques are used to maintain and ensure persistence on systems, and how to protect against this tactic.<\/p>\n\n\n\n
Right on schedule: Maintaining persistence via scheduled tasks<\/h2>\n\n\n\n
Windows Task Scheduler is a service that allows users to perform automated tasks (scheduled tasks) on a chosen computer for legitimate administrative purposes (e.g., scheduled updates for browsers and other applications).<\/p>\n\n\n\n
Throughout the course of our research, we\u2019ve found that threat actors commonly make use of this service to maintain persistence within a Windows environment.<\/p>\n\n\n\n
We\u2019ve noted that the Tarrask malware generates several artifacts upon the creation of a scheduled task, whether using the Task Scheduler GUI or the schtasks<\/a> command line utility. Profiling the use of either of these tools can aid investigators in tracking this persistence mechanism.<\/p>\n\n\n\n
The following registry keys are created upon creation of a new task:<\/p>\n\n\n\n
\n
- HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\TASK_NAME<\/em><\/strong><\/li>\n\n\n\n
- HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tasks\\{GUID<\/em>}<\/strong><\/li>\n<\/ul>\n\n\n\n
Figure 1. Tarrask malware creates new registry keys along with the creation of new scheduled tasks<\/figcaption><\/figure>\n\n\n\n The first subkey, created within the Tree<\/strong> path, matches the name of the scheduled task. The values created within it (Id, Index, and SD) contain metadata for task registration within the system. The second subkey, created within the Tasks<\/strong> path, is a GUID mapping to the Id<\/strong> value found in the Tree<\/strong> key. The values created within (Actions, Path, Triggers, etc.) contain the basic parameters necessary to facilitate execution of the task.<\/p>\n\n\n\n
To demonstrate the value in the artifacts generated, shown in the following figures, we have created \u201cMy Special Task\u201d which is set to execute the binary \u201cC:\\Windows\\System32\\calc.exe\u201d on a regular interval.<\/p>\n\n\n\n
Figure 2. XML file matches name of the task<\/figcaption><\/figure>\n\n\n\n Similar information is also stored within an extensionless XML file created within C:\\Windows\\System32\\Tasks<\/em>, where the name of the file matches the name of the task. This is displayed in Figure 2, where we name the task \u201cMy Special Task\u201d as an example.<\/p>\n\n\n\n
Figure 3. Extensionless XML file<\/figcaption><\/figure>\n\n\n\n Note that the \u201cActions\u201d value stored within the Tasks\\{GUID} key points to the command line associated with the task. In Figure 2, there is a reference to \u201cC:\\Windows\\System32\\calc.exe\u201d within the \u201cEdit Binary Value\u201d dialog, and there is a path referenced within the \u201c<Command>\u201d section in the extensionless XML file in Figure 3. The fact that this value is stored within two different locations can prove useful in recovering information regarding the task\u2019s purpose in the event the threat actor has taken steps to cover their tracks.<\/p>\n\n\n\n
Finally, there are two Windows event logs that record actions related to the creation and operation of Scheduled Tasks \u2013 Event ID 4698 within the Security.evtx log, and the Microsoft-Windows-TaskScheduler\/Operational.evtx log.<\/p>\n\n\n\n
Neither of these are audited by default and must be explicitly turned on by an administrator. Microsoft-Windows-TaskScheduler\/Maintenance.evtx will exist by default, but only contains maintenance-related information for the Task Scheduler engine.<\/p>\n\n\n\n
Effectively hiding scheduled tasks<\/h2>\n\n\n\n
In this scenario, the threat actor created a scheduled task named \u201cWinUpdate\u201d via HackTool:Win64\/Tarrask in order to re-establish any dropped connections to their command and control (C&C) infrastructure. This resulted in the creation of the registry keys and values described in the earlier section, however, the threat actor deleted the SD value within the Tree registry path.<\/p>\n\n\n\n
Figure 4. Deletion of the security descriptor (SD) value<\/figcaption><\/figure>\n\n\n\n In this context, SD refers to the Security Descriptor, which determines the users allowed to run the task. Interestingly, removal of this value results in the task \u201cdisappearing\u201d from \u201cschtasks \/query\u201d and Task Scheduler. The task is effectively hidden unless an examiner manually inspects the aforementioned registry paths.<\/p>\n\n\n\n
Issuing a \u201creg delete\u201d command to delete the SD value will result in an \u201cAccess Denied\u201d error even when run from an elevated command prompt. Deletion must occur within the context of the SYSTEM user. It is for this reason that the Tarrask malware utilized token theft to obtain the security permissions associated with the lsass.exe process. Upon execution of the token theft, the malware could operate with the same privileges as LSASS, making the deletion possible.<\/p>\n\n\n\n
Figure 5. Successful deletion of SD in Command Prompt<\/figcaption><\/figure>\n\n\n\n It is also important to note that the threat actor could have chosen to completely remove the two registry keys within Tree and Tasks, and the XML file created within C:\\Windows\\System32\\Tasks<\/em>. This would effectively remove the on-disk artifacts associated with the scheduled task, but the task would continue to run according to the defined triggers until the system rebooted, or until the associated svchost.exe process responsible for executing the task was terminated.<\/p>\n\n\n\n
It\u2019s possible the threat actor wanted to ensure persistence across reboots and therefore chose not to perform those steps, instead deleting only the SD value; however, we also speculate that the threat actor was unaware that the task would continue to run even after these components were removed.<\/p>\n\n\n\n
Recommendations and cyber resilience guidance<\/h2>\n\n\n\n
Job or task schedulers are services that have been present in the Windows operating system for many years. The attacks we described signify how the threat actor HAFNIUM displays a unique understanding of the Windows subsystem and uses this expertise to mask activities on targeted endpoints to maintain persistence on affected systems and hide in plain sight.<\/p>\n\n\n\n
As such, we recognize that scheduled tasks are an effective tool for adversaries to automate certain tasks while achieving persistence, which brings us to raising awareness about this oft-overlooked technique. We also want to bring attention to the fact that threat actors may utilize this method of evasion to maintain access to high value targets in a manner that will likely remain undetected. This could be especially problematic for systems that are infrequently rebooted (e.g., critical systems such as domain controllers, database servers, etc.).<\/p>\n\n\n\n
The techniques used by the actor and described in this post can be mitigated or detected by adopting the following recommendations and security guidelines1<\/sup>:<\/p>\n\n\n\n
\n
- Enumerate your Windows environment registry hives looking in the HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree<\/em> registry hive and identify any scheduled tasks without SD (security descriptor) Value within the Task Key. Perform analysis on these tasks as needed.<\/li>\n\n\n\n
- Modify your audit policy to identify Scheduled Tasks actions by enabling logging \u201cTaskOperational\u201d within Microsoft-Windows-TaskScheduler\/Operational. Apply the recommended Microsoft audit policy settings<\/a> suitable to your environment.<\/li>\n\n\n\n
- Enable and centralize the following Task Scheduler logs. Even if the tasks are \u2018hidden\u2019, these logs track key events relating to them that could lead you to discovering a well-hidden persistence mechanism\n
\n
- Event ID 4698 within the Security.evtx log<\/li>\n\n\n\n
- Microsoft-Windows-TaskScheduler\/Operational.evtx log<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- The threat actors in this campaign used hidden scheduled tasks to maintain access to critical assets exposed to the internet by regularly re-establishing outbound communications with C&C infrastructure. Remain vigilant and monitor uncommon behavior of your outbound communications by ensuring that monitoring and alerting for these connections from these critical Tier 0 and Tier 1 assets<\/a> is in place.<\/li>\n<\/ul>\n\n\n\n
Indicators of compromise (IOCs)<\/h2>\n\n\n\n
The following list provides IOCs observed during our investigation. We encourage customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.<\/p>\n\n\n\n