With this post and my last post, I guess I’m on a path of finding interesting ways to “break” AD. The last post related to AD denial of service and this one relates to an interesting way to get to privileged access on AD by gaining what would seem to be completely unrelated access on the domain NC “head”. This is the domainDNS object that represents your Active Directory Domain, as shown in the screen shot below:
Editing the Domain NC head in AD
By default, only privileged users should have access to write to the Domain NC head. The reason for this is that this object in AD actually holds some important information, like the password policy of the domain, as delivered by Group Policy, and some other domain specific settings. In addition, one of the other things that can be written on this object is the gpLink attribute. GPLink holds any GPOs that have been linked at the domain level, and this is where it gets interesting.
This topic came up on the Bloodhound Slack Channel and it got me thinking about how a user with just write permissions on this object could abuse that control to elevate their permissions in AD. There was no obvious path there until I started thinking about good old Group Policy. If I can write to the gpLink attribute on the domain object, how can that help me? Well, remember from my previous rants on Group Policy discoverability, it’s fairly easy for an unprivileged user to read GPOs in a domain to determine which GPOs grant privileged access (e.g. using Restricted Groups policy) and where those GPOs are linked. In fact, Bloodhound uses this fact to find paths to Domain Admin, by querying GPOs that use Restricted Groups policy, among others, to determine which users or groups have admin access in which GPOs, and where those GPOs are linked. So, let’s assume we have found a GPO using one of these methods, that grants the “Help Desk Admins” group as a member of the local Administrators group on a set of workstations, by virtue of that GPO being linked to a workstations OU somewhere down in the AD hierarchy. How can we abuse that if we have write access on the domain object?
Failing Upwards
One of the nifty and relatively unknown “features” of Restricted Groups policy is that works just as well when targeting domain controllers, as it does when targeting workstations and servers. So, imagine the following GPO that is currently in the domain and linked to the Marketing Workstations OU:
A GPO Granting Help Desk Admins, local Adminstrative access.
Now, there is nothing to prevent me from taking this GPO and adding a reference to it on the gpLink attribute of the domain object, assuming I have write access to that object. I just need the GUID of the GPO, and then I need to append it to the existing gpLink entries, which usually looks like this:
[LDAP://cn={5076F987-6FF9-47A4-A382-FB3D17EDEEEC},cn=policies,cn=system,DC=cpandl,DC=com;2][LDAP://cn={8378830A-7835-4820-A5FD-D41ABBD23FBB},cn=policies,cn=system,DC=cpandl,DC=com;0][LDAP://cn={4B20289F-CA64-4A1D-A9CD-4822A39BE064},cn=policies,cn=system,DC=cpandl,DC=com;2]
This is just a [] delimited list of the LDAP path to each GPO, referenced by it’s GUID, in the domain. At the end of the LDAP path, is a semi-colon delimited value that indicates the status of the link, where 0 is enabled, 1 is disabled and 2 is enforced.
Once I’ve added my Restricted Groups GPO to the link list at the domain level, what happens? Well, most obviously, all machines that process that policy in the domain, will have the Help Desk Admins group added to their local Administrators group. But…and here’s the kicker…guess what else happens? The Help Desk Admins domain group also gets added to the domain Administrators group in AD, because that GPO is processed by Domain Controllers as well! Yes, even though it’s not best practice to use Restricted Groups policy to manage AD group memberships, it works just fine, and in this case, we can take advantage of it to force an arbitrary group (in this case, Help Desk Admins) to be elevated to god-like status within AD, just by having write permissions on the domain object. Not bad, huh? Here’s an example of this below. I linked my arbitrary GPO, called “RGStealth”, to the domain object by writing it’s GUID into the gpLink attribute on that object. Once a domain controller processes that policy, you see the effect of it in the domain Administrators group to the right. Neat!
Using Restricted Groups to infiltrate domain administrators.
Summary
What’s the moral of the story? Well, don’t grant write access to the domain object to just anyone. It should be just as restricted as any other privileged object in AD because with just a little bit of information and access, it is relatively easy to bend existing GPOs to your will and use them for evil. And, if you managed to get write access on a GPO, Restricted Groups would be the least of your problems. You could write arbitrary settings into a GPO that would then get processed by Domain Controllers, amongst other machines. So…lock it down!