DCSync

Using directory replication to steal secrets

Introduction

DCSync is an Active Directory attack technique that abuses the directory replication process used by Domain Controllers to obtain sensitive credential information.

Microsoft’s Active Directory stores its main database information in a file called NTDS.dit. The file is normally stored on the server at C:\Windows\NTDS\NTDS.dit

It contains the domain’s directory information, including:

  • User and computer accounts
  • Groups and group memberships
  • Security identifiers (SIDs)
  • Password hashes and other credential-related data
  • Active Directory configuration information

Because it contains highly sensitive authentication information, direct access to NTDS.dit is heavily protected. Attackers who obtain a copy can potentially extract password hashes and other secrets.

This is why DCSync is significant – An attacker can abuse Active Directory replication to request credential information from a Domain Controller.

Rather than stealing the NTDS.dit database directly, an attacker with the appropriate replication privileges can request credential data from a Domain Controller as though they were another Domain Controller.

This makes DCSync particularly dangerous because it can be performed remotely and uses legitimate Active Directory functionality.

What is DCSync?

Many organisations operate multiple Active Directory servers for various reasons:

  • Redundancy / high availability – If one Domain Controller fails, another can continue providing authentication and directory services.
  • Disaster recovery – Having multiple Domain Controllers protects against hardware failure, corruption or other incidents affecting a single server.
  • Load balancing – Authentication requests, LDAP queries and other directory operations can be distributed across multiple Domain Controllers.
  • Geographical locations – Large organisations may have Domain Controllers in different offices, cities or countries to provide local authentication services.
  • Faster authentication – A workstation can authenticate against a nearby Domain Controller rather than communicating across a slow WAN connection.
  • WAN resilience – If a branch office loses its connection to headquarters, a local Domain Controller can continue authenticating users and computers.
  • Maintenance without downtime – One Domain Controller can be taken offline for patching or maintenance while another continues providing authentication.
  • Different Active Directory sites – Organisations can use AD Sites and Services to associate Domain Controllers with particular physical networks and control how replication occurs.
  • Large environments – A large organisation may simply have too many users and computers for a single Domain Controller to efficiently handle all directory and authentication requests.

Active Directory relies on replication to keep these Domain Controllers synchronised. When a change is made to an account, group or other directory object, Domain Controllers replicate that information between one another.

DCSync abuses this functionality.

If an attacker compromises an account that has sufficient Directory Replication permissions, they can request sensitive information from another Domain Controller.

This can include:

  • NTLM password hashes
  • Kerberos keys
  • Password-related secrets
  • Privileged account credentials
  • The KRBTGT account’s secrets

The attacker therefore does not necessarily need direct access to the Domain Controller itself.

How does DCSync work?

A typical DCSync attack follows a relatively simple process:

  1. Compromise an account – The attacker first gains access to an account within the Active Directory environment.
  2. Obtain replication privileges – The attacker identifies an account with permissions such as
    DS-Replication-Get-Changes
    DS-Replication-Get-Changes-All
    DS-Replication-Get-Changes-In-Filtered-Set

    These permissions allow directory replication operations.
  3. Request replication data – The attacker sends a replication request to a Domain Controller.
  4. Domain Controller responds – The Domain Controller treats the request as legitimate because the requesting account has the required replication permissions.
  5. Credential material is returned – The attacker receives sensitive authentication information associated with the requested account.
  6. Credentials are abused – The recovered credential material can then be used for authentication, lateral movement or further privilege escalation.

What can an attacker achieve?

A successful DCSync attack can provide an attacker with credential material that may enable:

  • Credential theft
  • Account takeover
  • Privilege escalation
  • Lateral movement
  • Pass-the-Hash attacks
  • Kerberos abuse
  • Persistence
  • Domain-wide compromise

If the attacker obtains the secrets associated with the KRBTGT account, the consequences can be particularly severe.

The KRBTGT account is fundamental to Kerberos authentication within the domain, and compromise of its keys can enable further attacks against the Kerberos infrastructure.

DCSync vs NTDS.dit

DCSync is often confused with traditional NTDS.dit extraction, but the techniques are different. NTDS.dit extraction involves obtaining the Active Directory database and extracting credential information from it.

DCSync instead abuses the normal Active Directory replication mechanism to request credential information from a Domain Controller.

This means an attacker can potentially perform DCSync without directly accessing the Domain Controller’s filesystem.

Detecting DCSync

DCSync can be challenging to detect because it uses legitimate Active Directory replication functionality.

One of the most important Windows security events to monitor is Event ID 4662 — An operation was performed on an object

Security teams should look for replication-related activity involving:

  • DS-Replication-Get-Changes
  • DS-Replication-Get-Changes-All
  • DS-Replication-Get-Changes-In-Filtered-Set

Particular attention should be given to replication requests originating from systems that are not Domain Controllers.

Other warning signs include:

  • Unexpected accounts possessing replication privileges
  • Changes to Active Directory delegation
  • Replication activity from unusual hosts
  • Replication requests targeting privileged accounts
  • Suspicious authentication activity following replication events

How can DCSync be prevented?

The most important defence is to carefully control who has directory replication permissions.

Organisations should:

  • Apply the principle of least privilege
  • Restrict replication permissions to authorised accounts
  • Regularly audit Active Directory permissions
  • Remove unnecessary delegation
  • Monitor changes to privileged groups
  • Protect Domain Administrator accounts
  • Monitor Event ID 4662
  • Monitor unusual Domain Controller activity
  • Use strong authentication for privileged accounts
  • Regularly review nested group memberships
  • Segment administrative systems from normal user networks

Replication permissions should be treated as highly privileged access.

Conclusion

DCSync abuses Active Directory’s legitimate replication mechanism to extract sensitive credential information.

It does not require an attacker to directly steal the NTDS.dit database – Instead, the attacker abuses replication privileges to make a Domain Controller provide credential material.

A compromised account with replication privileges can potentially turn a single foothold into full Active Directory domain compromise.