Obtaining Administrator credentials or multiple ways to work with Mimikatz

Що таке Mimikatz?

Mimikatz is a tool that implements the functionality of the Windows Credentials Editor and allows you to obtain the authentication data of the user logged into the user’s system in an open form. That is, a utility for intercepting passwords on Windows. It is well known for its ability to extract plaintext passwords, hashes, PINs, and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets. The mimikatz utility allows you to extract user passwords directly from memory (by injection into lsass.exe of the sekurlsa.dll library), from a saved computer memory dump, or even from a hibernation file. However, this method will not work if there is a modern antivirus blocking the injection on the system.

In this case, you will have to first create a dump of the machine’s memory and extract the passwords for the sessions of all users from it on another machine. Benjamin Delpy originally created Mimikatz as a proof of concept to demonstrate to Microsoft the vulnerability of their authentication protocols to attack. Instead, he inadvertently created one of the most widely used and downloaded hacking tools of the past 20 years. Benjamin Delpy continues to lead the development of Mimikatz, so the toolkit works with the current version of Windows and includes the most advanced types of attacks. Mimikatz first demonstrated how to exploit a single vulnerability in the Windows authentication system. This tool now covers several different types of vulnerabilities. Mimikatz is capable of many things, especially if you are interested in penetration testing or just want to dig into Windows’ internal authentication device.

A little theory

Most system administrators are sure that Windows does not store users’ passwords in the clear (ahaha), but only in the form of its hash. And although today there are a large number of utilities capable of extracting hashes of user passwords from the system, we can say with some confidence that when using a rather complex password that is not from the dictionary, an attacker has almost no chance to pick it up by direct brute force or based on already calculated hashes. It seems that our perimeter is not a criminal fortress! But! it wasn’t here! We have the Mimikatz utility in our arsenal that changes the entire schedule! In principle, this is true, but there are various nuances related to users logged into a specific Windows system. The fact is that some system processes do use user passwords in the open (or encrypted) form, and not their hashes, for their official purposes.

Passwords (passwords themselves, not their hashes) of users are stored in encrypted form in the memory of the OS, and to be more precise in the memory of the LSASS.EXE process. The problem is that password encryption is implemented using the standard Win32 functions LsaProtectMemory and LsaUnprotectMemory, which are designed to encrypt/decrypt a certain area of memory. The utility of the French developers mimikatz allows you to get encrypted data from memory and decrypt it using the LsaUnprotectMemory function, allowing you to display on the console all the accounts of users authorized in the system and their passwords (in an open, already decrypted form!). To exploit the vulnerability, an attacker must be able to attach the library to lsass.exe.

Options for use

We get passwords using the Debug method from memory

The program provides its own console, from which you can run the necessary modules for various situations (the concept of the “Swiss army knife”). To receive passwords in the form of plain text, you will need only three commands:

Retrieving a user’s password from a Windows memory dump

A memory dump for the LSASS process can be obtained using the PowerShell function Out-Minidump.ps1. Import the Out-Minidump function in PoSh and create a memory dump of the LSASS process:

The memory dump, in our example it is lsass_592.dmp (by default it is stored in the %windirsystem32% directory), you need to copy it to another computer that has the mimikatz utility and execute the command:

As you can see, nothing complicated. In this way, you can get a memory dump from a remote computer using psexec or WinRM (with administrator rights) and get the user’s password.

Retrieving user passwords from hibernate and VM files

With the help of simple manipulations, an attacker can easily obtain user passwords from memory dump files, system hibernation file (hiberfil.sys) and. vmem files of virtual machines (swap files of virtual machines and their snapshots). This will require the Debugging Tool for Windows (WinDbg) package, mimikatz itself, and a utility to convert .vmem to a memory dump file (for Hyper-V it can be vm2dmp.exe or MoonSols Windows Memory toolkit for VMWare vmem files).

For example, if you need to convert the vmem swap file of the VMWare virtual machine into a dump, execute the command:

Download the resulting dump into WinDbg (File -> Open Crash Dump), download the mimikatz library with the name mimilib.dll

We are looking for the lsass.exe process in the dump:

We type and get a list of Windows users and their passwords in open form.

Getting Windows user passwords in the open using the Mimikatz utility works on the following systems, including those running on Hyper-V 2008/2012 and VMWare hypervisors of various versions.

Using Mimikatz in pass-the-hash attacks

In the event that it is not possible to obtain the user’s password, but only its hash, Mimikatz can be used for a so-called pass-the-hash attack. In this case, the hash can be used to run processes on behalf of the user.

For example, after obtaining the user’s NTLM hash, the following command will run a command prompt as a privileged account:

Protection against attack

Preventing the possibility of receiving debug

By default, the rights to use the debug mode are granted to the local group of administrators (BUILTINAdministrators). Although in 99% of cases this privilege is absolutely not used by administrators (it is usually needed by system programmers), accordingly, for the sake of security, it is better to disable the possibility of using the SeDebugPrivilege privilege. This is done through group policy (local or domain).

Go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment and enable the Debug Program policy. To it, you need to add a domain group of users who may need debug rights (usually developers), or leave this group empty so that no one has this right.


Now, if you try to get debug through mimikatz, an error will appear:

Disable WDigest

The WDigest protocol appeared in Windows XP and was used to perform HTTP digest authentication (HTTP Digest Authentication), the feature of which was the use of the user’s password in the open form. In Windows 8.1 and Server 2012 R2, the ability to completely prohibit the storage of passwords in the open form of LSASS was added. To prevent storage of WDigest in memory, in these OSes, in the HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigest registry branch, there is already a DWORD32 parameter with the name UseLogonCredential and the value 0. If you want to completely disable the WDigest authentication method, in the same branch (HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigest) set the value of the Negotiate key to 0 To support this feature in Windows 7, 8 and Windows Server 2008 R2/2012, it is necessary to install a special update – KB2871997, and then expose the same registry keys.

Protection of LSA from the connection of third-party modules

Windows 8.1 and Windows Server 2012 R2 introduced the ability to enable LSA protection, which protects LSA memory and prevents connections to it from unprotected processes. To enable this protection, you need to create the RunAsPPL parameter with the value 1 in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLSA registry branch.

After applying the parameter, the attacker will not be able to access the LSA memory, mimikatz will issue an error on the securlsa::logonpassword command:

Disabling LM and NTLM

The outdated LM authentication protocol and, accordingly, the storage of LM hashes must be disabled using the Network Security group policy. Next, you need to refuse to use at least the NTLMv1 protocol (policy in the section Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options – Network Security: Restrict NTLM: NTLM authentication in this domain), and how maximum and NTLMv2

Prohibition of using reversible encryption

It should be explicitly forbidden to store passwords of AD users in plain text. To do this, you should enable the domain policy Store password using reversible encryption for all users in the domain in the section Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy, setting its value to Disabled.

Prohibition of using saved passwords

You can prevent domain users from saving their passwords to access network resources in Credential Manager. To do this, enable the Network access: Do not allow storage passwords and credentials for network authentication policy in the Computer Configuration -> Windows Settings ->Security Settings ->Local Policies ->Security Options section.

Prohibition of credential caching

One of the capabilities of mimikats is to obtain a hash of user passwords from the HKEY_LOCAL_MACHINESECURITYCache registry branch, which stores the password hashes of the last 10 (default) logged-in domain users. These hashes can normally be used to authenticate users to the system when the domain controller is unavailable. It is recommended to prohibit the use of saving cached data by enabling the policy Interactive Logon: Number of previous logons to cache (in case domain controller no available) in the section Computer Configuration -> Windows Settings -> Local Policy -> Security Options, changing the value of its parameter to 0 .


In addition, to speed up the memory cleanup of the lsass process from user accounts that have ended the session, you need to create a DWORD key with the name TokenLeakDetectDelaySecs and the value 30 in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa branch. The memory will be cleaned 30 seconds after the user logs on. In Windows 7, 8/ Server 2008R2, 2012, for this key to work, you need to install the previously mentioned update KB2871997.

Found an error?
If you find an error, take a screenshot and send it to the bot.