MITRE’s data sources
- File monitoring
- Process monitoring
- Process command-line parameters
- Windows event logs
API monitoring is an additional data source that is useful in certain contexts for observing adversaries leveraging Scheduled Task. In some attack campaigns, adversaries have used the Windows Component Object Model and Distributed COM technique (T1175) to create a Scheduled Task via macros or other methods. API monitoring provides visibility into this and other covert methods for creating a Scheduled Task.
File monitoring provides a useful data source for observing the malicious use of Scheduled Tasks. Defenders should consider tracking the schtasks.exe or at.exe binary because it will enable them to continue observing Scheduled Tasks, even if the binary has been moved to a different path or renamed entirely. A Scheduled Task that has been moved or renamed can be a good indicator of malice.
Monitoring process execution of schtasks.exe and at.exe is important because these processes have the ability to set tasks locally or remotely, enabling lateral movement. Historically, adversaries have set Scheduled Tasks to start under a different user context (administrator, for example).
More recently, PowerShell has a cmdlet (new-ScheduledTask) that provides the same functionality as schtasks.exe. Understanding the processes that normally spawn Scheduled Tasks and monitoring parent-child process relationships is useful for observation as well.
Process command-line parameters
Process command-line parameters are another rich source for observing malicious Scheduled Tasks. While they might provide the highest fidelity of alerting, they also offer adversaries the most potential for blending in. Understanding the various parameters and what to look for in a given environment requires extensive research and testing, but tracking via the command-line is ultimately the way that most teams monitor for Scheduled Task abuse.
Windows event logs
Windows event logs may also provide useful information about start and stop times for task execution as well as additional details about the task itself.
Security teams should begin by reviewing all process and command-line execution of schtasks.exe and at.exe, ranking the results from most common to least. Where possible, you should also try to collect all Scheduled Tasks across an environment using a tool such as OSQuery or Sysinternals Autoruns. Again, you’ll want to organize the associated processes and command-lines by occurrence, so that you understand which tasks occur often and which do not.
You’ll want to take a close look at less commonly used command-line switches for schtasks.exe. One example might be
/XML. It’s entirely possible that searching for this in your environment may turn up nothing, but, if you do happen to find it, you’ll want to examine the contents of that XML file.
It’s also a good idea to monitor for tasks that spawn at seemingly strange intervals. For example, something like
/sc minute /mo 20, which means that the task will run every 20 minutes, should be viewed with suspicion. There are few legitimate reasons that a task would need to run every 20 minutes—or at any other fixed interval.
Tracking for Scheduled Tasks that load binaries (.exe, for example) or scripts (.ps1, .vbe, and .vbs to name a few) from suspicious paths is a quick win for detection. The default execution path for schtasks.exe or at.exe is
c:\windows\syswow64\, so any deviation from those should raise concerns that the binary has been moved. Also consider monitoring for suspicious execution paths such as
\windows\tasks\, as it is pretty suspicious for a Scheduled Task to execute from either of these paths.
As is the case with Masquerading, you should review binary metadata. Binary metadata includes a field for internal names, which are often good indicators of a binary’s true identity. It’s a good idea to raise an alert when it appears that schtasks.exe or at.exe have been renamed.
Ultimately, you’ll want to understand what parent processes normally spawn Scheduled Tasks. Is it normal in your environment for SYSTEM to create a task? If the answer is “no,” then you’ll want to consider alerting on that behavior. Similarly, you may want to track when users spawn schtasks.exe from PowerShell or cmd.exe.
Weeding out false positives
We should note that tracking schtasks.exe command-line parameters may generate a high volume of data and false positives at first. By default, Windows runs a number of common tasks. The same is essentially true at the organizational level, with application and server-specific tasks. Once you identify and tune out the normal, deviations are pretty reliable indicators of maliciousness.
Some automated software deployment utilities (e.g., SCCM, Kaseya) may utilize Scheduled Tasks to deploy software or keep systems up to date—and may contribute to high false positive rates.