Search/ GitHub
PW-002Attack pathControl and privilege paths

Account or group outside Tier Zero can DCSync

An account outside Tier Zero holds the replication rights that let it download every password hash in the domain.

Category
Attack Path
Severity
At least High.
Typical owner
AD / identity team
Data needed
Any collection: the replication rights come from the domain object's permissions, which every collector reads. Rights held through nested groups are reported once, on the outermost group.
MITRE ATT&CKT1003.006
Most useful toDefensive engineersIdentity and access engineersOffensive operatorsAuditors
On this page

In plain language

Domain controllers copy the directory, password hashes included, to each other through replication. Two permissions on the domain allow it. Whoever holds both can ask a domain controller for any account's password hash, including the krbtgt key that signs every Kerberos ticket. The technique is called DCSync.

Only domain controllers, and a few tightly controlled sync services such as Entra Connect, should have these rights. Anyone else who holds them has the power of a Domain Admin, whatever their group memberships say.

What Pathwarden flags

A user, computer or group outside Tier Zero holds both directory replication rights on the domain object: "Replicating Directory Changes" and "Replicating Directory Changes All" (directly or through group membership). Together they let it ask a domain controller for the password hash of any account.

How attackers use it

DCSync (OS Credential Dumping: DCSync, T1003.006) lets an attacker who controls this account or group pull the krbtgt hash and every admin hash remotely, without touching a domain controller's disk. With the krbtgt hash they can forge golden tickets and keep domain access until krbtgt is rotated twice. Tools such as Mimikatz and Impacket secretsdump do this in one command.

Find it with Pathwarden

Data needed: Any collection: the replication rights come from the domain object's permissions, which every collector reads. Rights held through nested groups are reported once, on the outermost group.

In the web UI or the HTML report, open the Findings tab and expand PW-002: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-002
# the step-by-step guide on this page, offline
pathwarden guide PW-002
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-002

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

  • Identify what the account or group is. Legitimate holders besides domain controllers are rare: Entra Connect (MSOL_ / AAD sync) accounts, some identity governance, backup or password-sync products.
  • Check whether it actually replicates: on domain controllers, audit "Directory Service Access" and look for event 4662 with the replication GUIDs 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 and the account as subject.
  • If it is a sync account that must keep the rights, do not remove them: treat the account and its server as Tier Zero instead (Option B).

How to fix it

  1. In Active Directory Users and Computers, enable View > Advanced Features.
  2. Right-click the domain, Properties > Security > Advanced.
  3. Find entries for the account (or the group that grants it) with "Replicating Directory Changes" / "Replicating Directory Changes All".
  4. Select each and click Remove, then OK.
  5. If the right comes through a group, remove the account from that group instead.

Option B: Keep the rights, manage the account as Tier Zero

  1. Add the account and the server it runs on under Additional Tier Zero in Settings.
  2. Restrict logon to that server to Tier Zero admins, protect the account (long random password or gMSA where the product supports it), and monitor event 4662 for replication from any other source.
  3. If the sync server has been retired, disable the account and remove the rights as in Option A.

By default only Domain Controllers, Enterprise Domain Controllers and Administrators hold both rights on the domain object.

PowerShell

PowerShell
Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl -Path "AD:\$domainDN"

# Replication extended rights
$getChanges    = [Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
$getChangesAll = [Guid]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"

# Show who holds them
$acl.Access | Where-Object { $_.ObjectType -in $getChanges, $getChangesAll } |
    Select-Object IdentityReference, ObjectType, IsInherited

# Save the current descriptor, then remove the account's entries
$acl.Sddl | Out-File ".\domain-acl-backup.txt"
$acl.Access | Where-Object {
    $_.ObjectType -in $getChanges, $getChangesAll -and $_.IdentityReference -like "*<Account>"
} | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$domainDN" -AclObject $acl

Verify the fix

Re-run the "Show who holds them" query; only domain controllers, Enterprise Domain Controllers, Administrators and intended sync accounts should remain. Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

Restore the saved descriptor: $acl = Get-Acl "AD:\$domainDN"; $acl.SetSecurityDescriptorSddlForm((Get-Content .\domain-acl-backup.txt)); Set-Acl "AD:\$domainDN" $acl

References

  1. Microsoft: Configure AD DS connector account permissions (Entra Connect)learn.microsoft.com
  2. SpecterOps: BloodHound documentationbloodhound.specterops.io
  3. SpecterOps BloodHound docs: DCSyncbloodhound.specterops.io
  4. MITRE ATT&CK T1003.006: OS Credential Dumping: DCSyncattack.mitre.org

↑↓ to moveEnter to openEsc to close