I found this to be an interesting technique shared by Huy Kha. In summary, its a way to remove yourself from domain admin but have the ability to add yourself anytime since you are associated with the managed by attribute. Many administrators would miss this permitting a malicious party to hide undetected.

Requirements:

Domain Admin account

As we all know, there are tons of ways, how attackers can hide themselves in Active Directory.

Today we are going to take the group Domain Admins as an example, but keep in mind that it is possible to do it on other groups as well. It is just an example, because everyone has once heard of ‘’Domain Admins’’

The purpose of this blog is to make it understandable for both system administrations and pen testers. Please do understand that I’ll try to do my best to make it for both audience understandable as possible.

Also I don’t claim any credits for this technique. It is not something new, but rather something that could have been overlooked by others.

In my blog post we’re going to assume that we already achieved Domain Admin and the goal is to hide ourselves as long as possible. Not to remain persistence, but just to hide ourselves. In every engagement you want to have a back-up plan. So you need a second account to perform this action and another account that is used to be the kind of backdoor that grants you permission.

At the following screen we can see that the user Anonymous is part of the Domain Admins group.

Now at the ‘’Managed By’’ attribute we need to add the user Anonymous

When looking for the user Anonymous, we’re able to find this account in Active Directory.

And we are nearly at the end. Which means that we need to hide ourselves in some objects in Active Directory.

At the beginning of this blog post, we added our user to ‘’Managed By’’ attribute at the Domain Admins group. We want to hide this for sysadmins, before they notice it.

To do this we have to deny read access for the ‘’Managed By’’ attribute. Not the entire Read Properties

This makes is less suspicious for sysadmins to notice this. It kinda looks normal to me isn’t it?

Since we’re part of the ‘’Managed By’’ attribute. We can still add/remove ourselves to this group. Make sure that the ‘’Manager can update membership list’’ has been check marked. Which is equal to ‘’Write Members.’’

Because we’re in Domain Admins. Means that we’re able to modify the AD Root object.

This means that we can control this object.

Which basically means that can add users to this object and modify their permissions.

So now we can add a user to this object and give Full control’’ permission on the AD Root. This gives them the opportunity to do DCSync and request remotely all the NT hashes of the users.

In a nutshell what we all just did.

We removed ourselves from Domain Admin, but do remain hidden in the ‘’Managed By’’ attribute at the group by denying read access to the managedBy attribute at the group. This allow us to add ourselves to the group at anytime as we want.

Here we have removed the user Anonymous from the list, but we’re still able to add the user to the group.

How do you detect this?

Check the DACL of high-privileged groups such as Domain Admins, Enterprise Admins or Administrators to see if some suspicious group or user has been added to it or what kind of ACL’s has been set.

The strange part is that, when you take a look at the permission section (blue) of the user Anonymous. You don’t see any ACL that has been granted to it if you decided to grant the user or group specific the ‘’Write Members’’. This could be overlooked and ignored by sysadmins if they decided to take a look at the Domain Admins object. Because the permissions section would look blank in ADUC.

This is something you already aware of it, but it is just a refresher.

How can we make it much more difficult to find us?

At the DACL of the high-privileged groups such as Domain Admin, Enterprise Admin and Administrators. There are a few interesting groups part of it, which are the following:

Cert Publishers
Windows Authorization Access Group
Terminal Servers License Servers

What if we as Domain Admin decided to add ourselves to one of these groups such as Cert Publishers, and then decide to add Cert Publishers to the managedBy attribute of Domain Admins and deny read managedBy for Everyone?

By default Cert Publishers is part of the DACL at the Domain Admins group. So this will make it less suspicious and even more harder to discover. Because this group has no special ACL granted, but if you grant in this case, the group Cert Publishers the specific ‘’Write Members’’ properties.

The permission section of Cert Publishers would look blank in ADUC.

Those default groups are often empty, but lets say that the sysadmin did decide to take a quick look at it. We could deny read members at it to make it look like the group is empty.

Terminal Server License Servers is an empty group in Active Directory that is part of the DACL at Domain Admins. Lets add the Domain Admin to this group now.