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.
The XML view shows something completely different.
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:
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:
Please note for any bugs and/or feature requests, please reach out to me on LinkedIn.
I wanted to take a few minutes and discuss current plans for upcoming changes in the security MP. I’d also like to use this space as an open forum for feature requests. While I’m not expecting tons of requests, it is worth noting that I do have a few criteria for any change I make.
- It needs to be something that should not generate a lot of noise when enabled. More than anything, that means I’ll need to have a unique way of identifying the issue in question. Several (not all) of my PtH rules are off by default for precisely that reason, they aren’t unique to PtH related events.
- For Operational Threats, I’d prefer to be tracking items that are currently in use or increasingly being used by the bad guys.
- Obviously, I need to stay within the limits of what the SCOM libraries can provide. Event log and registry key analysis are pretty easy. I’d note that anything that can be scripted in PowerShell should be relatively easy as well.
That said, feel free to drop a comment here for any ideas. You can also hit me up on linked in.
These are my current plans for updates:
- I want to rewrite the scheduled task rule to allow for overrides for specific applications. Unfortunately, this one is noisy as way too many commercial applications create their own scheduled tasks in task scheduler. This would allow users to override for specific applications in their environment.
- Similarly, I’d like to rewrite the service created on DC rule to do the same thing. In general, services should not be created on domain controllers fairly often, so this is worth monitoring for potential threats. However, it seems that some applications do occasionally create a service on a domain controller. This would allow a user to override for that specific service.
- I did find some false positives with local account creation, as those events can be generated on domain controllers. I didn’t see this in testing, but I did observe this at a customer recently. I’ve written in an override for the next release to turn this off on domain controllers.
- I would like to remove alerting for batch logons and put this in as a report. It’s worth noting that batch logons are very insecure, but this also is generating a lot of noise. The nice thing about a report is that you can see where these logons are occurring and update your applications accordingly…. at the very least, these machines could be segregated in your environment as to make it harder for an attacker to access the machine and steal credentials.
- I would like to write a collection rule/report for TLS 1.0 and 1.1 authentications. These too are insecure protocols and should be shut off in an organization. The idea behind this would be similar to the NTLM/LanMan/Wdigest/SMB1 reports. It should be able to tell a user where this authentication is happening in an environment so as to fix any applications that are using it and allow an organization to shut it off. I don’t know how easy this will be. My initial research (though to be fair I haven’t spent more than a few minutes looking into this) didn’t find an easy way to detect this. I’ll probably also need some beta-testers here as I doubt I have these protocols running in my lab.
Beyond that, I don’t have too much in the way of changes scheduled. I’d definitely like to hear more from the community as to what they would like to see. I think we’ve hit most of the low hanging fruit, which is good, but that also means it will take a lot more effort for additional features.