The content in this post describes a method by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for 5 minutes.
I presented on this AD persistence method at DerbyCon (2015).
Complete list of Sneaky Active Directory Persistence Tricks posts
AdminSDHolder is an object located in the System Partition in Active Directory (cn=adminsdholder,cn=system,dc=domain,dc=com) and is used as a security template for objects that are members of certain privileged groups. Objects in these groups are enumerated and any objects with security descriptors that don’t match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object Access Control List (ACL) with the security permissions set on the AdminSDHolder.
Objects protected by AdminSDHolder have the attribute “AdminCount” set to 1 and security inheritance is disabled.
Note that when an object is removed from one of the protected groups, AdminCount is not set to another value. This is due to early feedback when Windows 2000 was released.
Default AdminSDHolder Security ACLs
The AdminSDHolder object permissions are used as an ACL template for domain privileged groups.
Relevant AdminSDHolder default ACLs:
- Authenticated Users: Read
- SYSTEM: Full Control
- Administrators: Modify
- Domain Admins: Modify
- Enterprise Admins: Modify
AdminSDHolder Default Protected Objects
SDProp Protected Objects (Windows Server 2008 & Windows Server 2008 R2):
- Account Operators
- Backup Operators
- Domain Admins
- Domain Controllers
- Enterprise Admins
- Print Operators
- Read-only Domain Controllers
- Schema Admins
- Server Operators
A subset of these groups can be excluded from control, including Account Operators, Server Operators, Print Operators, Backup Operators.
Around 60 minutes later, the PDC Emulator runs and the account now has full control on the Domain Admins group.
Or, run SDPRop manually.
In Windows Server 2008 R2, Microsoft introduced a new rootDSE LDAP modify operation, called RunProtectAdminGroupsTask, to start the AdminSDHolder process.
The new Windows 2008 R2 RunProtectAdminGroupsTask-based mechanism provides a more efficient mechanism to enforce AdminSDHolder application. Under the hood, the older FixUpInheritance-based mechanism doesn’t really kick off the AdminSDHolder process—it starts the Security Descriptor Propagator Update (SDProp) process. SDProp has the same effect on the ACLs of critical security groups and accounts but takes much longer to complete. SDProp is the background AD process that propagates changes of inheritable ACEs on parent objects to their child objects. It’s automatically triggered when an object’s ACL is modified or when an object is moved. SDProp affects all AD child objects’ ACLs and not only the ACLs of critical AD security groups and accounts and will thus consume much more DC processing time.
SDProp Reference on WindowsITPro.com
Manual triggering of the SDProp process
FixUpInheritance (prior to Windows 2008 R2):
Windows 2008 R2 RunProtectAdminGroupsTask-based mechanism:
Exploiting AdminSDHolder & SDProp
Add the account or group to the AdminSDHolder object permissions granting either Full Control or Modify rights.
The user “Bobafett” is added in this example.
After running SDProp, Bobafett is automatically added to the Domain Admins group (along with the others listed above). Now this account can modify the Domain Admins group membership.
Note that the user account Bobafett has no group membership.
Despite not being a member of any groups, this account can now modify the group membership of Domain Admins.
AdminSDHolder is a sneaky method for an attacker to persist granting the ability to modify the most privileged groups in Active Directory by leveraging a key security component. Even if the permissions are changed on a protected group or user, SDProp will change the securtiy permissions to match that of the AdminSDHolder object.
Monitor the ACLs configured on the AdminSDHolder object. These should be kept at the default – it is not usually necessary to add other groups to the AdminSDHolder ACL.
Monitor users and groups with AdminCount = 1 to identify accounts with ACLs set by SDProp.
Find all users with security ACLs set by SDProp using the PowerShell AD cmdlets:
Get-ADObject -LDAPFilter “(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))” -Properties MemberOf,Created,Modified,AdminCount
- Five common questions about AdminSdHolder and SDProp
- AdminSDHolder, Protected Groups and SDPROP
- Manually run SDProp
Maybe interesting schedule task that check the ACL change; very simple example:
get-acl -Path “AD:\CN=AdminSDHolder,CN=System,DC=Domain,DC=test” | Select-Object -ExpandProperty Access | Export-Csv -Encoding Unicode C:\temp\ACLAdminHolder.csv
$currentGroup = get-acl -Path “AD:\CN=AdminSDHolder,CN=System,DC=Domain,DC=test” | Select-Object -ExpandProperty Access
$baselineGroup = import-csv -Path “C:\temp\ACLAdminHolder.csv”
$diff = Compare-Object -ReferenceObject $baselinegroup -DifferenceObject $currentGroup -Property “IdentityReference”
if ($diff -ne $null)
foreach ($item in $diff)
$user = $item.IdentityReference
if ($item.SideIndicator -eq “=>”)
$mailbody = “AdminSDHolder ACL change detected, compare results”
$mailbody = “AdminSDHolder ACL change detected, compare results”
send-mailmessage -from “KK@domain.test” -to “firstname.lastname@example.org” -subject “Check AdminHolderACL” -body $mailbody -smtpServer “mail1.domain.test”
Other audit/monitor tools could do the same in real-time too.
In any case, we would have a lot of problems…
Thanks for all of your info.
Blue Team SysAdminsGroup
For me, the best way to check changes on ACLs (and many other objects or attributes) is to check replication metadata.
With your solution you won’t be able to detect modifications if the attackers revert changes.
Whereas with replication metadata you’ll see a jump of 2 in the version of the metadata.
You can’t also rely on logs because an attacker could have modify the searchflags attribute of one of the schema attribute to disable audit. For example, modify the searchflags attribute (add never_audit_value) of the nt-security-descriptor attribute in the schema and then you could modify ACLs without being detected.
Have a look at my old wiki article (in french …) : http://social.technet.microsoft.com/wiki/contents/articles/25946.metadata-de-replication-et-analyse-forensic-active-directory-fr-fr.aspx
As Sysadmin (I’m not a security expert), I appreciate so much this kind of information and help; I can try more things to secure our “environment”.
Thanks a lot again!
Really interesting article, and clever way to hide the power of a sleeper account.. Question though: The title says “…get domain admin rights”. Don’t you already need to be a Domain admin or equivalent to modify the AdminSDHolder object?
Noted. Title updated.