DCSync to domain dominance
An account with directory-replication rights can ask a domain controller to replicate secrets — pulling every account's hash, including krbtgt — which turns a single over-privileged delegation into full, persistent control of the domain.
Scenario
An authorized internal engagement where a prior phase has yielded an account that holds replication rights (DS-Replication-Get-Changes / -All) — often through an unintended ACL rather than Domain Admin. The objective is to demonstrate the blast radius of that right and how domain persistence would be established.
- 1
Discovery
Find who can replicate
Enumerate which principals hold the replication extended rights on the domain object. These are frequently granted by accident to service accounts, connectors or nested groups — map them, because any one of them is a path to every secret in the domain.
DetectionReads of the domain object's ACL and replication-rights enumeration (often via BloodHound-style collection) are catchable with directory auditing.
MitigationAudit and remove unnecessary DS-Replication rights, and alert on changes to the domain object's DACL.
- 2
Credential Access
Replicate domain secrets
Using the replication rights, request that a domain controller replicate account secrets (the DCSync technique) — retrieving password hashes without running code on the DC. Pull the krbtgt account's hash specifically, documenting that the right alone was sufficient.
DetectionReplication (DsGetNCChanges) requests from a host that is not a domain controller are a high-fidelity DCSync signal in directory-service logs.
MitigationRestrict replication rights to domain controllers, monitor for non-DC replication, and tier administration so no workstation account can replicate.
- 3
Persistence
Forge long-lived access
With the krbtgt hash, demonstrate that a Golden Ticket could be forged to impersonate any user for an arbitrary lifetime — showing why krbtgt compromise means the domain must be considered fully compromised, then document for remediation rather than deploying lasting access.
DetectionTickets with anomalous lifetimes or mismatched account/RID data, and TGS use without a preceding AS exchange, are detectable with Kerberos auditing.
MitigationRotate the krbtgt password twice (the only real recovery after exposure), and monitor for ticket anomalies.
- 4
Lateral Movement
Demonstrate reach
T1550.002 Use Alternate Authentication Material: Pass the HashT1078.002 Valid Accounts: Domain AccountsShow that the recovered hashes grant access across the estate — for example authenticating to hosts with a privileged account's hash — to map how total the compromise is, strictly within the agreed scope and with everything logged for clean-up.
DetectionHash-based authentication (no interactive logon), and privileged logons from unusual hosts, are strong signals with logon auditing and Credential Guard telemetry.
MitigationCredential Guard, tiered administration, unique local-admin passwords (LAPS), and enforcing that privileged accounts only log on to privileged hosts.
Key takeaways
- DCSync needs only replication rights — not Domain Admin and not code on a DC — so an accidental ACL is enough to pull every hash.
- krbtgt exposure means domain-wide, long-lived forgery is possible: recovery requires a double krbtgt rotation.
- The fix is least-privilege ACLs on the domain object plus alerting on replication from non-DCs.