Security Monitoring 1.7.x is up

There isn’t much to this year’s update. I didn’t get a ton of feature requests, but I did get a couple and built them in. This is the change log.

  • Updated Local Admin Change rule to account for GPO enforced Local Admin Settings.
  • Fixed a couple of alert replacement bugs.
  • Added more overrides options for some powershell rules.
  • Updated Log Clearing alerts to allow for a user account override.
  • Added an exclusion to PowerShell logging for an Azure path as well as SCOM 2019 default path.
  • Fixed a bug with the alert description for the PowerShell running in memory rule.
  • Added rule for suspicious user logons.
  • Added an exclusion for WindowsAzureNetAgent on the service creation on DC rule.

Also worth noting that I’ve moved all content off of technet galleries and on to github. I’m not a github expert by any means, so I’m still figuring out the pull requests and fun stuff associated with that, but this could eventually become a community project with the right volunteers. Here is a link to both the previous and current content.

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: Updating Local Account Monitoring for GPO Enforced Settings

It was brought to my attention that the local admin group monitoring rule that I’ve written becomes incredibly noisy if GPO enforcement is used on local admin groups. Essentially what happens in that situation is that every time a machine applies the GPO, it fires off the 4732 and 4733 events that are being monitored. This can lead to thousands of alerts in this scenario. As such, I’ve re-written the rule, but I’d note that it gets a bit tricky. The main issue revolves around how SCOM processes events. It’s worth noting that SCOM only processes the XML, so using the friendly names won’t work. I’ve attached a couple of examples from my lab to show the difference.

This first screenshot is the friendly view. As you can see, it’s pretty straight forward. I used my admin account in this case to add a test account to the local administrator group on my SCOM server.

image

The XML view shows something completely different.

image

As you can see from the screenshots, for whatever reason, the SID is recorded in the XML view. I looked into a couple different ways to reduce noise for this; but unfortunately, the only workable solution would be to filter the rule based on the user IDs being recorded in the event, and since these are SIDS, we will need to obtain the SIDs from either ADSI Edit or from the Attribute Editor in Active Directory Users and Computers. I’ve baked 5 SID based overrides into this rule, which should hopefully be enough. It looks like this if you need to override it:

image

The easiest method to obtain the SID of the account(s) in question is to use the Attribute Editor in Active Directory Users and Computers. This requires advanced features to be turned on (this is in the view menu, and there should be a check box next to advanced features if it’s enabled).

It will look like this:

image

Please note for any bugs and/or feature requests, please reach out to me on LinkedIn.

Security Monitoring Partnering with Easy Tune

Tune the Security MP in a fraction of the time

Good news! I have written a Tuning Pack for my Security Management Pack which means you can tune the pack in a fraction of the time with Easy Tune from Cookdown. My Tuning Pack is live today on the Easy Tune Community Store

What is Easy tune?

Easy Tune is a new (and free) way of setting overrides to tune SCOM alerting. Traditionally, tuning a management pack is painful – its about 10 clicks to set a single override and some management packs contain thousands of workflows you may want to tune, multiply this problem by multiple groups and you can see how days can be spent tuning.

Easy Tune takes the head ache out of setting up overrides by allowing you to set them quickly with Tuning Packs (which are essentially CSV files)

clip_image002

To get you started there is a Community Store (a GitHub repro) containing community curated Tuning Packs which you can tune directly from, and if you think the Tuning Packs available could be improved or added to, you can submit a PR to change overrides or simply create your own Tuning Packs. This can be done by copying a Tuning Pack from the Community Store, creating one from management packs installed in your SCOM environment.

Tuning packs contain “levels” which you can tune to. A level is basically a list of overrides stored in a column of a tuning packs CSV. All Tuning Packs, including ones you create yourself automatically get levels “Discovery Only” and “MP Defaults” (as Easy Tune can work these out from the source MPs automatically), as well as being able to specify your own overrides – these are great for understanding what the MP author intended the value to be or for turning off all workflows which aren’t discoveries (which will reduce SCOMs workload and allow you to tune up on a per group basis as needed)

clip_image004

One of the great things about Tuning Packs is their simplicity – they are just CSV files which is great when it comes to reviewing overrides with other teams or updating override values. The can easily be reviewed with domain experts to agree desired tuning without looking at SCOM at all (lets face it, the SCOM console it not a thing of beauty).

Once you have reached alert nirvana with Easy Tune, there are is a config drift tool built in to shine a light on where your effective overrides have drifted from those you set, allowing you to keep your tuning in tip top shape.

The folk at cookdown give all of this away for free. I think it is an awesome tool that is a must for all SCOM admins

Easy Tune PRO

Cookdown sell a PRO version of Easy Tune too – it adds some excellent additional features:

· Time of day alert tuning – allows you to specify different override values for specific times/days. Very useful for ramping up monitoring for the 9am Monday morning logon storm where you want to make sure everything is working as it should or for disabling monitoring during the nightly backup job.

· Automation capabilities via PowerShell – allows you to script tuning and solve any unique issues you have with tuning which aren’t supported out of the box

· Rich override config drift detection – config drift is shown along side each Tuning Pack where the effective monitoring is not what you have set with Easy Tune and gives you tooling to see where the effective monitoring is set to help you resolve conflicts.

I haven’t had a chance to play with the PRO features but they look really cool (especially time of day alert tuning!) but you can read more about it here.

Security Monitoring Future Plans (May 2019)

The good news about this project is that we’ve been able to knock out a lot of low hanging fruit that can be used to detect some of the bread crumbs that an attacker leaves behind as well as identifying where legacy protocols are being used. The bad news is that most of the low hanging fruit has been picked clean. This space will be used to help identify and track future plans.

I’m going to stick with a 1 year cadence. This has been developed mostly by me on my own time, and as such there’s only so many hours to go around. My current plans are as follows:

  • I would like to develop an administrative account monitoring component targeting admin accounts. I’m not sure how easily this will be able to be accomplished. Enumerating these against a DC is not that hard to do, but in order to alert on these, these objects would need to be created on each and every DC. This isn’t realistic from a performance standpoint. There’s currently an unhosted class and disabled discovery in this MP, but nothing is targeted against it. The hope would be to come up with a way to start tracking admin accounts in general, logons outside of business hours, etc.
  • I’m hoping to delve more into WMI monitoring with the next release.
  • There are a few rules that I could see re-writing to add overridable parameters.
  • Likely going to write some detection mechanisms around this SCOM vulnerability.

This is not a big list presently, but as time permits I hope to grow it. Any suggestions are always appreciated.

Security Monitoring Change Log May 2019

  • Updated Task Scheduler Creation Rule
  • Updated Service Creation on DC Rule
  • Disabled alert rule for Batch Logon. There is a report that is capturing this. The rule is still present and can be enabled.
  • Created override for Local Account Creation rules for domain controllers. While this didn’t appear in any testing, I was told that some security software can generate false positives for this one on domain controllers. Since DCs don’t have local accounts to begin with, I simply turned this off for domain controllers.
  • Fixed a bug with regsvr32 remote registration of DLL rule.
  • Added rules/discoveries associated with writeable locations in the OS. Note that there are three parts to this series.
  • Added rule to detect attempt to kill windows defender.
  • Added collection rule and report for TLS usage.
  • Added rules for suspicious PowerShell Usage.  For instructions on overrides, please see the addendum.
  • Removed dependency on SQL MP.
  • Added rule for WMI Persistence.
  • Added rules for WMI Remoting.
  • Distributed application
  • Added a timeout as an overridable parameter to the SMB1 collection rule. The specified timeout of 60 seconds was causing failures in my lab. I upped this value to 300 seconds as the default setting.
  • Turned off registry monitor for WDigest settings. This was not needed in Server 2012/2016. With Server 2008 going out of support, I’ve disabled the monitor. It is still present if someone desires to use it.