ADACL-005: WriteOwner Permissions on Critical Objects
- Platform
- Active Directory
- Category
- AD ACL & Delegation
- Severity
- Critical
- Zero Trust pillar
- Identity (weight 2)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check enumerates the security descriptor (nTSecurityDescriptor) of high-value AD objects and inspects every non-inherited ACE for the WRITE_OWNER access right (ActiveDirectoryRights flag 0x00080000 / WriteOwner). It walks the following object set: the domain root, AdminSDHolder (CN=AdminSDHolder,CN=System), the Domain Controllers OU, every protected group (groups with adminCount=1), KRBTGT, the Schema and Configuration NCs, GPOs linked to Tier-0 OUs, and any user or computer flagged as Tier 0. For each ACE granting WriteOwner, the check resolves the trustee SID, filters out default principals (BUILTIN\Administrators, NT AUTHORITY\SYSTEM, Enterprise Admins, Domain Admins, the SYSTEM-owned default ACEs from the defaultSecurityDescriptor of the schema), and reports the remaining trustees as findings.
Why it matters
The owner of an AD object is granted READ_CONTROL and WRITE_DAC implicitly by the Windows security model, regardless of what the DACL says. An attacker with WriteOwner therefore controls the object in two ACL writes: change owner, then rewrite the DACL. On Tier-0 objects the blast radius is full domain compromise. WriteOwner on Domain Admins lets an attacker add themselves to the group. WriteOwner on AdminSDHolder propagates an attacker-controlled ACE to every protected group within 60 minutes via SDProp. WriteOwner on a Domain Controller computer object enables Resource-Based Constrained Delegation abuse and DCSync via msDS-AllowedToActOnBehalfOfOtherIdentity or by writing servicePrincipalName plus a logon target. WriteOwner is functionally indistinguishable from WriteDACL or GenericAll for attack purposes, but it is often overlooked during ACL audits because it does not appear in the default "Full Control" check in dsa.msc.
Attack path
Step 1: Reconnaissance. The attacker runs BloodHound or SharpHound with -CollectionMethod ACL, or queries nTSecurityDescriptor directly via LDAP. BloodHound surfaces the edge as "WriteOwner" with a built-in attack path to GenericAll. Step 2: Take ownership. Using the compromised principal, the attacker calls Set-ADObject -Replace @{nTSecurityDescriptor=...} or PowerView Set-DomainObjectOwner -Identity "Domain Admins" -OwnerIdentity attacker. Impacket dacledit.py and BloodyAD set-owner achieve the same from Linux. Step 3: Grant GenericAll. As the new owner, the attacker has implicit WRITE_DAC and adds a GenericAll ACE for their account using Add-DomainObjectAcl -Rights All or BloodyAD add genericAll. Step 4: Abuse the access. For a group, Add-DomainGroupMember adds the attacker. For AdminSDHolder, the ACE is mirrored to all protected groups by SDProp. For a computer, the attacker writes msDS-AllowedToActOnBehalfOfOtherIdentity for RBCD, then requests a Kerberos service ticket as any user via S4U2Self/S4U2Proxy (Rubeus s4u). For KRBTGT, the attacker resets the password and forges a Golden Ticket.
How Guerrilla assesses it
Guerrilla performs an authenticated LDAP search with the SDFlagsControl (LDAP_SERVER_SD_FLAGS_OID, OwnerSecurityInformation | DaclSecurityInformation) to retrieve nTSecurityDescriptor on every target object. For each retrieved descriptor, the parser walks the DACL and emits an ACE record for entries where ((AccessMask & 0x00080000) != 0) and AceType is ACCESS_ALLOWED. Trustee SIDs are resolved against the domain and filtered against an allowlist of Tier-0 / default-by-design principals. Inherited ACEs are excluded by default unless --IncludeInherited is set, because inherited WriteOwner from AdminSDHolder onto protected groups is expected. The check also flags WriteOwner held by accounts that are themselves stale (lastLogonTimestamp older than 180 days), disabled, or kerberoastable, since those add a takeover path on top of the privilege.
Recommended value
No non-default principals with WriteOwner on critical AD objects
Remediation
Audit WriteOwner permissions on critical objects. Remove WriteOwner ACEs for non-default principals. Verify that object owners are appropriate privileged accounts. Enable ownership change auditing and monitor Event ID 4662 for WriteOwner operations.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6, AC-6(1), AC-3
- ANSSI
- vuln_permissions_writeowner
- MITRE ATT&CK
- T1222.001, T1098