The following hunting analytic assists with identifying suspicious tasks that have been registered and ran in Windows using EventID 200 (action run) and 201 (action completed). It is recommended to filter based on ActionName by specifying specific paths not used in your environment. After some basic tuning, this may be effective in capturing evasive ways to register tasks on Windows. Review parallel events related to tasks being scheduled. EventID 106 will generate when a new task is generated, however, that does not mean it ran. Capture any files on disk and analyze.
- Type: Hunting
- Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
- Datamodel: Endpoint
- Last Updated: 2021-10-19
- Author: Michael Haag, Splunk
- ID: b3632472-310b-11ec-9aab-acde48001122
|T1053.005||Scheduled Task||Execution, Persistence, Privilege Escalation|
Kill Chain Phase
1 2 3 4 5 6 `wineventlog_task_scheduler` EventCode IN ("200","201") | rename ComputerName as dest | stats count min(_time) as firstTime max(_time) as lastTime by Message dest EventCode category | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `winevent_windows_task_scheduler_event_action_started_filter`
The SPL above uses the following Macros:
Note that winevent_windows_task_scheduler_event_action_started_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.
How To Implement
Task Scheduler logs are required to be collected. Enable logging with inputs.conf by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] and renderXml=false. Note, not translating it in XML may require a proper extraction of specific items in the Message.
Known False Positives
False positives will be present. Filter based on ActionName paths or specify keywords of interest.
Associated Analytic story
|80.0||80||100||A Scheduled Task was scheduled and ran on $dest$.|
source | version: 1