Mimikatz DCSync Usage, Exploitation, and Detection

Note: I presented on this AD persistence method at DerbyCon (2015).

A major feature added to Mimkatz in August 2015 is “DCSync” which effectively “impersonates” a Domain Controller and requests account password data from the targeted Domain Controller. DCSync was written by Benjamin Delpy and Vincent Le Toux.

The exploit method prior to DCSync was to run Mimikatz or Invoke-Mimikatz on a Domain Controller to get the KRBTGT password hash to create Golden Tickets. With Mimikatz’s DCSync and the appropriate rights, the attacker can pull the password hash, as well as previous password hashes, from a Domain Controller over the network without requiring interactive logon or copying off the Active Directory database file (ntds.dit).

Special rights are required to run DCSync. Any member of Administrators, Domain Admins, or Enterprise Admins as well as Domain Controller computer accounts are able to run DCSync to pull password data. Note that Read-Only Domain Controllers are not  allowed to pull password data for users by default.


The credentials section in the graphic above shows the current NTLM hashes as well as the password history. This information can be valuable to an attacker since it can provide password creation strategies for users (if cracked).

Will’s post has great information on Red Team usage of Mimikatz DCSync:
Mimikatz and DCSync and ExtraSids, Oh My


How DCSync works:

  1. Discovers Domain Controller in the specified domain name.
  2. Requests the Domain Controller replicate the user credentials via GetNCChanges (leveraging Directory Replication Service (DRS) Remote Protocol)

I have previously done some packet captures for Domain Controller replication and identified the intra-DC communication flow regarding how Domain Controllers replicate.

The Samba Wiki describes the DSGetNCChanges function:

“The client DC sends a DSGetNCChanges request to the server when the first one wants to get AD objects updates from the second one. The response contains a set of updates that the client has to apply to its NC replica.

It is possible that the set of updates is too large for only one response message. In those cases, multiple DSGetNCChanges requests and responses are done. This process is called replication cycle or simply cycle.”

“When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from.”

From MSDN:

The IDL_DRSGetNCChanges method replicates updates from an NC replica on the server.

   [in, ref] DRS_HANDLE hDrs,
   [in] DWORD dwInVersion,
   [in, ref, switch_is(dwInVersion)] 
   [out, ref] DWORD* pdwOutVersion,
   [out, ref, switch_is(*pdwOutVersion)] 

hDrs: The RPC context handle returned by the IDL_DRSBind method.

dwInVersion: Version of the request message.

pmsgIn: A pointer to the request message.

pdwOutVersion: A pointer to the version of the response message.

pmsgOut: A pointer to the response message.

Return Values: 0 if successful, otherwise a Windows error code.

Exceptions Thrown: This method might throw the following exceptions beyond those thrown by the underlying RPC protocol (as specified in [MS-RPCE]): ERROR_INVALID_HANDLE, ERROR_DS_DRS_EXTENSIONS_CHANGED, ERROR_DS_DIFFERENT_REPL_EPOCHS, and  ERROR_INVALID_PARAMETER.


Delegating Rights to Pull Account data:

It is possible to use a regular domain user account to run DCSync. The combination of the following three rights need to be delegated at the domain level in order for the user account to successfully retrieve the password data with DCSync:

  • Replicating Directory Changes (DS-Replication-Get-Changes)
    Extended right needed to replicate only those changes from a given NC that are also replicated to the Global Catalog (which excludes secret domain data). This constraint is only meaningful for Domain NCs.
  • Replicating Directory Changes All (DS-Replication-Get-Changes-All)
    Control access right that allows the replication of all data in a given replication NC, including secret domain data.
  • Replicating Directory Changes In Filtered Set (rare, only required in some environments)


Note that members of the Administrators and Domain Controller groups have these rights by default.


Pulling Password Data Using DCSync

Once the account is delegated the ability to replicate objects, the account can run Mimikatz DCSync:

mimikatz “lsadump::dcsync /domain:rd.adsecurity.org /user:krbtgt”


Targeting an admin account with DCSync can also provide the account’s password history (in hash format). Since there are LMHashes listed it may be possible to crack these and gain insight into the password strategy the admin uses. This may provide the attacker to guess the next password the admin uses if access is lost.

mimikatz “lsadump::dcsync /domain:rd.adsecurity.org /user:Administrator”



Detecting DCSync usage

While there may be event activity that could be used to identify DCSync usage, the best detection method is through network monitoring.

Step 1: Identify all Domain Controller IP addresses and add to “Replication Allow List”.

PowerShell Active Directory module cmdlet:

Get-ADDomainController -filter * | select IPv4Address


[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers | select IPAddress

Nslookup (if DC runs DNS):

Set type=all


Step 2: Configure IDS to trigger if DsGetNCChange request originates an IP not on the “Replication Allow List” (list of DC IPs).



There are other tools that perform this same process so it’s better to focus on detecting the method instead of specific artifacts.

Other tools that leverage GetNCChanges

Note that Full Control rights at the domain provides these rights as well, so limit who has domain-level admin rights.




(Visited 183,985 times, 18 visits today)