← All walkthroughs

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.

On-prem Windows / Active Directory Advanced Active DirectoryCredential AccessPersistence
Authorized testing only. This is a conceptual, defensive-aware walkthrough that maps an attack path to MITRE ATT&CK, detection and mitigation, and links to references for the detail. It is not a copy-paste playbook. Use it only against systems you own or are explicitly permitted to test.

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. 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.

    Detection

    Reads of the domain object's ACL and replication-rights enumeration (often via BloodHound-style collection) are catchable with directory auditing.

    Mitigation

    Audit and remove unnecessary DS-Replication rights, and alert on changes to the domain object's DACL.

  2. 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.

    Detection

    Replication (DsGetNCChanges) requests from a host that is not a domain controller are a high-fidelity DCSync signal in directory-service logs.

    Mitigation

    Restrict replication rights to domain controllers, monitor for non-DC replication, and tier administration so no workstation account can replicate.

    References mimikatz · impacket
  3. 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.

    Detection

    Tickets with anomalous lifetimes or mismatched account/RID data, and TGS use without a preceding AS exchange, are detectable with Kerberos auditing.

    Mitigation

    Rotate the krbtgt password twice (the only real recovery after exposure), and monitor for ticket anomalies.

  4. 4

    Lateral Movement

    Demonstrate reach

    Show 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.

    Detection

    Hash-based authentication (no interactive logon), and privileged logons from unusual hosts, are strong signals with logon auditing and Credential Guard telemetry.

    Mitigation

    Credential Guard, tiered administration, unique local-admin passwords (LAPS), and enforcing that privileged accounts only log on to privileged hosts.

    References crackmapexec · impacket

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.