DCSync

Also calledDRSUAPI, GetNCChanges, Replication abuse, krbtgt

Asks a domain controller to replicate account secrets, as another DC would.

Needs
Replication
Gives
krbtgt KeyandNT HashandAES KeyandService Key

How the Attack Works

Domain controllers copy changes between themselves with the directory replication service, and a DC answers a GetNCChanges request with account secrets for any caller holding the replication rights on the domain. It checks those rights, not whether the caller is a domain controller, so the request can come from any machine. Domain Admins, Enterprise Admins, the built-in Administrators and the DCs hold the rights by default, and the Entra Connect sync account holds them by design.

Read first Password Hashes and Kerberos Keys

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

An account holding the replication rights asks dc-01, from the foothold, for account secrets as a DC would.Step through it

ws-042 Foothold

dc-01 Domain controller

  • krbtgt key
  • dana's key
  • srv-fin-01 key
  1. Step 1 of 3, Replication Request, ws-042 to dc-01
  2. Step 2 of 3, Secrets Replicated, dc-01 to ws-042
  3. Step 3 of 3, Keys Put to Use, on ws-042

  1. Step 1 of 3: Replication Request

    ws-042 Foothold to dc-01 Domain controller

    Request to replicate account secrets IDL_DRSGetNCChanges DRSUAPI over RPC

    ws-042, which is not a DC, asks dc-01 to replicate named accounts' secrets, krbtgt's among them.

    Logged

    • 4662 An operation was performed on an object

      On dc-01, in the Security log When enabled

      Control Access on the domain object with DS-Replication-Get-Changes-All, by the caller

    What Defenders See

    The Security log on dc-01 shows event 4662 naming the replication rights, for an account that is not a DC. Replication from ws-042, an address that is not a DC's, shows too, and so does Defender for Identity's DCSync alert.

  2. Step 2 of 3: Secrets Replicated

    dc-01 Domain controller to ws-042 Foothold

    dc-01 checks only that the caller holds the replication rights, then returns the accounts' keys.

    Keys

    • ws-042 now holds krbtgt key (new at this step) dana's key (new at this step) srv-fin-01 key (new at this step)

    What Defenders See

    The Security log on dc-01 records nothing more. Defender for Identity alerts on the request from ws-042, a computer that is not a DC.

  3. Step 3 of 3: Keys Put to Use

    On ws-042 Foothold

    The krbtgt key forges TGTs. The other keys serve pass-the-hash, overpass-the-hash and silver tickets.

    What Defenders See

    No log on ws-042 or any DC shows anything until the keys are used. From then on, the golden ticket and pass-the-hash pages take over.

Needs First

What the attacker must already hold for this attack to be possible.

  • Replication RightsAn account holding the replication rights, such as Domain Admins, a DC account, or one granted them.

Comes From

Gives the Attacker

What running it hands the attacker to use next.

  • The krbtgt KeyThe krbtgt key, for golden and diamond tickets, without touching any DC disk.
  • An NT HashAny account's NT hash, and its password history, on request.
  • An AES KeyAny account's Kerberos AES keys, where it has them.
  • A Service's KeyAny service or computer account's key, for silver tickets.

Leads To

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and LogWritten OnLook ForSwitch It On
4662 An operation was performed on an object (opens in a new tab) Security logDomain controllers, for objects with a matching audit entryProperties naming 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes-All) for an account that is not a DC or the sync account.Audit Directory Service Access, and an audit entry (SACL) on the object

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

  • Without Directory Service Access auditing and an audit entry on the domain object, a DC writes no 4662 for DCSync at all.
  • 4662 names the account, not the machine. A DC's own account used from elsewhere looks like normal replication until its Logon ID is matched to the DC's 4624, which holds the source address.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyIdentityDirectoryEvents (documentation, opens in a new tab)

Needs Defender for Identity sensors on every DC, and replace the dc- prefix with your DCs' names. The Entra Connect server replicates by design.

KQLDefender XDR, Advanced hunting
// Directory replication asked for by a computer that is not a domain controllerIdentityDirectoryEvents| where Timestamp > ago(30d)| where ActionType has "replication"| where not(DeviceName startswith "dc-")| project Timestamp, ActionType, AccountName, AccountDomain, DeviceName, IPAddress, DestinationDeviceName, AdditionalFields| order by Timestamp desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Attacks tied to this one that its needs and gives do not already name, such as another form of it or its reverse, each with how the two connect.

  • NTDS.dit Theft

    The same keys, copied from a DC's disk rather than asked for over the network.

  • DCShadow

    The reverse, a rogue DC pushing changes in through the same replication.

  • Zerologon

    One way to the rights this needs, a domain controller's own account reset through Netlogon.

Sources