Security Monitoring: Using SCOM to capture Suspicious User Activity

This is an extension of a previous rule that I wrote to use SCOM to track executables being run in user writeable locations. The concept behind this is similar, and it tracks another behavior of an attacker. Once they’ve compromised an account, they are going to execute a bunch of code. I wrote rules tracking specific places in the OS where they are looking to do their thing. They can also do that thing from a user profile of a compromised account. Really any place within that profile is a potential target, so it makes it hard to track. As such, I’ve written a new rule for Suspicious User Activity. Much like the other 4688 events SCOM is tracking, this will generate an alert any time a .ps1, .psm1, .exe is run from a user context…

Now there’s a downside to this one. It has the potential to be noisy. I know personally that I have never had a problem running PowerShell scripts off of my desktop or some location in my user share. A more organized person might do that differently, but I’m kind of lazy like that, and I’m not alone either I suspect. What that means is some admins doing normal activity will likely trigger it. I’ve made it overridable for that reason, and it’s matching the command line parameter, so really anything in the path can be overridden. I’d be careful with this obviously, as you can exclude by say a user name, entire script path, or script name. Doing something such as a user name would effectively mean that if Joe Admin’s account is compromised, you’d never know… so some planning might be wise. You could potentially exclude the path that a user uses, or just turn it off for a specific server if that’s the issue at hand. Where you should be concerned is if you see an alert from say a service account or something like that… since those accounts shouldn’t be executing anything out of their user profile.

Security Monitoring: Update to Log Clearing Rules

I had a customer bring this to my attention, but there are tools out there that will backup logs and clear them as needed. This will generate an unwanted noise when an automated tool clears the log. As such, I’ve re-written the rule to allow for an account based override. Here’s how it works.

The original rule has been disabled. It’s still there if you want to enable it for any reason, but I haven’t (at least as of now) pulled it out of the XML. I’ve created and enabled a new rule that does the same thing, but this has an additional statement looking for a user account, which is can be overridden.


In the screenshot above, you can override with the specific service account that is being used to clear the logs.

This will also apply to the rule looking for the system log being cleared.

This will be in the May update to Security Monitoring.