AD-ACL-002: Non-default control over AdminSDHolder¶

high   Permissions   MITRE ATT&CK T1098   Reads: LDAP

A principal outside tier 0 can rewrite the AdminSDHolder object, whose DACL SDProp copies onto every protected admin account and group every hour.

Also known as: adminsdholder

Why it matters¶

CN=AdminSDHolder,CN=System is a template. Every 60 minutes the Security Descriptor Propagator (SDProp) on the PDC emulator overwrites the security descriptor of every protected account and group (members of Domain Admins, Enterprise Admins, Administrators, the operator groups, krbtgt and so on) with the AdminSDHolder one.

1. An attacker who can write the AdminSDHolder DACL adds an ACE giving their account full control.
2. Within an hour SDProp stamps that ACE onto every protected object.
3. They reset a domain admin's password or add themselves to Domain Admins.

It is also a classic persistence trick: an administrator who removes the attacker's ACE from Domain Admins sees it come back at the next SDProp run.

How ad-doctor detects it¶

ad-doctor reads the DACL of CN=AdminSDHolder,CN=System,<domain> (the effective ACEs, including those it inherits when inheritance is on, see AD-ACL-005) and reports every principal outside the default tier-0 set that holds a takeover right:

• GenericAll or full control,
• GenericWrite,
• WriteDacl or WriteOwner,
• WriteProperty on all attributes (an ACE with no object type).

Default tier 0 here is Administrators, Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers, Enterprise Domain Controllers, the read-only DC groups, the built-in Administrator and SYSTEM. Each object is the principal's name, for example helpdesk. Ownership of AdminSDHolder is not evaluated.

Severity¶

Always high: control of AdminSDHolder becomes control of Domain Admins, Enterprise Admins, Administrators and every other protected group and member within an hour.

False positives and limits¶

• Delegated tier-0 tooling, such as a privileged access management product that manages protected accounts through AdminSDHolder. Treat its service account as tier 0 and accept the finding with an owner (../ci.md#accepted-risks).

Fix¶

1. Review the AdminSDHolder DACL (read-only):

   $holder = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
   (Get-Acl "AD:$holder").Access |
       Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty' } |
       Format-Table IdentityReference, ActiveDirectoryRights, ObjectType, IsInherited -AutoSize
   

2. Remove the ACEs for the reported principals. dsacls /R removes every ACE for the trustee, so check step 1 first:

   # dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=example" /R "CORP\helpdesk"
   

3. Wait for SDProp (60 minutes) or run it now, then confirm the ACE is gone from a protected group such as Domain Admins as well.

4. If the grant was not intended, investigate: who added it and when (directory service change auditing, event 5136 on the DCs), and what the principal did with protected accounts since.

Verify¶

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ACL-002

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ACL-002"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

Related checks¶

• AD-ACL-004
• AD-ACL-005
• AD-ACC-006
• AD-PATH-001

References¶

Microsoft and vendors

• Appendix C: Protected accounts and groups in Active Directory

Research

• Sneaky Active Directory Persistence #15: Leverage AdminSDHolder & SDProp (Sean Metcalf)
• An ACE Up the Sleeve: Designing Active Directory DACL Backdoors (SpecterOps)

MITRE ATT&CK

• T1098

Available since 0.1.0.