“…Active Directory delegation is critical part of many
organisations' IT infrastructure. By delegating administration,
you can grant users or groups only the permissions they need
without adding users to privileged groups (e.g., Domain
Admins, Account Operators)…”*
* [source] http://windowsitpro.com/active-directory/view-remove-ad-delegated-permissions
• Windows Remote Administration Toolkit
• Windows attacking host with Admin Privileges
• Patience and Enumeration Skills!
AD PowerShell Cmdlets
• Import the AD PowerShell module on the attacking host
• The attack box isn’t part of the victim domain, so the AD drive cannot load
$Env:ADPS_LoadDefaultDrive = 0
• CN = Common Name
• OU = Organizational Unit
• DC = Domain Component
We (most likely) need:
• User credentials of some sort…
Questions to ask:
• What’s the Domain name / Distinguished Name (DN)?
OK, Bob (a member of “it_support_limited”) has the reset
password right over the Support OU
Questions to ask :
• Where does Jeff’s (or any other ‘useful’) account reside?
Abuse of Privilege…
• Looking at the previous enumeration results we see that Jeff is also in the support OU
SamAccountName : bob
SamAccountName : jeff
• Let's change his password!
=local' -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "P@ssw0rd"
-Force) -Server 192.168.99.100 -Credential "rebootuserbob"
To cut a long story (and many, many more slides of enumeration) IT_support_limited has password reset
rights over the UK OU and child entities and IT_support_priv has all possible delegation rights over the entire
Offices OU and child entities
Now we’ve inherited Jeff’s powerful delegation rights over
the entire Offices OU and sub entities!
Questions to ask :
• Are there any privileged accounts we can commandeer?
PWN all the Admins!
• From earlier recon we found an interesting user, godmode:
• Which groups is godmode a member:
Get-ADPrincipalGroupMembership godmode -Server 192.168.99.100 -Credential
"rebootuserjeff" | select name
• Ah, excellent Jeff has delegation rights here, lets change the password….
AdminSDHolder & SDProp
• AdminSDHolder is a container that exists in
each AD domain
• A protected group is an Active Directory group
that is identified as a privileged group. This
group and all its members should be protected
from unintentional modifications*
• When an AD group is marked a protected
group; AD will ensure that the owner, the ACLs
and the inheritance applied on this group are
the same as the ones applied on
* [source] https://social.technet.microsoft.com/wiki/contents/articles/22331.adminsdholder-protected-groups-and-security-descriptor-propagator.aspx
• So where do we go from here?
• We have powerful delegation rights – we can change passwords, modify group memberships, add
• DA is not necessarily the end goal
• Sensitive data is likely to be stored in group drives:
• If we recall, Bobs home directory resides in the following location:
HomeDirectory : DC-01Share$HomeBob
• …the list goes on
There are many directions we could take…
Questions to ask :
• DA is off the table (for now), but are there any other
sensitive groups we can pwn?
• Automated group enumeration – I won’t bore you with the PS query!
SamAccountName : IT_support_limited
SamAccountName : IT_support_priv
SamAccountName : it_users
SamAccountName : the_privileged_few
SamAccountName : hr_users
• We (Jeff) have delegation rights here - let's add ourselves (bob) to this group!
• Complex environments could easily faultier in delegation assignments
• Microsoft provide a nice wizard interface for assigning permissions…
….revoking permissions is not such a straight forward approach
• Often overlooked in pentests, but a prime target!
• ADUC > Advanced View > Security Tab