This chapter covers the DCSync attack, a powerful post-exploitation technique that allows an attacker to impersonate a domain controller and request password hash replication from a legitimate DC. For the PT0-002 exam, this topic falls under Domain 3 (Attacks and Exploits), specifically objective 3.4: 'Given a scenario, perform post-exploitation techniques.' Expect 1-2 questions directly on DCSync mechanics, detection, and mitigation. Understanding DCSync is critical because it represents a pinnacle of privilege escalation—once an attacker has replication rights, they effectively own the domain.
Jump to a section
Imagine a high-security office building with a central key room that stores a master key for every door. Only the security director and a few authorized backup operators are allowed to enter the key room. The backup operators have a special procedure: they can request a copy of any master key by filling out a form that says 'I need to replicate the key for backup purposes.' The security director's system is designed to trust this request because it comes from an authorized backup operator using the proper replication protocol. Now, imagine an attacker steals a backup operator's badge and walks into the key room. They fill out the same form, and the system hands over a copy of the CEO's office master key. The system never questions whether the backup operator actually needs that key—it just sees the valid replication request and complies. In Active Directory, DCSync works exactly like this. The attacker gains an account with Domain Replication privileges (like a domain admin or a specially delegated account) and then uses a tool like Mimikatz to send a valid DSGetNCChanges request to a domain controller. The DC, believing the request is legitimate replication traffic, responds with the password hashes for any user the attacker requests—including the KRBTGT account, which can forge golden tickets. The attacker never needs to log in to the DC or run code on it; they simply abuse the trust inherent in the replication protocol.
What Is DCSync and Why Does It Exist?
DCSync is a post-exploitation attack that abuses the Active Directory replication protocol to extract password hashes from a domain controller without running code on the DC itself. The attack was first publicly documented by Benjamin Delpy (gentilkiwi) in Mimikatz version 2.0 in 2015. It exploits the legitimate functionality of directory replication—specifically the Directory Replication Service (DRS) Remote Protocol, defined in MS-DRSR. In a normal AD environment, domain controllers replicate changes (including password hashes) among themselves to maintain consistency. The DCSync attack allows a user with appropriate privileges (such as Domain Admins, Enterprise Admins, or accounts delegated the 'Replicate Directory Changes' permission) to request any object's secrets from a DC as if they were another DC.
How DCSync Works Internally
The attack leverages the DSGetNCChanges method of the DRS protocol. Here is the step-by-step mechanism:
1. Prerequisite: The attacker must have an account with one of the following extended rights on the domain:
- 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 (GUID: 89e95b76-444d-4c62-991a-0facbeda640c)
These permissions are typically granted to Domain Admins, Enterprise Admins, and the built-in administrators group. However, they can be delegated to any account, which is a common misconfiguration.
Initiating the Request: Using a tool like Mimikatz (lsadump::dcsync), the attacker sends a DsGetNCChanges request to a target DC. The request includes the object's distinguished name (DN) of the user whose secrets are desired, or * for all users.
DC Response: The target DC, believing the request is from a legitimate replication partner, responds with a DsGetNCChanges response containing the requested object's replPropertyMetaData and, critically, the dBCSPwd (password hash), UnicodePwd, and NTLMHash attributes. These are the password hashes (both NTLM and LM, if available) and the supplemental credentials.
Extraction: The attacker receives the hashes and can then use them for pass-the-hash, offline cracking, or golden ticket attacks. The most valuable target is the KRBTGT account, whose hash can forge Kerberos tickets granting domain admin access.
Key Components, Values, Defaults, and Timers
DRS Protocol: Uses RPC over TCP on port 135 (endpoint mapper) and dynamically assigned high ports (typically 49152-65535) for the actual replication traffic. In modern Windows, replication uses TCP port 389 (LDAP) or 636 (LDAPS) for the initial binding, then switches to a dedicated RPC port.
Extended Rights: The three permissions listed above are granular. The most common is DS-Replication-Get-Changes-All, which allows retrieval of all attributes, including sensitive ones.
Default Groups: Domain Admins, Enterprise Admins, and the built-in Administrators group have these rights by default. The Exchange Windows Permissions group is also often delegated these rights in Exchange environments, which is why Exchange servers are a common vector.
Tooling: Mimikatz is the classic tool, but others exist: Invoke-DCSync in PowerSploit, SharpKatz, DCSync in Impacket's secretsdump.py, and CrackMapExec with the --dcsync flag.
Detection: Event ID 4662 (An operation was performed on an object) with Object Type domainDNS and Access Mask 0x100 (control access) or 0x200 (list object). Also, Event ID 4624 for logon sessions from the attacking machine. The key is looking for DS-Replication-Get-Changes on a non-DC computer.
Configuration and Verification Commands
To check which accounts have replication rights:
# Using Active Directory PowerShell module
Get-ADObject -Identity "DC=domain,DC=com" -Properties nTSecurityDescriptor | Select -ExpandProperty nTSecurityDescriptor
# Or use ADSI Edit to view the security descriptor of the domain objectTo audit replication permissions with PowerView:
Get-DomainObjectAcl -Identity "DC=domain,DC=com" -ResolveGUIDs | Where-Object { $_.ActiveDirectoryRights -match "Replication" }To perform a DCSync with Mimikatz:
lsadump::dcsync /domain:targetdomain.com /user:AdministratorTo perform with Impacket:
secretsdump.py domain/user:password@targetdc -dc-ip 10.0.0.1 -just-dc-user krbtgtInteraction with Related Technologies
Kerberos: DCSync is often a precursor to Golden Ticket attacks. The KRBTGT hash allows forging TGTs.
SYSVOL/GPP: DCSync can extract cpassword from GPP if the attacker has replication rights, though GPP passwords are deprecated.
Azure AD Connect: If Azure AD Connect is present, the connector account may have replication rights, providing a path to cloud hybrid attacks.
Group Managed Service Accounts (gMSA): DCSync can retrieve gMSA passwords if the attacker has replication rights and knows the group's DN.
Detection and Mitigation
Monitoring: Enable auditing for Directory Service Access and Directory Service Changes. Use Event IDs 4662 and 5136 (modification of directory objects). Look for DS-Replication-Get-Changes from non-DC machines.
Honeytokens: Create a user account with a fake hash and monitor for DCSync attempts on that account.
Least Privilege: Remove replication rights from accounts that do not need them. Regularly audit delegated permissions.
Protected Users Group: Add high-value accounts to the Protected Users group, which prevents caching of NTLM hashes (but does not prevent DCSync of the hash from the DC).
SID Filtering: Not directly applicable, but forest trusts should have SID filtering enabled to prevent inter-forest DCSync.
Common Misconceptions
Many believe DCSync requires code execution on the DC. In reality, the attacker only needs network access to the DC and valid credentials with replication rights. Also, some think DCSync only works against the PDC emulator, but it works against any writable DC. Finally, DCSync does not require the attacker to be in the Domain Admins group—any account with the specific extended right can perform it.
Gain credentials with replication rights
The attacker first obtains credentials for an account that has the 'Replicate Directory Changes' permission on the domain. This could be through phishing, pass-the-hash, or privilege escalation from a lower-privileged account. Common targets are Domain Admins, Enterprise Admins, or accounts delegated these rights, such as service accounts for backup software or Exchange servers. The attacker may also use tools like BloodHound to identify accounts with these rights.
Identify a reachable domain controller
The attacker needs network connectivity to a writable domain controller. They can discover DCs via DNS SRV records (_ldap._tcp.dc._msdcs.domain.com) or by querying the current DC using nltest /dsgetdc:domain. The attacker must ensure the target DC is not firewalled from their position. If the attacker is on a segmented network, they may need to pivot through a compromised host that has access to a DC.
Execute DCSync using Mimikatz or equivalent
The attacker runs a DCSync command specifying the target domain and the user whose hash they want. For example, with Mimikatz: `lsadump::dcsync /domain:contoso.com /user:Administrator`. The tool sends a DsGetNCChanges request to the DC. The DC processes the request and returns the password hashes and other secrets for the specified user. The attacker receives the hashes in memory or writes them to a file.
Extract and crack or pass the hash
The attacker now has the NTLM hash of the targeted user. They can use this hash in a pass-the-hash attack to authenticate as that user without knowing the plaintext password. Alternatively, they can use offline cracking tools like Hashcat or John the Ripper to attempt to recover the plaintext password. If they extracted the KRBTGT hash, they can forge a golden ticket granting domain admin access.
Lateral movement and persistence
With the compromised hash, the attacker can move laterally to other systems, access sensitive data, or create backdoor accounts. If they obtained a domain admin hash, they can now authenticate to any system in the domain. The attacker may also extract additional hashes of other users to widen their foothold. Persistence can be established by creating a new domain admin account or modifying group memberships.
In a typical enterprise, DCSync is a critical threat that often goes undetected because it uses legitimate replication traffic. I've seen three common deployment scenarios where DCSync is particularly dangerous:
Scenario 1: Exchange Server Delegation Many organizations delegate replication rights to the Exchange Trusted Subsystem group to allow Exchange servers to access directory data. Attackers who compromise an Exchange server (e.g., via ProxyShell or ProxyLogon) can then use DCSync to extract domain admin hashes. In one engagement, we found that the Exchange server had been delegated 'Replicate Directory Changes All' rights, and once we gained a shell on the Exchange server, we used Mimikatz to dump the KRBTGT hash. The client had no monitoring for DCSync because they assumed only domain controllers would make replication requests.
Scenario 2: Backup Software Accounts Backup solutions like Veeam or CommVault often require accounts with domain admin privileges or replication rights to back up Active Directory. These service accounts are frequently configured with weak passwords or stored in scripts. In a red team operation, we extracted the backup service account's credentials from a configuration file and used them to DCSync the entire domain. The backup server was not a domain controller, so the DCSync traffic stood out in logs, but the SOC had not configured alerts for non-DC replication.
Scenario 3: Cloud Hybrid Environments Organizations using Azure AD Connect sync passwords to the cloud. The Azure AD Connect server has an account (MSOL_*) that is granted replication rights. If an attacker compromises the Azure AD Connect server, they can DCSync on-premises AD. In one case, the attacker used a vulnerability in the Azure AD Connect health service to gain local admin, then used the MSOL account to DCSync the domain. This gave them access to both on-premises and cloud resources.
What goes wrong: Most misconfigurations stem from over-delegation. The default permissions for Domain Admins are often inherited by service accounts. Additionally, many organizations fail to monitor Event ID 4662 for non-DC machines performing replication. The recommended mitigation is to implement a 'replication firewall'—only allow specific IP addresses (the actual DCs) to make replication requests. This can be done via Windows Firewall or network segmentation. Also, use Protected Users group to limit NTLM caching, though it does not prevent DCSync itself.
For PT0-002 objective 3.4, the exam will test your understanding of DCSync as a post-exploitation technique. Here's exactly what you need to know:
Objective Code: 3.4 – Perform post-exploitation techniques. DCSync falls under 'Extract password hashes' and 'Domain privilege escalation.'
Common Wrong Answers: 1. 'DCSync requires local admin on the DC' – This is false. DCSync does not require code execution on the DC; it only needs network access and credentials with replication rights. Many candidates assume you need to be on the DC itself. 2. 'DCSync only works against the PDC emulator' – False. It works against any writable DC. The PDC emulator is often targeted because it holds the most recent password changes, but any DC will respond. 3. 'DCSync is prevented by enabling SMB signing' – False. SMB signing does not affect DRS RPC traffic. DCSync uses RPC over TCP, not SMB. 4. 'DCSync can be blocked by disabling the Directory Replication Service' – False. Disabling DRS would break AD replication entirely. The correct mitigation is to restrict who can perform replication.
Specific Exam Numbers:
The three permissions: DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2), DS-Replication-Get-Changes-All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2), DS-Replication-Get-Changes-In-Filtered-Set (89e95b76-444d-4c62-991a-0facbeda640c).
Event ID 4662 for DCSync detection.
Mimikatz command: lsadump::dcsync /domain:contoso.com /user:krbtgt.
Impacket: secretsdump.py domain/user:pass@DC -just-dc-user krbtgt.
Edge Cases:
DCSync can be performed against read-only domain controllers (RODCs) but only if the attacker has the 'Replicate Directory Changes' permission on the RODC's allowed password replication group. However, RODCs do not store all hashes; they cache only specific users.
In a multi-domain forest, an Enterprise Admin can DCSync across all domains because the permission is on the forest root.
DCSync can also extract the plaintext password if reversible encryption is enabled (stored as 'reversible password' in the supplemental credentials).
How to Eliminate Wrong Answers:
If the question says 'The attacker compromised a workstation and ran DCSync,' the answer is that the workstation must have network access to a DC and the attacker must have credentials with replication rights. The workstation itself does not need to be a DC.
If the question asks for the best mitigation, look for 'Remove replication permissions from non-DC accounts' or 'Monitor Event ID 4662 for non-DC replication.'
If the question asks what hash is most valuable, the answer is KRBTGT because it enables golden ticket attacks.
Memorize the three GUIDs for the replication permissions, as the exam may present them as part of a scenario.
DCSync abuses the MS-DRSR protocol (DsGetNCChanges) to request password hashes from a DC.
The attacker needs an account with DS-Replication-Get-Changes-All permission (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2).
DCSync does not require code execution on the DC; it is a network-based attack.
The most valuable target is the KRBTGT account hash, which enables Golden Ticket attacks.
Detection relies on Event ID 4662 for non-DC machines performing replication operations.
Mitigation involves removing replication rights from non-DC accounts and monitoring for anomalous replication traffic.
Tools: Mimikatz (lsadump::dcsync), Impacket secretsdump.py, PowerSploit Invoke-DCSync.
DCSync works against any writable DC, not just the PDC emulator.
Exchange Trusted Subsystem and backup service accounts are common vectors for delegation.
Protected Users group does not prevent DCSync; it only prevents caching of NTLM hashes on clients.
These come up on the exam all the time. Here's how to tell them apart.
DCSync Attack
Requires network access to a DC and credentials with replication rights.
Does not require any code execution on the DC; uses legitimate DRS protocol.
Extracts individual user hashes on demand without copying the entire database.
Leaves event log evidence (Event 4662) but is often missed by SOCs.
Can be performed remotely from any machine with network connectivity to the DC.
NTDS.dit Dumping
Requires local administrator access on the DC to access the NTDS.dit file.
Involves copying the database file (often via Volume Shadow Copy) and extracting hashes offline.
Extracts all user hashes at once; the entire database must be processed.
Leaves evidence of VSS creation and file access (e.g., Event 7036 for Volume Shadow Copy).
Requires physical or remote desktop access to the DC; cannot be done purely over the network.
Mistake
DCSync requires local administrator privileges on the target domain controller.
Correct
DCSync only requires a valid account with DS-Replication-Get-Changes-All permission. The attacker does not need to run code on the DC; they just send a replication request over the network.
Mistake
DCSync only works against the PDC emulator role holder.
Correct
DCSync works against any writable domain controller. The PDC emulator is often targeted because it has the most up-to-date password changes, but any DC will respond to the replication request.
Mistake
Enabling LDAP signing or SMB signing prevents DCSync.
Correct
LDAP signing and SMB signing do not prevent DCSync because DCSync uses DRS RPC, not LDAP or SMB. However, enabling LDAP channel binding and signing can help prevent LDAP-based attacks but not DCSync.
Mistake
DCSync can be detected by looking for Mimikatz binaries on disk.
Correct
DCSync can be performed with various tools, including built-in Windows commands via PowerShell (using ADSI) or remote tools like Impacket. The attack leaves no binary footprint on the target DC. Detection relies on network traffic and event logs, not file scanning.
Mistake
DCSync only extracts NTLM hashes, not Kerberos keys.
Correct
DCSync extracts the entire supplemental credentials structure, which includes NTLM hashes, LM hashes, Kerberos keys (AES128, AES256, DES), and even plaintext passwords if reversible encryption is enabled.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
DCSync is a post-exploitation technique that allows an attacker to impersonate a domain controller and request password hashes from a legitimate DC using the Directory Replication Service (DRS) protocol. The attacker needs an account with DS-Replication-Get-Changes-All permission. The attack is stealthy because it uses legitimate replication traffic and does not require code execution on the DC. On the PT0-002 exam, remember that DCSync is a network-based attack, not a local privilege escalation.
The attacker needs one of three extended rights on the domain object: DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2), DS-Replication-Get-Changes-All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2), or DS-Replication-Get-Changes-In-Filtered-Set (89e95b76-444d-4c62-991a-0facbeda640c). The most common is DS-Replication-Get-Changes-All. These rights are typically held by Domain Admins, Enterprise Admins, and the built-in Administrators group, but can be delegated. For the exam, know the GUIDs and that the permission is on the domain object itself.
Yes, but with limitations. An RODC only caches credentials for users who have authenticated to it or are in the Allowed Password Replication Group. An attacker with replication rights on the RODC can DCSync only those cached hashes. However, if the attacker has Enterprise Admin rights, they can DCSync against writable DCs instead. On the exam, remember that RODCs are not a complete defense against DCSync.
DCSync is a network-based attack that extracts hashes on demand using the DRS protocol. NTDS.dit dumping requires local admin access to the DC to copy the database file and extract hashes offline. DCSync is stealthier because it does not leave forensic artifacts on the DC's disk, but both yield the same hashes. On the exam, know that DCSync is preferred by attackers because it is remote and does not require file system access.
Enable auditing for Directory Service Access (Event ID 4662). Look for an account that is not a domain controller performing a control access operation (Access Mask 0x100) on the domain object with the property DS-Replication-Get-Changes. Also monitor for unusual network traffic to DCs on high RPC ports. Use tools like Microsoft Sentinel or Splunk to correlate 4662 events from non-DC machines. On the exam, Event ID 4662 is the key detection mechanism.
An attacker can extract password hashes for any user, including the KRBTGT account. This allows pass-the-hash attacks, offline cracking, and Golden Ticket forging. The attacker can also extract Kerberos keys for silver tickets. Ultimately, the attacker can gain domain admin access and persist indefinitely. On the exam, the worst-case impact is full domain compromise.
Partially. DCSync uses RPC over TCP. If you block all RPC traffic except between domain controllers, you can prevent non-DC machines from initiating replication. However, this is difficult to implement because many management tools also use RPC. A more practical approach is to use Windows Firewall rules to allow replication only from known DC IPs. On the exam, know that network segmentation is a compensating control, not a complete block.
You've just covered DCSync Attack and Domain Replication — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?