About a year ago, I posted about the perils of granting someone write access on the Active Directory Domain NC “head” object, and how you could use that and some quirks in Restricted Groups policy to essentially elevate your access in AD, just based on being able to link arbitrary GPOs at the domain level. This peril also exists if an attacker can link GPOs to the Domain Controllers OU or edit GPOs already linked at the Domain Controllers OU. I encourage you to re-read that previous post, but the bottom line is that Restricted Groups policy, when applied to domain controllers, can impact AD local groups (e.g. Administrators) just like it can impact local groups on member servers and workstations. I was playing around with this for a recent talk I gave at the HIP Conference in Raleigh, and I noticed something interesting, that I thought was worth mentioning.
CAVEAT: The first point to re-iterate here is that YOU SHOULD NOT BE USING RESTRICTED GROUPS POLICY FOR MANAGING AD GROUPS! This is simply not supported by MS and what I talk about here is strictly from the perspective of a malicious user/attacker trying to gain elevated access to AD using this not-very-well-documented mechanism that exists in Restricted Groups policy. With that clear, let’s get on with it…
Restricted Groups and AD Auditing
What I noticed is that, when someone uses Restricted Groups to monkey with an AD local group, such as Administrators, the normal AD audit events are not logged to the security log on the originating DC. As an example, in many environments, customers have enabled the “Directory Services Changes” Advanced Audit Configuration category on their DCs. This generates a predictable set of event IDs whenever AD is changed: 5136 for changed objects, 5137 for newly created objects, 5139 for moved objects and 5141 for deleted objects. Many AD auditing solutions explicitly look for these event IDs and IT shops look for these events to get notified when something in AD has changed. What’s interesting about Restricted Groups policy applied to a DC, is that it does NOT log a 5136 event when the DC process that policy and adds a user or group to that local Group. Wait, what? That’s right, if someone manages to get a hold of one of these GPOs linked to a DC and injects arbitrary groups into the domain Administrators group, you won’t see a normal event log entry for it. In fact, you won’t see any event log entry for it, unless you have enabled the “Audit Security Group Management” subcategory under “Account Management” in Advanced Auditing. If you do have that enabled, you will see the following event:
Group Management Audit Event
This Event ID is 4732, and is the only evidence of what happened to that local group. So the bottom line here is to make sure that you watch for these events as well, as a malicious user might use this lack of transparency to try to slip one by you and get their group elevated without you noticing.
Group Tattooing
Another “feature” of Restricted Groups policy used against domain controllers, is that, if you remove the GPO that delivered the group, it is not automatically removed from the AD group. This is in contrast to the way Restricted Groups works against member servers and workstations, where as the policy is removed, the group is reverted back to it’s prior state. So, if you do have groups in AD that have been manipulated in this way, you’ll need to proactively go and remove the added members from those groups.
GP Preferences Local Users and Groups
Since Restricted Groups policy behaves this way, I naturally wondered if the GP Preferences Local Users and Groups feature also exhibited this behavior. So I tested it. The good news here is that GP Preferences Local Users and Groups does not work at all against AD groups, at least in the limited testing I did against the local Administrators group in my test domain. So, you’re at least safe there 🙂
Bottom line here is that you need to know what to look for in your AD audit logs if you are worried about attackers taking advantage of this path. Make sure your auditing tools are looking for all the required event IDs as I’ve mentioned above, and once again, HARDEN YOUR GPOS and YOUR SOMs (sites, domains and OUs).
Darren