Security Monitoring–Additional PowerShell Detections Addendum

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.

This is a follow up article to this piece that I wrote in early September. Not surprisingly, there was some noise in my initial lab tests. Two rules in particular were noisy, and the chief culprit happened to be SCOM. The rule governing PowerShell running in memory only  as well as the rule to bypass execution policy. When you think about it, both make sense to some extent, and that’s part of the reason why these features are built in to PowerShell.

If SCOM could not bypass execution policy, for instance, none of its script based data sources could execute if users set their execution policies wrong. As such, I decided to do a minor rewrite of all of the rules to allow for two overridable path based exclusions as I suspect specific applications could generate some noise. I know that SCOM uses a lot of PowerShell scripts. I believe that Exchange does as well. This also allows someone to do an override for a specific object, a group, for for an entire class. I may revisit this to add more, but I that most of our applications keep these items in specific folders, so there shouldn’t need to be any changes there.  I’ll also use this data source for any PowerShell detection I write in the future that may need to be overridden.

I’ve also created similar rules targeted at Windows Event Collector servers. To me, this is probably a bigger thing. It shouldn’t be terribly noisy, as this type of behavior in the desktop environment strikes me as something that should be more rare, but perhaps I’m wrong. As such, there’s nothing overridable in that environment for now.

To override for a specific path, do the following:

• Identify the rule and the type of override you wish to do (i.e. group, all objects, specific object, etc).
• Configure the path based override as follows: