Hunting: Suspicious Scheduled Task Created

Scheduled tasks are one of the most common persistence mechanisms used by threat actors. This type of activity is also not limited to malware, tons of PUP (Potentially Unwanted Programs) also create scheduled tasks to ensure they continue to run at logon, startup, or at an interval.

First thing we need to consider is where is the most common place for malware to be stored. The vast majority of times it's going to be in locations that are writable by non-admin users, and are not going to be seen by the user. This is typically going to be the %USERPROFILE%\AppData folder, or temp folders such as C:\Temp or C:\Windows\Temp.

What Log is Needed?

You need to log event code 4698. To turn it on, you must enable the correct Advanced Audit Policy under Object Access -> Audit Other Object Access Events and ensure Task Scheduler Operational Logging is enabled.

Searching in Splunk

index=windows source=WinEventLog:Security EventCode=4698 
| spath input=TaskContent path="Task.Actions.Exec.Command" output=Command 
| spath input=TaskContent path="Task.Actions.Exec.Arguments" output=Args 
| spath input=TaskContent path="Task.RegistrationInfo.Author" output=TaskAuthor 
| spath input=TaskContent path="Task.Principals.Principal.UserId" output=TaskUser 
| eval command_line = Command ." " .Args 
| where match(command_line, "(?i)\\\\(AppData|Temp)\\\\") 
    AND NOT (match(command_line, "C:\\\\Users\\\\[^\\\\]+\\\\AppData\\\\Local\\\\(Mozilla|Microsoft|Google)") 
    AND match(Task_Name, "(?i)google|microsoft|mozilla")) 
| table _time host EventCode signature user TaskAuthor TaskUser Task_Name command_line 
| sort -_time

First things first, the index is going to be all dependent on your Splunk setup. I included the source field as well, this is assuming you're using standard WinEventLogs not XML logs. I've had issues ingesting the XML logs for this log type because the Task XML comes in encoded.

spath Function

We are using the spath command to extract fields from the task XML. The Windows TA does not do this by default from what I've seen, so I have just done it myself.

With spath, the input is the field that you want to read your data from, in the case of this data the field is TaskContent. The path is the path to the field within the XML you want to extract. Output just allows you to specify the field name that you are outputting from the data you pull from your input and path. This is optional.

By extracting this data, it gives you a more clear picture and better data to send your analysts for your alerting. If you're utilizing Splunk Risk Based Alerting, I would recommend having this alert generate an alert as soon as it's found. Once you tune this properly you should not be seeing this often and anytime you do it should be heavily scrutinized.

Regular Expression

By evaling a new command_line field joining the Task Command with the Task Arguments, we can now just use regex to find if AppData or Temp is found within either of these fields. This is important because the command/binary may not be in AppData but a script the actor is running is in AppData. (?i) within the regex also specifies that it is case insensitive. This is needed just to ensure there are no false negatives. We also use regex to ignore google, microsoft, and mozilla folders/tasks. This could potentially cause false negatives but combined it's much less likely. You can always remove this line, see what matches you have in your environment, and filter more specifically.

Usage for Alerting

Many organizations monitor scheduled tasks but it can be quite noisy and hard to filter all false positives. I've found it's best to have one broad search for any scheduled tasks being created, and have that assign a lower risk value, and have this generate much higher risk score. With this setup it should give you the best results with the least false positives.

Results

As you can see, we have a scheduled task that's been created, the powershell command is pointing to a script that is stored within %LOCALAPPDATA%\Temp. Please take this search, add some additional suppressions that match your environment, and run this at the very least daily. We are already tuning out events where the name of the task contains Mozilla, Google, or Microsoft and pointing to directories in the AppData directory. These are commonly associated with Web Browsers doing auto updates. I've also found quite a few unwanted browsers doing the same like Blazer Browser and some of these other AI powered browsers. This is also a great way to detect trojan horses like the recent JustAskJacky campaign which is what this hunt was inspired by.

Utilizing this in a hunting search along with another search for the RunMRU registry key will show you quite a few new age, common initial access/persistence mechanisms.

Good luck and happy hunting!