Behind The Detection — Schtasks

Part I: Getting Started

Hello and welcome to this brand new blog series that I'm starting where I’ll be looking at some different techniques/tools used in the wild by different actors from the lens of Sysmon and the Windows Event Log and build/showcase available SIGMA rules to detect them.

This post will serve as an introductory post where I’ll highlight some general concepts and walk through some examples. We’ll get deeper as the series advances so bare with me :)

Bit Of Background

Attackers and malware love to persist on machines, in fact, it’s not love it’s sometimes a necessity. Now to achieve this persistence on windows one-way attackers often use is creating “scheduled tasks”

There are multiple ways to create these tasks via built-in command-line utilities or using APIs directly but today I’ll be focusing on the “schtasks.exe” utility for this first post we’ll look at other variations in future posts :)

We’re gonna look at three variations of schtasks being executed.

The first is from QBOT as seen in this Elastic report

C:\Windows\system32\schtasks.exe /Create /RU NT AUTHORITY\SYSTEM /tn ayttpnzc /tr regsvr32.exe -s "c:\Users\[REDACTED]\Desktop\7611346142\c2ba065654f13612ae63bca7f972ea91c6fe97291caeaaa3a28a180fb1912b3a.dll" /SC ONCE /Z /ST 15:21 /ET, 15:33

The second is from Ryuk as seen in this The DFIR Report report

"C:\Windows\System32\schtasks.exe" /CREATE /SC ONCE /ST 17:21:58 /TN 9T6ukfi6 /TR "'C:\Users\pagefilerpqy.exe'" /f /RL HIGHEST

And the third one is a custom

C:\Windows\system32\schtasks.exe /change /tn MaliciousTask /tr C:\Users\Public\malware.exe

One other note is that I’ll be using SIGMA to express the detection that I talk about here, so you need to be at least familiar with the basics.

It’s very easy to pick up and I have a GitHub repo with a bunch of resources to help you get started so check it out if you need to.

GitHub - nasbench/SIGMA-Resources: Resources To Learn And Understand SIGMA Rules

Schtasks CLI Options

Before we go further into how we can detect these command lines and what’s even suspicious about them it’s good to have a basic understanding of the “schtasks” utility CLI. For that, I suggest you check the MSDN documentation for the tool as it has some nice examples and a great explanation for most of the arguments.

schtasks commands

With that out the way let’s get going.

Are “Scheduled Tasks” Malicious?

Maliciousness sometimes is agreed upon by others it’s “context” is dependent. In this case “scheduled tasks” are not malicious per se as they are legitimate mechanisms offered by the OS. In cases like these what we’re looking for when writing detections is “Suspicious” or “Uncommon” behavior.

The words “Suspicious” or “Uncommon” can and will vary from one environment to another as some applications are executed often in env X and less in env Y. There are some common ground we can agree on (at least most of the time) a couple of examples would be

• Uncommon processes running from “C:\Users\Public” or %TEMP%
• Uncommon Child/Parent relationships
• DLLs being loaded from uncommon locations
• …Etc

Using these kinds of assumptions and knowledge if you will is what we use to write detections (there is a lot more to this but that’s the gist of it)

Now back to “schtasks”, let’s apply this process to our pre-selected from above.

CommandLine Detection

We’ll first start with analyzing the command line and for this, we’ll be relying on Event Log ID 4688 and Sysmon ID 1 which both are related to process creation and command line logging.

Here is a reminder of the first command.

C:\Windows\system32\schtasks.exe /Create /RU NT AUTHORITY\SYSTEM /tn ayttpnzc /tr regsvr32.exe -s "c:\Users\[REDACTED]\Desktop\7611346142\c2ba065654f13612ae63bca7f972ea91c6fe97291caeaaa3a28a180fb1912b3a.dll" /SC ONCE /Z /ST 15:21 /ET, 15:33

Let’s analyze what’s happening

• A task is being created we know this because of the “/Create” flag
• The “/RU” flag indicates the level of permissions that this task will run with (in this case it’s “NT AUTHORITY\SYSTEM”
• The task is called “ayttpnzc” (See “/tn” flag)
• The “/Tr” flag indicates the task being run which in this case is

“regsvr32.exe -s “c:\Users\[REDACTED]\Desktop\7611346142\c2ba065654f13612ae63bca7f972ea91c6fe97291caeaaa3a28a180fb1912b3a.dll”

• The last couple of flags are related to the type of schedule (see MSDN for full list) and the time of execution (we’ll skip this for now)

Let’s apply what we’ve talked about and see what can we write detection about.

Creating Tasks With “/Create”

The first thing we notice is the “/Create” flag which indicates in the context of “schtasks” that a task is being created.

Now one might care or not about task creation as it depends on how often it happens on an endpoint and in an environment. It could be a rare occurrence or a very common thing. No matter but we can write a very basic detection based on this idea.

Image == "schtasks.exe" and CommandLine contains "/Create"

In SIGMA form it would be something like this

https://github.com/SigmaHQ/sigma/blob/1e16ed00905a496cbc3b0a1a03d4c2f6f4b63de2/rules/windows/process_creation/proc_creation_win_susp_schtask_creation.yml

While this covers the basics it could (and will) generate a lot of false positives in a real environment so let’s get going to the next part.

Specifying The User With “/RU”

The next argument “/RU” is an interesting one as it let the users specify the level of privileges/permissions the task will run. Obviously the higher the permissions the more it can do.

Something running with high privileges is always of interest to us especially when it can be user controlled. So let’s write a simple detection looking for this pattern

Image == "schtasks.exe" and CommandLine contains "/RU" and CommandLine contains "NT AUTHORITY\SYSTEM"

In SIGMA form it would look a little bit like this (don’t mind the additional flags and logic for now)

https://github.com/SigmaHQ/sigma/blob/dabc74af0c8b15cf22f50df9f225ec3b8c599d80/rules/windows/process_creation/proc_creation_win_schtasks_system.yml

Task Being Run With “/TR”

The task is going to run the following command

“regsvr32.exe -s “c:\Users\[REDACTED]\Desktop\7611346142\c2ba065654f13612ae63bca7f972ea91c6fe97291caeaaa3a28a180fb1912b3a.dll”

Analyzing this command we see that it’s executing “regsvr32.exe”. Now a task running “regsvr32” is not that common so that’s the first thing we might notice. The second is the DLL being passed to “regsvr32” is located on the “Desktop” also an uncommon thing to do in a Task. Finally, the name of the DLL is very random (high entropy) which is another red flag (even if we know it’s the hash but let’s pretend it’s actually used like this in an attack).

Let’s step back a little bit and see what we have.

• “Regsvr32.exe” being executed as part of the scheduled task
• The DLL is located on the “Desktop”
• The DLL name is very random

We know that what we have currently is “suspicious” but we could extrapolate and say instead of “Desktop” we had “%TEMP%” or “C:\Users\Public\” would it still be suspicious? and instead of “regsvr32.exe” we had “cmd.exe” or “powershell.exe”? The answer is always it “depends” but most of the time it is suspicious.

So let’s write a generic rule for this

Image == "schtasks.exe" and CommandLine contains [Suspicious Folder] and CommandLine contains [Suspicious Binary Or Command]

In SIGMA it would look something like this

https://github.com/SigmaHQ/sigma/blob/dabc74af0c8b15cf22f50df9f225ec3b8c599d80/rules/windows/process_creation/proc_creation_win_susp_schtasks_change.yml

Hope that by now you’re starting to get the idea of how this works at a high level. With that let’s take a look at the second command then.

"C:\Windows\System32\schtasks.exe" /CREATE /SC ONCE /ST 17:21:58 /TN 9T6ukfi6 /TR "'C:\Users\pagefilerpqy.exe'" /f /RL HIGHEST

Again we have some familiar patterns but we have the “/RL” flag being to the value “HIGHEST”. Again we ask ourselves is this suspicious or not (a quick look at the doc will give you the answer)

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks-create

We can follow a similar pattern to write detection for this case if our current detection doesn’t cover this.

Now let’s look at the final command

C:\Windows\system32\schtasks.exe /change /tn MaliciousTask /tr C:\Users\Public\malware.exe

While this looks pretty similar to the other it has one big difference. That is the task is not being “created” but “updated”. The idea here is that we’ve seen attackers do all the dirty work during the creation of the task. But nothing is preventing them from creating a simple task and then updating the correct fields such as “/TR” and “/RU”.

Something to keep in mind is that you gotta expand your horizon and think/try some stuff even when you don’t really see it being used somewhere or written about in threat reports

There Is More Than CLI

While command-line detection is great and all at the end of the day is not the holy grail that we’re looking for. It can be and has been bypassed by a lot of threat actors but on the other hand, threat actors are still using the same copy-pasta stuff so don’t you dare ignore it ;)

In the case of “Scheduled Tasks” specifically, the registry contains some interesting indicators that we can use to know when a task is being created no matter the tool but that’s a discussion for next time :D

Conclusion

I really hope you enjoyed this post and found some use in it. If you have any comments, ideas, or just want to discuss then I’m on Twitter @nas_bench

Please look forward to future posts in this series as we’re gonna delve deeper into this :)

Resources

Here is all the linked stuff from the blog in one place for your convenience

• [The DFIR Report] — Ryuk Speed Run, 2 Hours to Ransom
• [Elastic] — Exploring the QBOT Attack Pattern
• [MSDN] — Schtasks
• [Nextron Systems] — Sigma Repository