Share via

Breaking apart the GPO Modification Process and Using SCOM to Detect GPO Changes – Part 1

  • Article

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.

A while back a colleague of mine introduce me to some work done by two other colleagues which involved using SCOM to alert against changes made to GPOs.  First, Jan Varšavský wrote the framework for SCOM 2007 which was later updated by Nathan Olmstead.  Andres Naranjo took this a step further writing a composite data source that collected the key events along with step by step instructions to create a VSAE project with a nice demonstration as to how it works.  I’d love to say that I’m as smart as these guys, but in reality, they’ve done most of the heavy lifting.  A few weeks ago, I had the chance to chat with Andres about including this in the security management pack for SCOM that is currently in development. He gave his blessing to my request, but did note that there are a few issues with the rule as it is currently written. In particular, it generates multiple alerts for each change, which is something that I would personally like to dial back.

From a security perspective, I’m not sure how much the bad guys will mess with your GPOs once they are in your environment, but I’d imagine that this is not something that is potentially off limits to them.  I cannot envision many scenarios where they would outright delete a GPO, as that strikes me as the type of thing that someone might notice, but I could see them adding GPOs to deploy some of their malware or perhaps modifying an existing GPO to do the same, turn off auditing, or those types of things.  Keep in mind, that attackers have a much wider margin for error in poorly run environments, and as such have been known to be a bit more brazen with their activities.  Something like this could be beneficial, assuming of course the monitoring team has a good alert management process.

First, let’s start with the events that we are watching.  All of these come out of the Domain Controller security logs.  You will also need to have Directory Services Change Auditing configured for successes if you want this to work.

  • Event ID 5137 is fired when a new GPO is created.  That seems straight forward.
  • Event ID 5141 audits a GPO deletion.
  • Event ID 5136 audits the specific changes.

For the most part, Event ID 5136 is what we will be looking at, but as I dissected this process, it was clear that there’s a lot more to the 5136 events than I suspected at first. My first test was to change an existing GPO in my lab. As expected, I got 4 alerts. I filtered the security log on my domain controller and also confirmed there were four 5136 events.  This was in line with my expectation, so the next step was to configure suppression.  That wasn’t difficult to do as the gpoGUID was already being collected by the composite data source.  As such, I could add the following tag to the alert generating rule and drop the number of alerts from four to one.

            <Suppression>
               <SuppressionValue>$Data/Property[@Name='gpoGUID']$</SuppressionValue>
             </Suppression>

As is often the case, there is a draw back to this approach.  Those 5136 events are generated for each change, and as it happens in the case of my test, there were two writes and two deletes that were captured in the 5136 event. My suppression will let you know that a GPO changed, but if the action was nefarious in nature, you’re going to need to filter the security logs on the domain controller(s) in question to see what those changes were.  In my test, the alert mentioned the value add, and it still captured who made the change.  Personally, I’m fine with that draw back as I’m not a fan of using SCOM alerting as an inventory mechanism. Their purpose is to let you know that an event happened so you can investigate it.  Given that the user making the change is recorded, that can simply be verified and closed by contacting them and confirming (or if you have a good change management process in place, looking it up).

My second test did not behave as expected.  In this test, I created a new, empty GPO.  This generated 9 alerts in SCOM along with an “PowerShell script failed to run” warning as well.  After adding the suppression tag, this reduced to only one alert for the GPO change along with the PowerShell script failure alert.  Further investigation showed that on my domain controller, I observed eleven 5136 events and only one 5137.  That makes sense as logic would dictate that only one 5137 would be generated for a GPO creation. Unfortunately, this guy was also the reason for my script failure. The composite DataSource feeds parameter 15 as an input to the correlation script.  However, event ID 5137 has no parameter 15. As such, that blank value causes the script to fail when it tries to parse event 5137.  I could spend a lot of time reverse engineering the PowerShell and rewriting it, but I’m lazy at heart, and to top it off, not all that great with PS.

Instead, since 5137 generates only once, I removed it from the collection criteria and created a separate rule that looks for and alerts to the presence of a 5137 noting the creation of a GPO. In this scenario, I’ll get two alerts:  one for the creation of the GPO, and then a subsequent alert for the changes that naturally follow. It’s not ideal, but I can live with that.

Next up is Part 2, where I’ll cover detecting the deletion of a GPO as well as unlinking an existing GPO.