TTechniqueActive Directory

DCSync

Credential AccessadvancedT1003.00614 min

DCSync uses Active Directory's built-in replication protocol to request password data for any account in the domain, without accessing a domain controller's file system, memory, or running processes. This lesson explains why the technique works, what permissions enable it, what the attacker gains, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.

This lesson builds on

Why it matters

DCSync is the endgame credential extraction technique in Active Directory. It allows an attacker with the right permissions to extract the password hash for every account in the domain, including the krbtgt account, remotely, through a legitimate protocol, without touching a domain controller's operating system.

Understanding DCSync matters because it is the technique that converts directory-level permissions into full domain credential compromise, and interviewers expect candidates to explain why replication rights are the most sensitive permissions in AD.

Key Concepts

Replication rights — DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain object; together they allow requesting password data through the replication protocol; these are the most sensitive permissions in AD
No DC access required — DCSync operates over the network using standard replication protocol calls; the attacker does not need to access NTDS.dit, LSASS, or any process on the domain controller
The protocol does not verify the requester is a DC — any account with replication rights can issue replication requests; the DC processes them identically whether the source is a legitimate replication partner or an attacker's workstation
krbtgt hash as the ultimate target — the krbtgt account's hash enables golden ticket creation; golden tickets impersonate any user with any group membership and survive all password changes except krbtgt rotation
Delegated replication rights are common — directory sync tools (Azure AD Connect, identity management products) often have replication rights granted to their service accounts; these accounts become priority targets
Detection via replication monitoring — DCSync generates DS-Replication-Get-Changes requests (Event ID 4662 with specific GUIDs) from non-DC sources; monitoring for replication requests from workstations or member servers is the primary detection method

Theory

Preconditions

DCSync requires an account with two specific extended rights on the domain object: DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Together, these rights allow the account to request password data through the directory replication protocol.

By default, only Domain Admins, Enterprise Admins, and the domain controller computer accounts have these rights. However, they can be delegated, and misconfigured delegations are a common finding. Service accounts for directory synchronization tools (Azure AD Connect, identity management products) are frequently granted replication rights and become high-value targets.

The attacker needs network access to a domain controller on the standard RPC/LDAP ports. No access to the DC's file system, memory, or console is required.

Why it works

Active Directory uses a replication protocol (MS-DRSR) to synchronize directory data between domain controllers. When a DC needs to synchronize with another DC, it requests changes, including password hashes, through this protocol. The receiving DC authenticates the requesting identity and checks whether it has the replication extended rights on the domain object.

The protocol does not verify that the requester is actually a domain controller. Any account with the replication rights can issue the same replication requests that DCs use to synchronize. The DC processes the request identically whether it comes from a legitimate replication partner or from an attacker's workstation.

This means an attacker with replication rights can request the password hash for any single account (targeted extraction) or replicate the entire directory database (full extraction): all through a protocol that is designed for exactly this type of data exchange.

Attacker gain

DCSync gives the attacker the password hash for any account in the domain. The most impactful targets are:

krbtgt account: its hash enables golden ticket creation, granting persistent, unrestricted access to the entire domain that survives password changes on all other accounts
Domain Admin accounts: their hashes enable direct administrative authentication to any domain resource
All accounts: full replication yields every account's hash, supporting offline cracking, credential reuse across environments, and comprehensive access

Because the extraction uses a legitimate protocol, it generates replication traffic that blends with normal DC-to-DC synchronization. The attacker does not need to touch the DC's NTDS.dit file, LSASS memory, or any process on the DC itself.

Where it fits

DCSync sits at the culmination of the privilege escalation chain. The attacker reaches it through one of several paths:

Direct compromise of a Domain Admin account (any technique that yields DA credentials)
Compromise of an account with delegated replication rights (service accounts for sync tools)
ACL abuse to grant themselves replication rights (WriteDACL on the domain object → add replication extended rights)
Delegation abuse that allows impersonation of a DC machine account

Once DCSync is performed, the attacker has effectively extracted the full credential store. The krbtgt hash is the final prize: it enables golden tickets that provide persistent, difficult-to-remediate access to the entire domain.

Tools / examples

Mimikatz lsadump::dcsync /user:krbtgt: requests the krbtgt account's password data through the replication protocol; outputs the NT hash and Kerberos keys
Impacket secretsdump.py -just-dc domain/user@DC: performs DCSync for all accounts or targeted accounts; supports hash-only extraction without full replication
Mimikatz lsadump::dcsync /all: replicates password data for every account in the domain; equivalent to extracting the full NTDS.dit credential store
PowerView Get-ObjectAcl -DistinguishedName 'DC=domain,DC=local' -ResolveGUIDs | ? {$_.ObjectAceType -match 'Replication'}: identifies which accounts have replication rights on the domain object
BloodHound: marks accounts with DCSync rights as high-value targets and shows paths from compromised principals to accounts with replication permissions

Defender view

Audit which accounts have DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain object. Every account with these rights should be documented, justified, and treated as Tier 0.
Monitor for replication requests from non-DC sources. Event ID 4662 with the DS-Replication-Get-Changes GUID (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2) from a source that is not a domain controller is a strong DCSync indicator.
Protect directory sync service accounts as Tier 0 assets. Accounts for Azure AD Connect and similar tools have replication rights and should be secured with strong passwords, MFA where possible, and restricted logon rights.
Regularly rotate the krbtgt password (twice, to invalidate both current and previous keys). This limits the window during which a compromised krbtgt hash enables golden tickets.
Remove unnecessary replication delegations. If a synchronization tool has been decommissioned, its service account's replication rights should be removed immediately.

Communication

Explain it to a stakeholder

DCSync is a technique where an attacker with specific directory permissions requests a copy of password data for any account in your organization, through the same mechanism your domain controllers use to synchronize with each other. The attacker does not need to break into a domain controller or access its files. They simply ask for the data through a legitimate protocol, and the domain controller provides it because the permissions allow it.

The most sensitive target is the master encryption key for your domain's authentication system. If the attacker obtains it, they can create authentication credentials for any employee, including administrators, and this access persists until the key is explicitly rotated. The fix is auditing who has these replication permissions and restricting them to only the accounts that genuinely require them.

Report language

Finding: DCSync: Full Domain Credential Extraction via Replication Rights. During the assessment, the operator compromised the svc_aadconnect service account, which has DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain object. Using Mimikatz DCSync, the operator extracted the NT hash for the krbtgt account and all Domain Admin accounts. A golden ticket was created using the krbtgt hash, providing persistent domain-wide access. The svc_aadconnect account was configured for Azure AD Connect synchronization with a password that had not been changed in 18 months.

Severity: Critical.

Recommendation: Rotate the krbtgt password twice immediately. Change the svc_aadconnect password and restrict its logon rights. Audit all accounts with replication rights on the domain object. Monitor for replication requests from non-DC sources.

Common weak answers

Describing DCSync as 'dumping the AD database' without explaining that it uses the replication protocol, not file access, not LSASS extraction. The mechanism matters because it explains why no DC access is needed.
Not mentioning the specific permissions required. DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain object are the precondition. Saying 'you need Domain Admin' is technically sufficient but misses that delegated replication rights are the real attack surface.
Not explaining why the krbtgt hash is the highest-value target. It enables golden tickets: persistent, unrestricted access that survives all password changes except krbtgt rotation.
Treating DCSync as a tool feature ('run secretsdump') rather than a protocol-level technique. The tool is irrelevant; the technique works because the replication protocol is designed to transfer password data.
Not mentioning detection. DCSync generates identifiable replication events (Event ID 4662) from non-DC sources. This is the primary detection signal and a common follow-up question.

Interview answer

DCSync uses AD's built-in replication protocol to request password hashes for any account in the domain. The attacker needs DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights on the domain object: these are the permissions that allow requesting credential data through the replication protocol. The protocol does not verify that the requester is actually a domain controller, so any account with these rights can issue the same requests DCs use to synchronize.

The most impactful target is the krbtgt account, because its hash enables golden ticket creation: persistent, unrestricted access that survives all password changes except krbtgt rotation. DCSync does not require accessing the DC's file system or memory. Detection focuses on monitoring replication requests from non-DC sources, since legitimate replication only occurs between domain controllers.

Follow-up questions

What specific permissions does an account need to perform DCSync, and where are those permissions set?
Why is the krbtgt hash the most valuable target for DCSync, and what does an attacker do with it?
How does DCSync differ from extracting credentials from NTDS.dit or LSASS?
What monitoring would you recommend to detect DCSync activity?
If you found a decommissioned service account with replication rights still configured, how would you explain the risk?

Study Kit