This website uses its own and third party cookies to collect information that helps to optimize your visit to their web pages. Cookies will not be used to collect personal information. You can either allow or reject their use. You can also change their settings at any time. You will find more information on our Cookie Policy page.


DS4N6 Blog >> Threat Hunting with AI- Part 3 - T1053.005 / Scheduled Tasks In-Depth

Threat Hunting with AI- Part 3 - T1053.005 / Scheduled Tasks In-Depth

370x370_jess-garcia.jpg [25/05/21] May 25, 2021
Jess Garcia - One eSecurity
Twitter: j3ssgarcia - LinkedIn: garciajess

[ Full blog post series available here ]

Photo by Şahin Sezer Dinçer on Unsplash

In Part 2 of this blog post series, we decided that we would try to detect the Solarwinds/Sunburst Campaign via the detection of technique T1053.005 / Scheduled Tasks.

In this blog post we will try to know, in-depth, how the adversarial technique T1053.005 / Scheduled Tasks works, in order to be able to develop a successful anomaly detection mechanism for that technique.

MITRE T1053.005 - Scheduled Tasks

We will now get to know MITRE ATT&CK T1053.005 / Scheduled Tasks Technique a little better.

You can of course start with the information provided at its corresponding T1053.005 MITRE ATT&CK sub-tecnique page.

The information provided in the “Detection Section”, while very valuable, is somewhat scarce and very focused (as most of the MITRE ATT&CK Frameworw) towards Event Logs. This is great and somewhat natural, since most organizations center their Detection strategies on event logs, but there certainly are other Forensic Artifacts that are associated to the Scheduled Tasks that we can use.

The Attack Execution View - The Mordor Project

To start with, if you want to know more about how the T1053.005 technique works in the real world, I highly recommend you to start with the Mordor Project, an amazing project developed by Roberto & Jose Luis Rodriguez (@Cyb3rWard0g & @Cyb3rPandaH).

In a nutshell, what the Rodriguez brothers did was execute in the lab over 100 commonly seen attacks/hacking activity (adversarial techniques), while recording associated data: commands executed by the attacker, events generated in the victim, network traffic observed, which is available for download. They also map each of the attacks to the corresponding MITRE ATT&CK Enterprise Framework Techniques.

Let's go back to our scenario, the remote creation of an Scheduled Task, to understand the value that the Mordor Project provides and how it works.


If browse to the Mordor Scheduled Task Creation page, you will first see the Metadata section, in which we can see that this adversarial technique is associated to multiple MITRE ATT&CK Enterprise Tactics (TA0002 - Execution, TA0003 - Persistence, TA0004 - Privilege Escalation and TA0008 - Lateral Movement) and to the T1053.005 technique what we are currently discussing.

Then the Dataset Description: This dataset represents a threat actor creating a scheduled task remotely using schtasks.


And immediately after you have the download links where you can download the corresponding event log / packets data in json format:

This is a excerpt of the Host json file which, as you can see, contains the Windows event logs associated with the adversarial activity:

$ jq . schtask_create_2020-12-1907003032.json | less
  "SourceName": "Microsoft-Windows-Security-Auditing",
  "ProviderGuid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
  "Level": "0",
  "Keywords": "0x8020000000000000",
  "Channel": "Security",
  "Hostname": "WORKSTATION5.theshire.local",
  "TimeCreated": "2020-12-19T06:59:28.410Z",
  "@timestamp": "2020-12-19T06:59:28.410Z",
  "EventID": 5158,
  "Message": "The Windows Filtering Platform has permitted a bind to a local port.\r\n\r\nApplication Information:\r\n\tProcess ID:\t\t3108\r\n\tApplication Name:\t\\device\\harddiskvolume2\\windowsazure\\guestagent_2.7.41491.1005_2020-11-30_095005\\guestagent\\windowsazureguestagent.exe\r\n\r\nNetwork Information:\r\n\tSource Address:\t\t0.0.0.0\r\n\tSource Port:\t\t56581\r\n\tProtocol:\t\t6\r\n\r\nFilter Information:\r\n\tFilter Run-Time ID:\t0\r\n\tLayer Name:\t\tResource Assignment\r\n\tLayer Run-Time ID:\t36",
  "Task": "12810",
  "ProcessId": "3108",
  "Application": "\\device\\harddiskvolume2\\windowsazure\\guestagent_2.7.41491.1005_2020-11-30_095005\\guestagent\\windowsazureguestagent.exe",
  "SourceAddress": "",
  "SourcePort": "56581",
  "Protocol": "6",
  "FilterRTID": "0",
  "LayerName": "%%14608",
  "LayerRTID": "36"
  "SourceName": "Microsoft-Windows-Security-Auditing",

As you can see you have here, in json format, the events that were generated by the target system when a Scheduled Tasks was remotely scheduled and executed:

$ jq . schtask_create_2020-12-1907003032.json  | grep "SourceName" | sort | uniq -c | sort -nr
    906   "SourceName": "Microsoft-Windows-Sysmon",
    133   "SourceName": "Microsoft-Windows-Security-Auditing",
      2   "SourceName": "Microsoft-Windows-TaskScheduler",

As you can see, here are the two Windows Event IDs (104/106) associated with the creation of the tasks, from the Microsoft-Windows-TaskScheduler file:

$ grep "Microsoft-Windows-TaskScheduler" schtask_create_2020-12-1907003032.json | jq . | grep "EventID" | sort | uniq -c | sort -nr
      1   "EventID": 140,
      1   "EventID": 106,

There are easier ways to consume this dataset than the linux command line (including Jupyter). Check the Consume Datasets section of the Mordor web site for more information.

The Network file is actually pcap-ng dump of the network packets associated to the adversarial activity:

$ tshark -r schtask_create_2020-12-1907003032.pcapng | less
    1   0.000000 →  TLSv1.2 97 Application Data
    2   0.000033 → TCP 54 3389 → 54545 [ACK] Seq=1 Ack=44 Win=63261 Len=0
    3   0.004613 → TLSv1.2 694 Application Data
    4   0.004666 → TLSv1.2 16806 Application Data, Application Data
    5   0.005286 →  TCP 54 443 → 56575 [ACK] Seq=1 Ack=3521 Win=1029 Len=0
    6   0.005286 →  TCP 54 443 → 56575 [ACK] Seq=1 Ack=17393 Win=1029 Len=0
    7   0.007720 →  TLSv1.2 97 Application Data
    8   0.015728 →  TLSv1.2 97 Application Data
    9   0.015785 → TCP 54 3389 → 54545 [ACK] Seq=1 Ack=130 Win=63175 Len=0
   10   0.027780 →  TLSv1.2 97 Application Data

Adversarial View

And a little later, the Adversarial View, that is, the commands that the adversary executed to implement that technique:

PS C:\windows\system32> C:\Windows\system32\cmd.exe /C schtasks /create /F /tn "\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager" /tr "C:\Windows\system32\cmd.exe /C C:\Windows\System32\notepad.exe" /sc ONSTART /ru system /S WORKSTATION6
SUCCESS: The scheduled task "\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager" has successfully been created.
PS C:\windows\system32> 

The Detection View - The Threat Hunter Playbooks Project / Sigma Rules

The Threat Hunter Playbooks Project

Very closely related to the Mordor Dataset Project, and also by the Rodriguez brothers, is the Threat Hunter Playbooks Project (THP).

The THP provides an amazing collection of resources, extremely useful for Threat Hunters such as:

Of special interest for our analysis is the Analytics section of the Targeted Notebooks, where you can find a description of the SQL query required to identify the use of thatTa technique.

Unfortunately, there is no THP Notebook for T1053.005, but for the sake of an example, we will include here the query for Remote Service creation:

If you want to learn more about the Mordor and THP Projects, this blog post by Roberto Rodriguez, Threat Hunter Playbook ⚔ + Mordor Datasets 📜 + BinderHub 🌎 = Open Infrastructure 🏗 for Open Hunts, may give you a bigger picture of the underlying purpose of both initiatives and how to make them work.

Sigma Rules

Sigma is a generic and open signature format that allows you to describe relevant log events in a straightforward manner. Sigma is for log files what Snort is for network traffic and YARA is for files.

Sigma has been gaining popularity over the last few years, and as such you will find multiple repositories on the Internet containing rules in Sigma format.

For obvious reasons one of the most popular and well maintained is the one at SigmaHQ, where Florian Roth, the founder and soul of the Sigma project, has contributed dozens of Sigma rules for multiple platforms (Windows, Linux, Proxy, Web, etc.).

Other popular repository is the one at Elemental. Elemental is a centralized threat library of MITRE ATT&CK techniques, Atomic Red Team tests, and over 280 Sigma rules.

You will find in both repositories rules related to the detection of T1053.005:

As you can see, there is some overlap in the repos.

This is how the win_rare_schtask_creation.yml looks like:

As a side note, in addition to detection through standard Windows Event Logs (evtx), you will see in many of these repositories that detection rules via Sysmon events are also widespread, due to the bigger flexibility and granularity that Sysmon provides (Sysmon is a Sysinternals utility for Windows systems provides detailed information about process creations, network connections, and changes to file creation time). Unfortunately you will not find Sysmon widely deployed in most of the organizations, so in most real world cases you will have to live with standard Windows event logs.

As you can see, we count with multiple sources that we can use in order to identify how to detect the most common adversarial techniques via event logs or sysmon. But event logs are limited (granularity, retention, etc.), so we will now look for more comprehensive information sources that provider a wider range of evidence.

The Forensics View - The SANS Hunt Evil Poster

A more comprehensive Forensics-oriented resource that you can use is the SANS Hunt Evil Poster.

The Poster is an amazing resource which, among many other things, outlines what are the forensic artifacts associated to different types of activities commonly used by adversaries: RDP, Network Shares, PsExec, Scheduled Tasks, Services, WMI, PowerShell Remoting.

So, good news for us, as you can see the Poster describes in-depth the forensic artifacts associated to T1053.005, both from the Source Computer and from the Destination Computer point of view.

Command Line Execution

To start with, the poster shows the command that the attacker would typically use to execute the malicious task.

The poster shows the commands that the attacker would execute to schedule a task remotely, both with the legacy -but still supported- version of the Scheduled Tasks system (“at”) as well as the modern version one (“schtasks”):

In the lower case, which corresponds to the “modern” version of the Scheduled Tasks system, the command shows how to schedule a task named “taskname” on a remote computer called “host” authenticating to it with username “user”. This task would run once as the user “SYSTEM” and would ultimately execute the binary “C:\temp\evil.exe”.

This command would leave the forensic “residue” in both the Source computer (the one in which the command is executed) and the Remote computer (then one in which the task is scheduled).

This action will leave some forensic “residue” in the source computer (events, registry and file system), related in the vast majority to the execution of the scheduled task, without much detail about its specific content:

And it would also leave forensic “residue”, much more comprehensive this time, in the destination computer (events, registry and file system), related to both the tasks been scheduled and the follow-up actions related to the malicious command been executed.

Artifact Selection & Collection

In order to allow the Hunting process to scale up, out of all the artifacts related to T1053.005, we will select first those that are more straightforward and easier to extract and analyze. If the process requires at a later stage, we would need to include additional / alternative artifacts to the ones selected.

According to the SANS Poster information, we will be chasing artifacts related to two broad categories:

  • The Scheduled Task itself:
    • evtx: Security.evtx / Microsoft-Windows-TaskScheduler%4Operational.evtx
    • Registry: SOFTWARE Hive:
      • Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks
      • Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\
    • Files: XML Task Files under C:\Windows\System32\Tasks
  • The evil.exe file executed by the scheduled task
    • Registry: ShimCache (SYSTEM Hive) and AmCache.hve
    • Prefetch: C:\Windows\Prefetch\evil.exe-{hash}.pf
    • Files: evil.exe

Regarding evil.exe, the file associated to each task, the problem is that, in order to identify it we would need to parse its corresponding XML file. evil.exe is not deterministic and therefore it is very complex to implement a Hunting process which depends on it. For that reason we will initially discard it, along with its associated artifacts.

We will focus on the Scheduled Task itself then, and we will start with just 2 artifacts which provide high value, are typically relatively small and are reasonably easy to extract.

File Artifact Comments
evtx Microsoft-Windows-TaskScheduler%4Operational.evtx Microsoft-Windows-TaskScheduler%4Operational events Or equivalent logs extracted from a SIEM or Log Aggregation system.
Files $MFT File Listing Or equivalent Forensic File Listing of XML Task Files under C:\Windows\System32\Tasks

If these artifacts do not provide satisfactory results in terms of the anomaly detection strategy that we have discussed previously, we could eventually include additional artifacts such as Security event logs or registry keys.

Well, that's all for now. As a summary, in this blog post we have covered different ways of detecting the creation and execution of scheduled tasks, associated to the MITRE Attack Technique T1053.005.

In the next post we will use all the information provided in these first 3 posts to enter the fascinating world of Machine Learning!

Stay Tuned and contact us if you have any comment or question!

[ Full blog post series available here ]