Threat hunting for Scheduled Tasks

You can’t talk about hunting for persistence techniques without mentioning scheduled tasks. As in the case of persistence via Windows services, described in a previous blog post, techniques related to scheduled tasks also allow for the use of a dual approach to persistence hunting:

methods of scheduled task threat hunting

Both the creation and execution of tasks can be hunted with simple yet different hypotheses, so let’s dive in and explore them.

Technique T1053.005 Scheduled Task/Job: Scheduled Task

The ‘scheduled task’ technique is a popular way of enabling persistent execution of malware. The technique can be used in an automatic manner (e.g., backdoor enables persistence of itself) or manually during the operational stage of a cyber attack. That’s why it is important to know how scheduled tasks can be created on a system and (even more importantly) how execution can be identified if something is executed as a scheduled task.

Hunting the threat: from hypothesis to event analysis

First of all, we need to understand how the ‘scheduled tasks’ technique is implemented. To execute a task, it must first be created. Although there are many ways to create scheduled tasks, it is usually done using the utility schtasks.exe. In general, when this utility is used it implies that a path to an executable file/script or the command is supplied as an argument to schtasks.exe, so the following hypothesis can be put forward:

“There will be a suspicious file/command supplied as an argument to schtasks.exe”. The general EDR query in this case might look like this:event_type: “Process creation” AND Payload.ImageFileName: “*\\schtasks.exe”

We can alter the query by adding more specific elements (e.g., specific path/filename/command fragment in command line arguments, or suspicious parent process). Executing the query might result in the following:

alter the query by adding more specific elements

We can also consider another similar example with the utility at.exe (T1053.002):

example with the utility at.exe

The main problem with such queries and hypotheses can be illustrated with a simple question: “What if a threat actor decided to create a recurring task in a different way?”. We know that scheduled tasks on Windows can be created using Windows APIor by creating a task definition XML, which does not require supplying a path to an executable/script in a command line parameter. In this case, we still have a failproof way of threat hunting: we can hunt for the execution of a file/script/command as a task. We know that in such cases the target of scheduled execution will have a specific parent process (several of them, actually). In this case, the EDR query to use looks like this:event_type: “Process creation” AND (Payload.ParentImageFileName: [“*taskeng*”, “*taskhost*” ] OR Payload.ParentCommandLine: “*\\svchost.exe -k netsvcs -p -s Schedule”),

Which covers all possible task parent processes depending on the version of Windows (and some other parameters).

The expected output can be as follows:

expected output

So we can use this ultimate strategy to hunt for the execution of scheduled tasks, regardless of how they were created. Keep in mind, however, that the parent-based strategy can generate many legitimate events since scheduled tasks are used by legitimate software.

There is also a special way of hunting for suspicious tasks. Since tasks are actually XML files created in a specific directory, you can use a query like the one below:event_type: “File creation” AND Payload.FileName: “*\\Windows\\System32\\Tasks\\*”

You can expect the following results:

hunting for suspicious tasks

Unfortunately, the above query can generate a lot of unnecessary events, so be prepared to filter them (e.g., by the process that created a task definition XML).

It may also be useful to retrieve such XML files during an in-depth threat hunting analysis or incident response process. After all, EDR stands for “Endpoint Detection and Response”, so in this case, the response capability of the EDR agent means that we can retrieve a file from a host by its name:

retrieve a file from a host by its name

This file can then be easily examined in any text editor, and among various XML tags we can find the exact command to be executed as a scheduled task:

exact command to be executed as a scheduled task

That’s all for scheduled tasks. The takeaway here is that any persistence technique can be hunted in (at least) two different ways: creation and actual execution.

Roman Rezvukhin

Roman Rezvukhin – Head of Malware Analysis and Threat Hunting Team