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.
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.
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.
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.
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.
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits – now part of Netwrix, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Learn why Active Directory security should be a priority for your organization and ways to mitigate against a data breach with this free white paper!Read more
Start a Free Stealthbits Trial!
No risk. No obligation.
Leave a Reply