Security Monitoring–Updating Service Created on DC Rule

One piece of feedback that I’ve seen in regards to security monitoring is noise due to services created on a domain controller. In general, this should not be a common event, but occasionally legitimate applications do create services on a domain controller. As such, I’ve done a minor rewrite of this rule to allow for an override for up to 5 services.

There’s a couple things worth noting.

First, this does not replace the rule that runs on all systems that generates alerts for known threats such as wince or psexec. Yes, both of those tools have legitimate uses, and if you’re using them in your organization, then I do recommend turning off that rule.

That said, there’s a second rule targeted only to Windows Domain controllers which will alert any time a service is created on a DC. Again, this is typically not common in an environment, but if you’re an exception to this, read on.

All you need to do is create an override:


That’s pretty straight forward. It’s worth noting that this is using a contains operator against parameter 2 of the event. There’s not much to this particular parameter, but if you’re troubleshooting and having issues, you’ll want to verify the value in the 7045 event that is created. It must match.


These updates will be in the next Security Monitoring MP. If you wish to test these, hit me up on linked in.

Security Monitoring–Updating Scheduled Task Creation Rule

One piece of feedback I’ve gotten is that monitoring the creation of scheduled tasks as well as service creation on domain controllers can get a bit noisy due to typical business activities. While these particular activities don’t happen terribly often, it’s possible to have applications that create scheduled tasks or services as needed. As such, both of these generate alerts that are ultimately ignored.

This forced a minor rewrite of both of these rules. Basically, I’ve written in code that allows you to override the rule and specify a particular exception.

Task Scheduler:

I had to go with a security event instead of using the Task Scheduler Operations log. The reason for it is that the Task Scheduler log only mentions what is created. It doesn’t say the program running. As such, you’ll need to do a couple things to get this working properly.

Step 1: Enable auditing of Object Access. This is an advanced policy, but you’ll need to turn on other audit object access events:


You’ll need to do this as the old rule isn’t going to work now.

Step 2: Do your override. That’s straight forward. You can target this against the entire class or a specific object. I’ve created 5 Applications that can be excluded (App1-5 on the screenshot below). This should allow plenty of flexibility.


At this point, save and you’re done. There is a bit of a catch here, and I have to emphasize this.  You need to be as specific as possible. All of the data for this scheduled task is lumped into parameter 6. As you can see from the screenshot below, there’s a lot of text in that parameter. The application running (in my case cmd.exe) is only a small portion of the parameter. I would recommend making sure you put the full path to the application you need to exclude if at all possible.


That’s the task scheduler. I’ll include this rule in the next update of this management pack. If there is interest in using this, hit me up on linked in.