Hiding in the Shadows at ‘’ManagedBy’’ Attribute

Hiding in the Shadows at ‘’ManagedBy’’ Attribute

by Huy Kha


Requirements:

  • Domain Admin account
  • Domain User account

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

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 have a back-up plan. So you need a second account to perform this action and one that 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

After we have done that. We should do the same the AD Root

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

Now to hide ourselves we first need to create a new OU and add the user Anonymous in the OU that we just created.

In the following screenshot you can see that the OU ‘’Backdoor’’ has been created and Anonymous is part of that OU.

Now we need to deny read access to this object for everyone. Which means that we have to add ‘’Everyone’’ at the DACL of the Backdoor OU first.

Now we need to select ‘’Deny’’ read access for everyone.

In the following screen, we can’t see the OU ‘’Backdoor’’ anymore in the list.

Now lets try to find the user ‘’Anonymous’’ again 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 AD Root and the group Domain Admins. 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, but in most mature organizations. There are tools such as Netwrix in place. Which can give alerts when someone was added to the Domain Admins group.

But do you remember that we also added ourselves to the ‘’Managed By’’ attribute of the AD Root?

This means that we can control this object, despite that we aren’t part of the AD Root object.

In this case we also have to deny read permissions for Everyone at the ‘’Managed By’’ attribute of the AD Root.

Despite that the user Anonymous is not part of the AD Root object. We still can control it, which means that we’re also able to add users to this object and modify their permissions.

Most of the security products won’t detect or notice this. 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.

Lets pretend that Alice Ciccu was our second account that we were using for our engagement. And the sysadmin did notice it and starts to remove to our second account (Alice) from the AD root. We can still log back on the the user Anonymous and give Alice ‘’Full control’’ permissions again.

This will give sysadmins a very hard time to discover the root cause of the problem, because the ‘’Managed By’’ attribute looks just normal to him/her.

Good luck with trying to find our kind of backdoor account named ‘’Anonymous’’

Credits:

This blog post is inspired by the likes of SpectreOps.


The article has been originally posted at: https://medium.com/@huykha10/hiding-in-the-shadows-e3c32b89fc1c


July 10, 2019

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013