Using SCOM to Detect Scheduled Task Creation

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

One well known thing that attackers like to do is to create scheduled tasks to periodically execute their payloads.  Detecting Scheduled task creation is not terribly difficult.  While it does not use the standard logs, there is an operational task scheduler log available that generates an event ID 106 whenever a scheduled task is created.  Information on said event can be found here.  Creating a rule to do this is very straight forward:

The downside to this is that it is not necessarily a quiet proposition.  For those that know me, noise generated by management packs is something I’m not a fan of.  Alerts should be actionable, and generating alerts that are ultimately ignored due to constant false positives will not do anyone any good.  As such, this brings us to a few problems as many organizations have legitimate uses for scheduled tasks. For the person responsible for security monitoring, they need a way of knowing which tasks are legitimate and which ones are not.  One easy way would be to configure standard tasks before the SCOM agent is installed, or use maintenance mode on the server while it is being configured prior to maintenance.  Good process can certainly get around those alerts, but there’s another problem: some applications also create scheduled tasks.

In my own lab, this is noticeable as an anti-malware scan runs periodically, and when it is set, it is set by a scheduled task:

If this is common thing in a lab with a half-dozen servers in it, then it could likely be a noisy thing in your environment.  But it is correctable.  Enter Parameterization.  The scheduled task log has two parameters:  The logging user and the task name. The task name is parameter 1, so if you have a task that is periodically being created by an application, then the task name should be the same. I’d hesitate to filter by the user name in this case as a user name such as a machine name could be generated by malicious code depending on the context of whomever generated it.

Crafting and tuning that rule is simple.

You’ll likely have some noise to start, but this is hardly something that cannot be corrected over time. Just keep adding lines for “Parameter 1” and “Does not contain” with a value that is unique to your scheduled task.

Comments

• Anonymous
  July 02, 2018
  This is a really useful article and helped me tremendously. However I decided to use the security event 4698 instead if event 106 because it has considerably more detail about the task which is really useful when viewing through the SCOM console. You need to enable additional auditing policies for this to work though. These are "Audit Other Object Access Events". Also when using event id 4698 you also need to check parameter 5 for the task name and not parameter 1.
  • Anonymous
    July 13, 2018
    I will have to look into this. Thank you!