Tools · Active Directory defense · 15 / 23
DCSync explained: who has replication rights and how to detect misuse with Event 4662
Understand directory replication rights conceptually, list every account that holds them, and detect replication requests from non-DC machines.
Replication is a feature
Domain controllers replicate directory changes, including password hashes, using the Directory Replication Service protocol. An account with the extended rights Replicating Directory Changes and Replicating Directory Changes All on the domain root can request that data as if it were a DC. Attackers who obtain such an account can pull the hash of any user, including krbtgt, without touching a DC’s disk. That technique is commonly called DCSync.
Domain controllers, Domain Admins, Enterprise Admins, and Administrators have these rights by default. Microsoft Entra Connect’s sync account often has them for password hash sync. Anyone else is a problem.
List who holds the rights
Read the ACL on the domain root and look for the two extended right GUIDs: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes) and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes-All). Expand groups to members.
Every identity in the result needs a reason. A forgotten backup tool account or a user granted the rights during troubleshooting is a common finding.
$root = (Get-ADDomain).DistinguishedName
$guids = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2','1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
(Get-Acl "AD:$root").Access | Where-Object { $_.ObjectType -in $guids -and $_.AccessControlType -eq 'Allow' } |
Select IdentityReference, @{n='Right';e={ if ($_.ObjectType -eq $guids[1]) {'Get-Changes-All'} else {'Get-Changes'} }} | Sort IdentityReferenceLab: detect a replication request
Enable Audit Directory Service Access on DCs. Replication requests then generate Event 4662 with the replication right GUIDs in the Properties field. Normal events come from DC computer accounts, whose names end in $. In the lab, run a legitimate replication with repadmin /syncall and observe 4662 from the DC accounts.
Build the detection: 4662 containing either GUID where the Subject account is not a domain controller computer account or the known Entra Connect account. Network-based tools can also flag DRSUAPI traffic from non-DC addresses.
repadmin /syncall /AdeP
$dcs = (Get-ADDomainController -Filter *).Name | % { "$_`quot; }
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date).AddHours(-1)} |
Where-Object { $_.Message -match '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2|1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' } |
% { [pscustomobject]@{Time=$_.TimeCreated; Subject=$_.Properties[1].Value} } | Where-Object { $_.Subject -notin $dcs }If it happens
Treat any unexpected replication request as a full domain compromise. Assume all hashes were taken, including krbtgt. The response includes resetting krbtgt twice, resetting privileged account passwords, and hunting for the initial access.
Prevention is keeping the list of identities with these rights at the defaults and protecting them as Tier 0.
Diagram
Expected and unexpected replication
Same protocol, different requester.
Requester. DC computer accounts, Entra Connect sync account.
Event. 4662 with replication GUIDs from known accounts.
Action. None.
Requester. A user or workstation account.
Event. 4662 with Get-Changes-All from that account.
Action. Treat as domain compromise.
Check yourself
1. Which accounts should normally request directory replication?
2. Which event records replication requests when DS Access auditing is on?
3. An unknown account performed a replication request. What should you assume?