{ "id": "85631145-8666-4fd1-a8fa-902d664fd9ae", "created_at": "2026-04-06T01:32:29.561775Z", "updated_at": "2026-04-10T13:12:52.012965Z", "deleted_at": null, "sha1_hash": "ade3752e267882432a859102f4786fe478271c51", "title": "Mimikatz DCSync Usage, Exploitation, and Detection", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 708300, "plain_text": "Mimikatz DCSync Usage, Exploitation, and Detection\r\nBy Sean Metcalf\r\nPublished: 2015-09-25 · Archived: 2026-04-06 01:07:33 UTC\r\nNote: I presented on this AD persistence method at DerbyCon (2015).\r\nA major feature added to Mimkatz in August 2015 is “DCSync” which effectively “impersonates” a Domain\r\nController and requests account password data from the targeted Domain Controller. DCSync was written by\r\nBenjamin Delpy and Vincent Le Toux.\r\nThe exploit method prior to DCSync was to run Mimikatz or Invoke-Mimikatz on a Domain Controller to get the\r\nKRBTGT password hash to create Golden Tickets. With Mimikatz’s DCSync and the appropriate rights, the\r\nattacker can pull the password hash, as well as previous password hashes, from a Domain Controller over the\r\nnetwork without requiring interactive logon or copying off the Active Directory database file (ntds.dit).\r\nSpecial rights are required to run DCSync. Any member of Administrators, Domain Admins, or Enterprise Admins\r\nas 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.\r\nhttps://adsecurity.org/?p=1729\r\nPage 1 of 7\n\nThe credentials section in the graphic above shows the current NTLM hashes as well as the password history. This\r\ninformation can be valuable to an attacker since it can provide password creation strategies for users (if cracked).\r\nWill’s post has great information on Red Team usage of Mimikatz DCSync:\r\nMimikatz and DCSync and ExtraSids, Oh My\r\nHow DCSync works:\r\n1. Discovers Domain Controller in the specified domain name.\r\n2. Requests the Domain Controller replicate the user credentials via GetNCChanges (leveraging Directory\r\nReplication Service (DRS) Remote Protocol)\r\nI have previously done some packet captures for Domain Controller replication and identified the intra-DC\r\ncommunication flow regarding how Domain Controllers replicate.\r\nThe Samba Wiki describes the DSGetNCChanges function:\r\n“The client DC sends a DSGetNCChanges request to the server when the first one wants to get AD objects\r\nupdates from the second one. The response contains a set of updates that the client has to apply to its NC replica.\r\nIt is possible that the set of updates is too large for only one response message. In those cases, multiple\r\nDSGetNCChanges requests and responses are done. This process is called replication cycle or simply cycle.”\r\n“When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom\r\ndata structure) it performs a replication cycle where it behaves like a client and makes DSGetNCChanges requests\r\nto that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from.”\r\nFrom MSDN:\r\nThe IDL_DRSGetNCChanges method replicates updates from an NC replica on the server.\r\nULONG IDL_DRSGetNCChanges(\r\n [in, ref] DRS_HANDLE hDrs,\r\n [in] DWORD dwInVersion,\r\n [in, ref, switch_is(dwInVersion)]\r\n DRS_MSG_GETCHGREQ* pmsgIn,\r\n [out, ref] DWORD* pdwOutVersion,\r\n [out, ref, switch_is(*pdwOutVersion)]\r\n DRS_MSG_GETCHGREPLY* pmsgOut\r\n);\r\nhDrs: The RPC context handle returned by the IDL_DRSBind method.\r\ndwInVersion: Version of the request message.\r\npmsgIn: A pointer to the request message.\r\nhttps://adsecurity.org/?p=1729\r\nPage 2 of 7\n\npdwOutVersion: A pointer to the version of the response message.\r\npmsgOut: A pointer to the response message.\r\nReturn Values: 0 if successful, otherwise a Windows error code.\r\nExceptions Thrown: This method might throw the following exceptions beyond those thrown by the\r\nunderlying RPC protocol (as specified in [MS-RPCE]): ERROR_INVALID_HANDLE,\r\nERROR_DS_DRS_EXTENSIONS_CHANGED, ERROR_DS_DIFFERENT_REPL_EPOCHS, and \r\nERROR_INVALID_PARAMETER.\r\nDelegating Rights to Pull Account data:\r\nIt is possible to use a regular domain user account to run DCSync. The combination of the following three rights\r\nneed to be delegated at the domain level in order for the user account to successfully retrieve the password data\r\nwith DCSync:\r\nReplicating Directory Changes (DS-Replication-Get-Changes)\r\nExtended right needed to replicate only those changes from a given NC that are also replicated to the\r\nGlobal Catalog (which excludes secret domain data). This constraint is only meaningful for Domain NCs.\r\nReplicating Directory Changes All (DS-Replication-Get-Changes-All)\r\nControl access right that allows the replication of all data in a given replication NC, including secret\r\ndomain data.\r\nReplicating Directory Changes In Filtered Set (rare, only required in some environments)\r\nNote that members of the Administrators and Domain Controller groups have these rights by default.\r\nhttps://adsecurity.org/?p=1729\r\nPage 3 of 7\n\nPulling Password Data Using DCSync\r\nOnce the account is delegated the ability to replicate objects, the account can run Mimikatz DCSync:\r\nmimikatz “lsadump::dcsync /domain:rd.adsecurity.org /user:krbtgt”\r\nTargeting an admin account with DCSync can also provide the account’s password history (in hash format). Since\r\nhttps://adsecurity.org/?p=1729\r\nPage 4 of 7\n\nthere are LMHashes listed it may be possible to crack these and gain insight into the password strategy the admin\r\nuses. This may provide the attacker to guess the next password the admin uses if access is lost.\r\nmimikatz “lsadump::dcsync /domain:rd.adsecurity.org /user:Administrator”\r\nDetecting DCSync usage\r\nWhile there may be event activity that could be used to identify DCSync usage, the best detection method is\r\nthrough network monitoring.\r\nStep 1: Identify all Domain Controller IP addresses and add to “Replication Allow List”.\r\nPowerShell Active Directory module cmdlet:\r\nGet-ADDomainController -filter * | select IPv4Address\r\nPowerShell:\r\n[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers | select\r\nIPAddress\r\nNslookup (if DC runs DNS):\r\nhttps://adsecurity.org/?p=1729\r\nPage 5 of 7\n\nnslookup\r\nSet type=all\r\n_ldap._tcp.dc._msdcs.DOMAIN.COM\r\nStep 2: Configure IDS to trigger if DsGetNCChange request originates an IP not on the “Replication Allow\r\nList” (list of DC IPs).\r\nThere are other tools that perform this same process so it’s better to focus on detecting the method instead of\r\nspecific artifacts.\r\nOther tools that leverage GetNCChanges\r\nImpacket: https://github.com/CoreSecurity/impacket\r\nDSInternals: https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/\r\nNote that Full Control rights at the domain provides these rights as well, so limit who has domain-level admin\r\nrights.\r\nhttps://adsecurity.org/?p=1729\r\nPage 6 of 7\n\nReferences:\r\nMSDN GetNCChanges\r\nHow to grant the “Replicating Directory Changes” permission for the Microsoft Metadirectory Services\r\nADMA service account\r\nGrant Active Directory Domain Services permissions for profile synchronization in SharePoint Server\r\n2013\r\nHow to poll for object attribute changes in Active Directory on Windows 2000 and Windows Server 2003 \r\nPolling for Changes Using the DirSync Control\r\nMimikatz and DCSync and ExtraSids, Oh My\r\n(Visited 208,184 times, 12 visits today)\r\nSource: https://adsecurity.org/?p=1729\r\nhttps://adsecurity.org/?p=1729\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://adsecurity.org/?p=1729" ], "report_names": [ "?p=1729" ], "threat_actors": [], "ts_created_at": 1775439149, "ts_updated_at": 1775826772, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ade3752e267882432a859102f4786fe478271c51.pdf", "text": "https://archive.orkl.eu/ade3752e267882432a859102f4786fe478271c51.txt", "img": "https://archive.orkl.eu/ade3752e267882432a859102f4786fe478271c51.jpg" } }