Today, I came across an interesting article (since posting, the original post has been taken offline) where the author described how an attacker could manipulate the permissions on extended attributes to create persistence once they have compromised an Active Directory domain.  Read the article for a great breakdown of the attack, but here’s a quick summary.

Step 1 – Domain Compromise

An attacker compromised Domain Admin privileges within Active Directory and wants to make sure they create some backdoors in case they lose the account they’ve compromised.

Step 2 – Abuse Active Directory Permissions

The attacker creates backdoors through Active Directory permissions.  In Huy’s article, he explains how this can be used to enable resetting of passwords as well as the DCSync attack.  Beyond that, we know AD permissions can be used to open up DCShadow.  In any case, the attacker makes a permission change to create a backdoor, but they don’t want somebody to discover they’ve made this change.  How can they hide it?  That’s where the extended attribute permissions come in.

Step 3 – Modify Permissions of Extended Attributes

Within Active Directory, in the configuration naming context (CN=Configuration,DC=domain,DC=local) there are objects which represent the different extended rights you can apply when assigning a permission.  In the post, the author modifies the CN=User-Force-Change-Password object to place a Deny ACL on Everyone.  As a result, no one can see the actual extended rights, so when they go to view the permissions on an object, they cannot tell that anybody has been granted that right (even though they have). 

So, that’s the gist of the attack (again read the post for full details). This is definitely something I had never thought of before and once I read it, I was curious to try it out in my labs and also see if this is an area StealthINTERCEPT could help prevent with its blocking policies. 

Blocking Extended Attribute Persistence

With StealthINTERCEPT, it was pretty straightforward to block this attack.  Building an Active Directory Lockdown policy, I selected the Extended Rights container and blocked all operations.

I decided it would be safer to block all users (even Domain Admins) from performing this attack since the premise of this attack is achieving persistence once you’ve already compromised a Domain Admin account.  

Next, I selected the specific attribute I wanted to block access to.  In this case, we want to prevent changes to the SACL, so I chose the nTSecurityDescriptor attribute:

And that’s it!  Now we have a rule that will block all users (even administrators) from changing permissions on anything in the Extended Rights container. 

After that was in place, I attempted to make a change such as the one outlined in the blog post. As expected, even though I was a Domain Admin, my access was denied.

I also got an alert from StealthINTERCEPT in real-time letting me know about the blocked attempt.  StealthDEFEND is also able to monitor for this activity and surface this as a threat to trigger the appropriate threat response.