Security Monitoring–Configuring SCOM to alert on attempts to kill Windows Defender

This is just a quick update to the next revision of Security Monitoring. If you don’t use Windows Defender, this will not generate any alerts, and in general it should be quiet even if you do use Window Defender.  This will only work if you have the audit process creation GPO set. I’d also note, that you need to have command line auditing turned on as well. I’ve referenced that in other places, but here’s a screenshot if you’re unsure:


If these are set, there is now a new rule that will look for 4688 events with various kill switches meant to stop that process. This alert will also be available if you’re using Windows Event Collectors.


Security Monitoring–Using SCOM to Detect Executables Run in Writeable OS Directories Part 1

I had the privilege of attending Microsoft Ready this last July. That allowed for some very useful networking. In this case, I got to speak a bit with some security professionals who do forensic investigations after a compromise. One common attack vector is something seen once the attacker has gained access to a machine. They will usually drop some sort of malware/executable files in specific directories within Windows that anyone can write to. This can be especially beneficial to them when they haven’t yet elevated themselves to local admin rights. They do this because there are directories within the Windows OS that non-admins are allowed to write to. Typically this is to store configuration information or provide writeable locations for temporary files/tasks. That said, an attacker can exploit these locations to run executables, which is something that (at least in my lab) doesn’t happen under normal circumstances.

Interestingly enough, this is actually pretty easy to track at a basic level.

Step 1 – Turn on Process Creation Tracking. If you’ve already been using SCOM to do security monitoring, you would have likely already done this, but just in case you haven’t, this is an advanced audit policy. It will generate 4688 events (and a lot of them) in your security logs.


Step 2 – create a rule that looks for event ID 4688 as well as “.exe” in parameter 6. On top of that, you’ll need to next an Or group to look at the common locations that users can write to within the windows directory:


As you can see, I kept the parameters generic so that I’m not dependent on the drive location. This was pretty easy. If you setup a rule like this, you can drop an executable (say MPViewer) in the c:\windows\temp directory and launch it. It will generate an alert every time.

There is a downside to this. For one, the screen shot above only contains the basic writeable locations. The reality is that every time you add a feature or install something, it’s possible that you create additional locations that need to be tracked. This rule won’t do that, and it’s impossible to know every single one. The other problem is that the same conditions should be monitored for the Program Files and Program Files (x86) directories. Those will vary by application, so again, it’s not something that someone can easily track since they won’t know all the possible combinations.  I’ll address that scenario in the next part.

This will be included in the next revision of the Security Monitoring Management Pack. It will contain both the part 1 and part 2 piece. If this is something you’d be interested in testing, please reach out to me on linked in.

Part 2 can be found here.

Part 3 can be found here.

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.