{"id":1729,"date":"2015-09-25T16:00:48","date_gmt":"2015-09-25T20:00:48","guid":{"rendered":"https:\/\/adsecurity.org\/?p=1729"},"modified":"2018-05-18T00:43:12","modified_gmt":"2018-05-18T04:43:12","slug":"mimikatz-dcsync-usage-exploitation-and-detection","status":"publish","type":"post","link":"https:\/\/adsecurity.org\/?p=1729","title":{"rendered":"Mimikatz DCSync Usage, Exploitation, and Detection"},"content":{"rendered":"

Note: I presented on this AD persistence method at DerbyCon (2015).<\/a><\/p>\n

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.<\/p>\n

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).<\/p>\n

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\u00a0 allowed to pull password data for users by default.<\/p>\n

\"Mimikatz-DCSync-UserRights-DCR-Administrator-500-Dump2\"<\/a><\/p>\n

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).<\/p>\n

<\/p>\n

Will’s post has great information on Red Team usage of Mimikatz DCSync:<\/strong>
\nMimikatz and DCSync and ExtraSids, Oh My<\/a><\/p>\n

 <\/p>\n

How DCSync works:<\/b><\/h4>\n
    \n
  1. Discovers Domain Controller in the specified domain name.<\/li>\n
  2. Requests the Domain Controller replicate the user credentials via GetNCChanges <\/a>(leveraging Directory Replication Service (DRS) Remote Protocol<\/a>)<\/li>\n<\/ol>\n

    I have previously done some packet captures for Domain Controller replication<\/a> and identified the intra-DC communication flow regarding how Domain Controllers replicate.<\/p>\n

    The Samba Wiki describes the DSGetNCChanges function<\/a>:<\/p>\n

    “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. <\/i><\/p>\n

    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.”<\/i><\/p>\n

    “When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication\u00a0cycle 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.”<\/i><\/p>\n

    From MSDN:<\/p>\n

    \n
    \n
    \n
    \n

    The IDL_DRSGetNCChanges method replicates updates<\/a> from an NC replica<\/a> on the server.<\/p>\n

    \n
    \u00a0ULONG IDL_DRSGetNCChanges(\r\n\u00a0  [in, ref] DRS_HANDLE hDrs,\r\n\u00a0  [in] DWORD dwInVersion,\r\n\u00a0  [in, ref, switch_is(dwInVersion)] \r\n\u00a0    DRS_MSG_GETCHGREQ* pmsgIn,\r\n\u00a0  [out, ref] DWORD* pdwOutVersion,\r\n\u00a0  [out, ref, switch_is(*pdwOutVersion)] \r\n\u00a0    DRS_MSG_GETCHGREPLY* pmsgOut\r\n\u00a0);\r\n<\/pre>\n<\/div>\n
    hDrs: <\/strong>The RPC<\/a> context handle returned by the IDL_DRSBind<\/a> method.<\/p>\n
    dwInVersion: <\/strong>Version of the request message.<\/p>\n
    pmsgIn: <\/strong>A pointer to the request message.<\/p>\n
    pdwOutVersion: <\/strong>A pointer to the version of the response message.<\/p>\n
    pmsgOut: <\/strong>A pointer to the response message.<\/p>\n
    Return Values: <\/strong>0 if successful, otherwise a Windows error code<\/a>.<\/p>\n
    Exceptions Thrown<\/strong>: This method might throw the following exceptions beyond those thrown by the underlying RPC protocol (as specified in [MS-RPCE]<\/a>): ERROR_INVALID_HANDLE, ERROR_DS_DRS_EXTENSIONS_CHANGED, ERROR_DS_DIFFERENT_REPL_EPOCHS, and\u00a0 ERROR_INVALID_PARAMETER.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/blockquote>\n
     <\/p>\n
    Delegating Rights to Pull Account data:<\/span><\/b><\/h4>\n
    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:<\/p>\n