Ariovis

Active Directory attack path · MITRE ATT&CK T1003.006

DCSync: When an Account Can Ask Active Directory for Its Secrets

DCSync is not about stealing the NTDS.dit file or opening an interactive session on a Domain Controller. The attack abuses a perfectly legitimate Active Directory function: replication.

When an account holds the required rights, it can ask a Domain Controller to hand over data normally intended for another Domain Controller. The problem is therefore not only "who is an administrator?".

The real question

Who holds, directly or indirectly, the right to replicate the domain's secrets?

Understand your Active Directory attack paths
MITRE ATT&CK
T1003.006 — OS Credential Dumping: DCSync
Tactic
Credential Access
Protocol abused
MS-DRSR / DRSUAPI (RPC)
Key rights
Replicating Directory Changes + Replicating Directory Changes All
Possible targets
Domain accounts, privileged accounts, krbtgt
Level
Tier 0 / critical
Windows signal
Event ID 4662 — only if auditing is configured
Position in the path
Post-compromise, after powerful rights are obtained

The attack path, step by step

DCSync comes late in an attack path. It assumes an identity has already obtained, or inherited, replication rights over the domain. Nothing in this sequence is automatic: each arrow depends on what the environment actually allows.

  1. 01

    Compromised identity

  2. 02

    Replication rights obtained

    • Replicating Directory Changes
    • + Replicating Directory Changes All
  3. 03

    Replication request sent to a Domain Controller

    • MS-DRSR / DRSUAPI / RPC
  4. 04

    Active Directory returns the data it is allowed to replicate

  5. 05

    Authentication material extracted

    • Domain account hashes
    • Privileged accounts
    • Potentially krbtgt
  6. 06

    Impact

    • Account impersonation
    • Movement towards Tier 0
    • Persistence

If the krbtgt secret is recovered

Golden Ticket becomes possible: forging valid Kerberos TGTs for the domain

The DCSync problem is not that an offensive tool can talk to the Domain Controller. The problem is that an identity holds the right to ask it for its secrets.

No need to "hack" the Domain Controller

This is what makes DCSync particularly worth understanding.

Replication is essential to the normal operation of Active Directory. Domain Controllers use the Directory Replication Service Remote Protocol, MS-DRSR, to keep domain data consistent.

DCSync hijacks that logic. The attacker does not ask the Domain Controller to run malware. They present themselves as a principal holding a replication right and request data through the protocol designed for exactly that.

A security control focused solely on processes running on DCs is therefore likely to miss part of the problem.

Key takeaway

DCSync is first an authorization problem inside Active Directory, before it is an offensive-tooling problem.

The real critical asset: replication rights

Two extended rights, set on the domain head, determine who can ask a Domain Controller for what.

RightRoleWhy it is sensitive
DS-Replication-Get-ChangesReplicating Directory Changes1131f6aa-9c07-11d1-f79f-00c04fc2dcd2Allows requesting changes from an Active Directory Naming Context.On its own, it does not hand over secrets. It is the first half of the path.
DS-Replication-Get-Changes-AllReplicating Directory Changes All1131f6ad-9c07-11d1-f79f-00c04fc2dcd2Extends replication to the domain's secret data.This is the right that authorises transmission of authentication material.

To describe the classic DCSync path, it is not enough to say that a single "Replicating Directory Changes" right is sufficient. The GetChanges + GetChangesAll combination is the essential case to monitor.

Active Directory also defines the DS-Replication-Get-Changes-In-Filtered-Set right. It exists for certain attributes belonging to the filtered attribute set. It should not be presented as a third permission systematically required for every DCSync.

You can hold the power without wearing the "Domain Admin" label

Highly privileged administrative groups naturally have the capabilities needed to perform replication operations. But Active Directory also allows these rights to be delegated.

That is precisely where governance becomes difficult. A service account, a legacy group, an old delegation or a chain of memberships can end up producing a principal able to request domain secrets without immediately appearing as a "domain administrator".

This is why reviewing only the Domain Admins or Enterprise Admins groups is not enough. Domain ACLs, and the paths that lead to these permissions, must be analysed.

Not every holder of replication rights is an attacker

Do not treat every non-DC account holding these rights as malicious. Some legitimate identity synchronisation services may hold replication rights.

Example: Microsoft Entra Connect may require Replicating Directory Changes and Replicating Directory Changes All for Password Hash Synchronization.

The right approach is therefore to identify, document and reduce legitimate exceptions, not to blindly remove every right.

Mimikatz, Impacket: they do not invent the flaw

Offensive tools make DCSync accessible. They do not create its precondition. No execution procedure is described here: only understanding what they exploit matters for defence.

Mimikatz

  • can use the DCSync mechanisms to request an account's data;
  • relies on rights already held by the context in use;
  • does not magically create replication rights.

Impacket

  • also offers capabilities to interact remotely with Active Directory replication mechanisms;
  • illustrates that no interactive session on the Domain Controller is required.

BloodHound

  • can represent the DCSync path when a principal holds the required permissions;
  • above all, shows how an initially less privileged identity ends up reaching that capability.
The risk is not Mimikatz. The risk is that an identity can legitimately ask for something it should no longer be able to ask for.

DCSync against krbtgt: the scenario that tips the whole domain

DCSync can target different accounts. When the recovered secret belongs to a user or administrator account, it may allow that account to be impersonated through the mechanisms available.

The krbtgt case is different. The krbtgt account carries the keys Kerberos uses to protect the domain's Ticket Granting Tickets. Recovering its secret can allow an attacker to forge Kerberos tickets — the principle behind the Golden Ticket.

So it is not DCSync alone that creates the Golden Ticket. The exact chain is:

  1. 01Replication rights
  2. 02DCSync
  3. 03krbtgt secret recovered
  4. 04Ability to forge TGTs
  5. 05Golden Ticket
DCSync against an ordinary account is serious. DCSync against krbtgt changes the scale: it compromises Kerberos trust for the entire domain.

Detecting legitimate replication used in an illegitimate context

The DCSync challenge is the same as for many identity-based attacks: the protocol in use is legitimate. Detection must therefore correlate the identity, the source machine and the observed behaviour.

01

Event ID 4662

An operation was performed on an Active Directory object

Event ID 4662 is not a magic DCSync alert. Its availability depends in particular on the Directory Service Access audit configuration and the corresponding SACLs. You then need to look for operations related to replication rights and put them in context.

02

Replication source

Replication originating from a known Domain Controller is normal. A DRSUAPI request coming from a user workstation, an unexpected administration server or a non-DC endpoint deserves immediate qualification.

03

Identity used

Compare the principal against the accounts authorised to perform replication. Look in particular for:

  • an unexpected user account;
  • an unusual service account;
  • new usage of an account that is usually legitimate;
  • a recent change of delegation.
04

SIEM correlation

Correlate identity + source IP / hostname + DRSUAPI + replication rights + time context.

  • Avoid naive rules that treat every replication as an attack.
Detecting DCSync means recognising a normal operation performed by the wrong identity, from the wrong machine, at the wrong time.

Remove the path rather than block the tool

Blocking a tool signature does not remove the right that makes DCSync possible. Remediation targets the permissions and the paths that lead to them.

  1. 01

    Inventory

    Identify every user, group, technical account and service holding replication rights over the domain, directly or indirectly.

  2. 02

    Justify

    For each principal:

    • why does it hold this right?
    • which service uses it?
    • is it still necessary?
    • who owns it?
  3. 03

    Reduce

    Remove obsolete delegations. Reduce intermediate groups. Isolate and govern legitimate synchronisation accounts. Avoid granting these rights to human identities when they are not needed.

  4. 04

    Monitor

    Put under watch:

    • use of replication rights;
    • changes to the associated ACLs;
    • new delegations;
    • requests from unusual sources.
  5. 05

    Revalidate

    After remediation, recompute the attack paths. A fix is genuinely useful when it removes the path that led to the DCSync capability.

This approach belongs to a broader effort to bring Tier 0 under control. For a sequenced trajectory from findings to first remediations: NIS2: securing your Active Directory in 90 days

An ACL fix is no longer enough after compromise

If a DCSync attack is confirmed, the recovered secrets must be considered potentially compromised. The response therefore depends on the accounts involved.

Revoking only the replication right closes the future path, but does not invalidate secrets already recovered.

  • analyse the scope that was actually requested;
  • reset or renew the exposed secrets;
  • look for subsequent use of those credentials;
  • check for persistence mechanisms.

If the krbtgt secret may have been compromised

Rotating the krbtgt account must follow Microsoft's official procedure. Microsoft documents a two-step reset, with a delay aligned with the Kerberos ticket lifetime. This is not a routine operation to launch immediately without preparation: it is planned, sequenced and verified.

Our conviction: a replication right is a Tier 0 asset

DCSync shows perfectly why an Active Directory analysis cannot stop at technical vulnerabilities or at the members of the Domain Admins group. Relationships are what matter.

  • A delegation.
  • A nested group.
  • A synchronisation account.
  • A legacy ACL.

Taken in isolation, each of these may look acceptable. Chained together, they can give an identity the ability to extract the domain's secrets.

Ariovis therefore analyses

  • sensitive accounts;
  • groups;
  • delegations;
  • ACLs;
  • replication rights;
  • the paths that lead to them;
  • the remediations that genuinely remove those paths.
Assess my Active Directory securityDiscover the Identity and Active Directory security offer

An audit reconstructs the paths. A controlled penetration test can verify which ones are actually exploitable. Identity and access penetration testing

Related techniques

Three techniques from the same collection. They are not necessarily three successive steps: each fits into an attack path depending on what the environment allows.

Technical sources

First-rank references used to support this page.

Go further

Ariovis content that directly extends this topic.