A major feature added to Mimkatz this summer 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 only 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:
- Discovers Domain Controller in the specified domain name.
- 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.”
ULONG IDL_DRSGetNCChanges( [in, ref] DRS_HANDLE hDrs, [in] DWORD dwInVersion, [in, ref, switch_is(dwInVersion)] DRS_MSG_GETCHGREQ* pmsgIn, [out, ref] DWORD* pdwOutVersion, [out, ref, switch_is(*pdwOutVersion)] DRS_MSG_GETCHGREPLY* pmsgOut );
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
- Replicating Directory Changes All
- 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):
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
- Impacket: https://github.com/CoreSecurity/impacket
- DSInternals: https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/
Note that Full Control rights at the domain provides these rights as well, so limit who has domain-level admin rights.
- MSDN GetNCChanges
- How to grant the “Replicating Directory Changes” permission for the Microsoft Metadirectory Services ADMA service account
- Grant Active Directory Domain Services permissions for profile synchronization in SharePoint Server 2013
- How to poll for object attribute changes in Active Directory on Windows 2000 and Windows Server 2003
- Polling for Changes Using the DirSync Control
- Mimikatz and DCSync and ExtraSids, Oh My