| name | conducting-domain-persistence-with-dcsync |
| description | Perform DCSync attacks to replicate Active Directory credentials and establish domain persistence by extracting KRBTGT, Domain Admin, and service account hashes for Golden Ticket creation. |
| domain | cybersecurity |
| subdomain | red-teaming |
| tags | ["red-team","active-directory","dcsync","persistence","credential-dumping","golden-ticket","mimikatz"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| d3fend_techniques | ["Application Protocol Command Analysis","Network Isolation","Network Traffic Analysis","Client-server Payload Profiling","Platform Monitoring"] |
| nist_csf | ["ID.RA-01","GV.OV-02","DE.AE-07"] |
Conducting Domain Persistence with DCSync
Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.
Overview
DCSync is an attack technique that abuses the Microsoft Directory Replication Service Remote Protocol (MS-DRSR) to impersonate a Domain Controller and request password data from the target DC. The attack was introduced by Benjamin Delpy (Mimikatz author) and Vincent Le Toux, leveraging the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights. Any principal (user or computer) with these rights can replicate password hashes for any account in the domain, including the KRBTGT account. With the KRBTGT hash, attackers can forge Golden Tickets for indefinite domain persistence. DCSync is categorized as MITRE ATT&CK T1003.006 and is a critical post-exploitation technique used by APT groups including APT28 (Fancy Bear), APT29 (Cozy Bear), and FIN6.
When to Use
- When conducting security assessments that involve conducting domain persistence with dcsync
- When following incident response procedures for related security events
- When performing scheduled security testing or auditing activities
- When validating security controls through hands-on testing
Most Often Missed & How to Confirm
- Attempting DCSync without both replication rights. The account needs both DS-Replication-Get-Changes and Get-Changes-All. Operators see one and assume failure. Confirm the actual grant before concluding the account can't replicate.
- Grabbing only RC4/NTLM. Pull AES256 keys too — forging a Golden Ticket with
/aes256 avoids the encryption-downgrade anomaly that RC4 tickets trigger in detections.
- Forgetting the domain SID. Without the SID (and ideally the krbtgt key version) the Golden Ticket is useless; capture it during the dump.
- Running against an RODC. A read-only DC won't hand over secrets; target a writable DC.
- Dumping
/all noisily when only krbtgt was needed — generates a replication spike and Event 4662 storm.
- How to confirm: secretsdump returns the line
krbtgt:502:aad3b435...:<ntlm hash>::: (and aes256_hmac keys with -just-dc), or Mimikatz lsadump::dcsync /user:krbtgt prints Hash NTLM:. Validate the replication right itself with the from the controlled principal to the Domain node. Don't conclude the account lacks rights until you've tested against a writable DC and verified both Get-Changes and Get-Changes-All are present.
