Abusing Active Directory Permissions with PowerView

One of my favorite presentations at Derbycon V was Sean Metcalf (@pyrotek3)’s talk “Red vs. Blue: Modern Active Directory Attacks & Defense“. In it, Sean had a section focused on “Sneaky AD Persistence Tricks”, meaning methods “by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for 5 minutes“. I wanted to show how one of the methods covered, the abuse of AdminSDHolder and SDProp, can be facilitated with new PowerView 2.0 functionality.

Note: I did not discover this attack method. I also will only give a brief background on the underlying components, as Sean has an excellent in-depth post on this approach, which I highly recommend everyone read before continuing.

I’ll also cover another way to quickly backdoor an AD domain that was built from other pieces of Sean’s presentation and @gentilkiwi‘s Mimikatz project. In short, there is a small set of permissions needed to execute Mimikatz’ DCSync functionality, and with PowerView you can now easily add those permissions to any user (even if they aren’t in a privileged group). Big thanks to @gentilkiwi and Vincent Le Toux for DCSync \m/

Edit: Obvious note: you need to have elevated access in order to change these permissions. These approaches are a backdooring mechanism, not an escalation path.

AdminSDHolder Brief Overview

AdminSDHolder is a special Active Directory object located at “CN=AdminSDHolder,CN=System,DC=domain,DC=com“. The stated purpose of this object is to protect certain privileged accounts from accidental modification. Every 60 minutes, a special process called SDProp recursively enumerates membership for a specific set of protected groups, checks the access control lists for all accounts discovered, and clones the ACLs for the AdminSDHolder object to any protected objects with a differing ACL. Sean details what groups are protected by default in his post.

Any account/group which is (or once was) a part of a protected group has their AdminCount property set to 1, even if the object is moved out of that protected group. With PowerView 2.0, you can now easily enumerate all users and groups with AdminCount=1 with Get-UserUser -AdminCount and Get-NetGroup -AdminCount, respectively. This lets you quickly find all high value accounts, even if they’ve been moved out of a protected group. Invoke-UserHunter now also accepts an -AdminCount flag, letting you easily hunt for all high valued users in the domain.

AdminSDHolder Abuse

Sean describes that if you modify the permissions of AdminSDHolder, that permission template will be pushed out to all protected accounts automatically by SDProp. So you can add an unprivileged user (even with no group membership) to the ACL for AdminSDHolder, and have a backdoor mechanism pushed out that lets you modify the membership of groups like Domain and Enterprise Admins! This can certainly be done manually, but it seemed like a great candidate to add to PowerView’s functionality. Under Sean’s prodding, I had already added the ability to enumerate object ACLs (Get-ObjectACL -SamAccountName X), and it was a simple step to add in ACL manipulation as well.

Add-ObjectACL is a cmdlet that takes a -TargetSamAccountName/-TargetName/-TargetDistinguishedName/etc. to determine the Active Directory object to manipulate the permissions of, and a -PrincipalSID/-PrincipalName/-PrincipalSamAccountName to determine the object permissions to add to the target. The -Rights argument takes “All” (for complete control), “ResetPassword” (for password manipulation), “WriteMembers” (for group member manipulation), or “DCSync” (more on this at the end of the post).

For example, if you wanted to add the ability for user ‘will’ to reset the password for user ‘matt’ in the current domain, this is the command you’d use (with elevated privileges obviously):

Add-ObjectACL -TargetSamAccountName matt -PrincipalSamAccountName will -Rights ResetPassword

If you wanted to execute the AdminSDHolder attack that Sean described, you can add the -TargetADSprefix ‘CN=AdminSDHolder,CN=System’ flag. This will preface the LDAP query string with the AdminSDHolder AD location. We can then add -Rights All to execute the attack, and check the results with Get-ObjectAcl -ADSprefix ‘CN=AdminSDHolder,CN=System‘ -ResoleGUIDs (-ResolveGUIDs will resolve the GUID strings for various rights to their canonical names for display).

Add-ObjectAcl -TargetADSprefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName matt -Verbose -Rights All

Within 60 minutes, we can verify that these permissions were propagated to groups like ‘Domain Admins’:

Get-ObjectAcl -SamAccountName "Domain Admins" -ResolveGUIDs | ?{$_.IdentityReference -match 'matt'}

DCSync Permissions

Sean covered the required permissions to execute DCSync on slide 60 of his presentation. The permissions needed vary based on domain functional level, explained in the “DACL required on each directory partition” chart here:

• The “DS-Replication-Get-Changes” extended right
  • CN: DS-Replication-Get-Changes
  • GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
• The “Replicating Directory Changes All” extended right
  • CN: DS-Replication-Get-Changes-All
  • GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
• The “Replicating Directory Changes In Filtered Set” extended right (this one isn’t always needed but we can add it just in case :)
  • CN: DS-Replication-Get-Changes-In-Filtered-Set
  • GUID: 89e95b76-444d-4c62-991a-0facbeda640c

With PowerView 2.0’s Add-ObjectAcl cmdlet, we can easily add all three of these permissions to the domain root for any user (“-Rights DCSync” will alias all the GUIDs needed). Here’s how we can grant these rights to the unprivileged ‘chris’ user in the dev.testlab.local domain:

Add-ObjectACL -TargetDistinguishedName "dc=dev,dc=testlab,dc=local" -PrincipalSamAccountName chris -Rights DCSync

We can now DCSync any account we wish from the DC for dev.testlab.local, despite being in no privileged groups, having no malicious sidHistory, and not having local admin rights on the domain controller itself!

WrapUp

Active Directory access rights are a relatively unexplored area from a (public) offensive perspective. Defenders should start auditing and monitoring the rights of specific privileged domain objects, especially the domain root and AdminSDHolder. This can be done manually, through PowerView’s Get-ObjectACL, and I’m sure through other methods. If anyone has additional manual (or automated) methods for the detection of this type of action, or if I made a mistake/overlooked something in this post, please let me know in the comments, on IRC (#psempire on Freenode), or by email (will [at] harmj0y.net).