Introducing StealthAUDIT 11.5! Complete your cloud security puzzle. LEARN MORE

Extracting User Password Data with Mimikatz DCSync

Blog >Extracting User Password Data with Mimikatz DCSync
DCSync with rights to replicating directory changes for replicating directory changes all

Introduction: Extracting User Password Data with Mimikatz DCSync

Mimikatz provides a variety of ways to extract and manipulate credentials, but probably one of the most useful and scary ways is using the DCSync command. This attack simulates the behavior of a domain controller and asks other domain controllers to replicate information using the Directory Replication Service Remote Protocol (MS-DRSR). Basically, it lets you pretend to be a domain controller and ask for user password data. Most importantly, this can be done without running any code on a domain controller as opposed to the other ways Mimikatz will extract password data. This can be used by attackers to get any account’s NTLM hash including the KRBTGT account, which enables attackers to create Golden Tickets.  The trickiest part of this attack is that it takes advantage of a valid and necessary function of Active Directory, so it cannot be turned off or disabled.

Who Can Perform a DCSync Attack?

DCSync with rights to replicating directory changes for replicating directory changes all

Performing a DCSync is quite simple. The only pre-requisite to worry about is that you have an account with rights to perform domain replication. This is controlled by the Replicating Changes permissions set on the domain. Having the Replicating Changes All and Replicating Directory Changes permission will allow you to perform this attack. 

By default, this is limited to the Domain Admins, Enterprise Admins, Administrators, and Domain Controllers groups. If you would like to quickly find any users who can perform the DCSync attack outside of these default permissions the following PowerShell script will help. This will enumerate all of the domain-level permissions for any domain and find all permissions granted these rights with a RID above 1000, which will exclude all default permissions.

#Get all permissions in the domain, filtered to the two critical replication permissions represented by their GUIDs

Import-Module ActiveDirectory

cd 'AD:DC=JEFFLAB,DC=local'

$AllReplACLs = (Get-AcL).Access | Where-Object {$_.ObjectType -eq '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' -or $_.ObjectType -eq '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'}

#Filter this list to RIDs above 1000 which will exclude well-known Administrator groups

foreach ($ACL in $AllReplACLs)


    $user = New-Object System.Security.Principal.NTAccount($ACL.IdentityReference)

    $SID = $user.Translate([System.Security.Principal.SecurityIdentifier])

    $RID = $SID.ToString().Split("-")[7]

    if([int]$RID -gt 1000)


        Write-Host "Permission to Sync AD granted to:" $ACL.IdentityReference


Output of PowerShell script showing which users have rights to perform DCSync attack against domain

Running this will output an entry for each permission given to a user or group who probably shouldn’t be there: 

Performing DCSync

If you do have the necessary rights, the rest is quite simple. Simply execute the following command:


Using Mimikatz command lsadump::dcsync, krbtgt to perform DCSync attack KRBTGT account

Here is that command to retrieve the KRBTGT hash. 

Using DCSync to return clear text password for an account with reversible password encryption

Another cool feature is that if the password is stored with reversible encryption, you can get a clear text password returned: 

Protections from DCSync

The best protection is controlling the domain permissions outlined earlier and making only the necessary accounts have the ability to replicate information from your domain. Inevitably, some users will have this right, and they should be protected to avoid their password details being stored where attackers may compromise them. Start by running the script provided above against all domains to be sure you don’t have any improper users with rights to perform this attack.

How Attackers Are Stealing Your Credentials with Mimikatz:

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:


Featured Asset

Comments (12)

  • Good evening sir,
    I thank you so much for this article. I just have a small question. I couldn’t find the window allowing me to activate “Replicating Changes All” and “Replicating Directory Changes”. Could you please tell me how to do it?
    Best regards.

    • Those are special permissions that can be applied at the domain level. To see them, open up Active Directory Users & Computers and go the properties of one of your top level domains, from there go to the security tab and you should be able to see those options in the list of permissions. This will not appear on OUs or other objects, so be sure to look at the domain level (jefflab.local in my case).

    • The special permissions I was referring to are the ‘Replicating Directory Changes’ and ‘Replicating Directory Changes All’. These are ‘special’ in that they cannot be applied on any object and just at the domain level, and are required for DCSync to work. That makes this particular attack interesting because a user could be granted these permissions separate from any membership in privileged groups and still be able to perform the DCSync attack.

      • Hi Jeff,
        Nice article, after reading I ma having following queries,
        1. Does an account require both Replicating Directory Changes and Replicating Directory Changes All permission to perform a DCSync attack?
        2. In ‘Replicating Directory Changes All’ permission only accounts password hash sync will happen right, in this case does an account can perform DCSync with Replication Directory Changes All permission alone?
        3. In SharePoint case, the SharePoint service account will have replication directory changes permission alone. Since both changes and changes all using same MS DRSR protocol, So SharePoint account also will consider as perpetrator account?
        4. Is there a way to differentiate accounts that performing Replicating Directory Changes, Replicating Directory Changes All and Replication Directly changes filtered set?

        Eagerly awaiting for your response.


        • Hi Somu,
          The response to your questions are as follows:
          1. Yes an account does require both the Replicating Directory Changes and the Replicating Directory Changes all to perform the DCsync attack.
          2. Only having the “replicate directory changes all” will not allow an account to perform the DCSync attack on its own because it specifically only controls access to the secret data inside active directory for replication where as the replicating directory changes permission allows the account to trigger the replication with a given NC.
          3. With sharepoint, I believe as you have stated that it only has the Replicating Directory Changes permission so whilst it can perform replication of account data it does not have access to the actual secrets (password hashes etc) of the accounts. This should be somewhat safe to exclude from threat detection tooling but I would only do so if you are also strictly monitoring for ACL changes on the domain to make sure it doesn’t get granted the replicating directory changes all permission as well.
          4. It is possible to differentiate between the different permissions used by enabling the Directory Service Access auditing and then looking for Event ID 4662 to the monitor for properties which contain the following GUIDs:

          DS-Replication-Get-Changes -> 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
          DS-Replication-Get-Changes-All -> 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
          DS-Replication-Get-Changes-In-Filtered-Set -> 89e95b76-444d-4c62-991a-0facbeda640c

          Other Control Access Rights can be found here (

          A thing to note with the standard logs for event ID 4662 is that it is only possible to tell if replication was performed and not what. To see the “what” was replicated it is required to enable the diagnostic logging which will be extremely verbose and is not recommended for long-term production use.

          Joe (Stealthbits)

    • This attack doesn’t need to run under the SYSTEM account, that is something that DCShadow requires. In any case, whether you run this as a user or computer that account will need the replication permissions listed above in the blog post granted on the domain object.

Leave a Reply

Your email address will not be published. Required fields are marked *




© 2022 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.