Manipulating User Passwords with Mimikatz

Manipulating User Passwords with Mimikatz

Introduction: Manipulating User Passwords with Mimikatz

Mimikatz now supports the ability to manipulate user passwords with new commands: SetNTLM and ChangeNTLM. These commands give attackers a new way to change user passwords and escalate privileges within Active Directory. Let’s take a look at these NTLM commands and what they do.


This performs a password change event. To use this command, you must know the old password in order to set a new one. One deviation is that this command will accept either a password or NTLM password hash. NTLM password hashes can be much easier to come across for users than their clear text passwords.  Here is an example of using the lsadump::changentlm command to change a user’s password with only knowing their current password hash. ChangeNTLM using the lsadump::changentlm command to change a user password knowing their password hash will produce Event ID 4723 in the DC event log

While this does require you to know a user’s password hash, the permission controlling who can change a user’s password is granted to Everyone by default, so it can be done by any user without special privileges.

This will produce Event ID 4723 in the domain controller event log.


This performs a password reset event. This does not require any knowledge of a user’s current password, but it does require you to have the Reset Password right on an account by default, which is not open to Everyone. Here is an example of using the lsadump::setntlm command to reset a user’s password. SetNTLM using the lsadump::setntlm command to reset a user’s password will produce Event ID 4724 in the domain controller event log

This will produce Event ID 4724 in the domain controller event log.

Attack Scenario – ChangeNTLM

This scenario is straightforward. If an attacker can compromise any user’s password hash, it will be valuable for performing pass-the-hash attacks. Typically, pass-the-hash limits you to command line access to systems and applications. Let’s say an attacker wants to log into OWA, SharePoint, or a remote desktop session. They may need to type in the user’s clear text password. In this case, the attacker can:

  1. Compromise any account’s NTLM hash
  2. Change the password just using the hash to any password they want
  3. Perform their attack using clear text password
  4. Set the password back the way it was using the old hash

This attack is very useful for further exploiting already compromised accounts. Next, let’s look at SetNTLM and how that can be used to elevate privileges.

Attack Scenario – SetNTLM

Let’s imagine the following attack scenario. An attacker has compromised an account with limited domain access. They have used Bloodhound to build an attack path around AD permissions, which includes resetting user passwords to take over their account. The attacker wishes to follow the attack path, but does not want to alert users to the fact that their account has been compromised by changing their password. How can the attacker reset the users’ passwords, and then put them back to their old values once the target is compromised? Enter SetNTLM.

With these commands, the attacker can follow this basic path:

  1. Build attack path with Bloodhound leveraging Active Directory permissions and password resets
  2. Reset passwords following attack paths
  3. Once privileged access is achieved, use Mimikatz to extract NTLM password history for all compromised accounts
  4. Apply previous NTLM hash to the accounts, setting them back the way they were

Note: The same can be done using DSInternals and the Set-SamAccountPasswordHash command.

Performing the Attack

We have already covered how to use Bloodhound to build attack paths in this post. Let’s imagine I have the following attack path using Active Directory permissions. This will take me from my current user to Domain Admin in three password resets. PowerShell script command System.Management.Automation.PSCredential to build out password reset attack path impersonating each compromised user to reach Domain Admin

Now that you know what accounts need to be compromised, you want to be sure you go about the attack as quickly as possible to not alarm any users. You can script out the password reset attack path using some basic PowerShell. The following script will take a password and follow the attack chain, impersonating each compromised user along the way until reaching the goal of Domain Admin. #Reset accounts to get to Domain Admin following attack path Set-ADAccountPassword

Next, I will launch a new PowerShell session as the Domain Admin and perform a DCSync operation to get the NTLM password history for all of the accounts: System.Management.Automation.PSCredential

Launch PowerShell session as the Domain Admin and perform a DCSync operation to get the NTLM password history for all the accountsFrom there, I will set the passwords back to the way they were using the SetNTLM command: Use SetNTLM command to set passwords back after become a domain admin to avoid users realizing their accounts have been compromised

And there you have it. I now have become a domain admin, and covered my tracks as best I can to avoid users realizing their accounts have been compromised along the way.

Protections Against SetNTLM and ChangeNTLM Attacks

One thing I found interesting is that if an attacker does use the ChangeNTLM attack, this will generate a 4723 event but the Subject and Target Account will be different. This will stand out from normal password changes that users perform on their own, where the two values will be identical. If administrators are going to reset passwords, they will perform a reset and generate a 4724 event. Using ChangeNTLM generates a 4723 event but subject and target account differ whereas if admins reset passwords they will generate a 4724 event


Beyond that, these attacks still are mitigated by controlling password reset rights in the directory to avoid the SetNTLM attack, and controlling how and where user hashes get stored to reduce the risk of the ChangeNTLM attack.

How Attackers Are Stealing Your Credentials with Mimikatz:

To sign up for the Mimikatz blog series, please click here

To register for the Mimikatz webinar, please click here.

Jeff Warren is STEALTHbits’ Vice President of Product Management. Jeff has held multiple roles within the Product Management group since joining the organization in 2010, initially building STEALTHbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining STEALTHbits, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.

With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering STEALTHbits’ high quality, innovative solutions.

Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.

Leave a Reply

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