Lion Cipher Lab

DCSync: pull domain password hashes through the replication protocol in your own lab — then govern who can

• Penetration Testing / Red Team
• Advanced
• ~90 min
• Free · no account required

Why it matters

DCSync is how a foothold in Active Directory becomes total ownership of the domain, and it is one of the hardest attacks for defenders to reason about because nothing is 'broken'. Domain controllers keep each other in sync by replicating directory data over a protocol called MS-DRSR; part of that data is account secrets. Windows lets any principal holding the 'Replicating Directory Changes' rights ASK a DC to replicate those secrets -- so an attacker who has compromised an account with those rights can simply request the password hash of any user, up to and including krbtgt, from anywhere on…

What you'll learn

• explaining DCSync in plain words: it is not an exploit but an ABUSE of the Directory Replication Service (MS-DRSR) protocol that domain controllers use to sync with one another -- a principal with the right permissions asks a DC to replicate an account's secrets and receives its password hash
• naming the exact two permissions that make it possible: the 'Replicating Directory Changes' (DS-Replication-Get-Changes) and 'Replicating Directory Changes All' (DS-Replication-Get-Changes-All) extended rights on the domain object -- rights that Domain Admins, Enterprise Admins and DCs hold by default, and that should hold for almost nobody else
• running DCSync from a Linux attacker box with impacket's secretsdump -just-dc / -just-dc-user, pulling the NT hash of a single account and then of the whole domain, WITHOUT logging on to the DC or running code on it
• understanding why pulling the krbtgt account's hash is the crown-jewel outcome: it is the key used to sign Kerberos TGTs, so its hash enables forged 'Golden Tickets' -- domain-wide, long-lived access
• measuring the BEFORE state: a suitably-privileged account can replicate any secret at will, and it looks like ordinary DC-to-DC replication traffic on the wire
• auditing who actually holds the replication rights in your directory (reading the domain object's ACL for the two Rights-GUIDs) and REMOVING them from any principal that is not a DC or an approved sync account -- the least-privilege control
• turning on and reading the detection: Directory Service Access auditing produces Event ID 4662, and a DCSync shows up as a 4662 whose Properties contain the replication control-access GUIDs from a source that is NOT a domain controller -- the signal the sibling SOC lab hunts
• responding when krbtgt is exposed: resetting the krbtgt password TWICE (with the required wait between resets) to invalidate forged Golden Tickets, per Microsoft's forest-recovery guidance
• the judgment: DCSync cannot be 'disabled' because replication is core to how AD works, so the posture is least privilege (minimise who can), tiering (protect the accounts that can), and detection (alert when it happens) -- not a patch; and the honest limits (a Domain Admin can always DCSync by design, so the real control is minimising Domain Admins)
• placing it on MITRE ATT&CK -- T1003.006 (OS Credential Dumping: DCSync) -- and connecting it to the downstream risk (Golden Ticket forgery from the krbtgt hash)

Steps in this lab

1. First, the shape of the problem — an abuse of replication, not a bug
2. Set up: give a NON-admin account the replication rights (on purpose)
3. BEFORE — DCSync a single account, then the whole domain
4. Why this worked — and why there is no patch
5. GOVERN — find who can DCSync, and strip the rights, then re-measure
6. DETECT — turn on the audit event that catches DCSync
7. RESPOND — reset krbtgt twice, and the honest limits

Open the full interactive lab →