Mimikatz needs to be run with administrative privileges (on the local machine), and provides its own command prompt.
Use the privilege::debug command to check if you’re running with the right privileges.
Use log $FILENAME to log all output.
Dumping cleartext passwords
The WDigest process caches cleartext passwords for recently logged in users. Or at least it used to. This behavior is disabled on modern Windows systems, but can be re-enabled by a single registry edit:
Once this is set, Mimikatz can dump any cleartext passwords that WDigest caches. (Obviously, this only applies to logins made after the registry key above is set.)
privilege::debug
token::elevate
sekurlsa::wdigest
Note that accounts in the “Protected Users” group will not have their credentials cached, even with the above registry hack.
This provides NLTM hashes for recently logged in users:
privilege::debug
token::elevate
sekurlsa::msv
Cached passwords are dumped as plain text, instead of NTHashes.
The LSASS process can be protected against memory-based attacks. This protection can be bypassed by loading the mimidrv.sys driver and then executing !processprotect /process:lsass.exe /remove from within the Mimikatz shell.
Inject an NTLM hash into a process
Commands (including reverse shells, if the necessary binaries/scripts are available) can be launched from Mimikatz using the extracted NTLM hash for authentication. Note that this doesn’t work if your privileges are elevated (weird, right?), hence the initial token::revert command:
The shell produced in this way is a bit weird, as it is actually running as the user that launched Mimikatz (which will show up if you call whoami, though the privileges will be those of the $TARGET_USER.
Mimikatz can dump ticket granting tickets (and session keys) from the memory of Windows’ Local Security Authority Subsystem Service (LSASS); these can then be used to for privilege elevation or lateral movement (depending on which users are active on that machine).
Use the sekurlsa::tickets /export command to dump any Kerberos “tickets” (really ticket + session key data structures) from LSASS’s memory as .kirbi files. Tickets are named like ID-USER-SERVICE-DOMAIN.kirbi; ticket granting tickets have a krbtgt SERVICE name. If you can find a krbtgt ticket belonging to an administrator account, then you’ve (almost) struck gold.
Pass the ticket attacks
Mimikatz can extract Kerberos TGT/TGS tickets and session keys:
privilege::debug
sekurlsa::tickets /export
Note that TGTs for all users are available if you can run as SYSTEM; these allow TGS tickets to be requested for any service the corresponding user has access to. If you’re not running as SYSTEM, then you can get TGS tickets for the current user, which will give you access to those services the current user has permission to use (and has accessed recently).
Mimikatz can then inject tickets into the current session:
This allows the account you’re logged in as to (automatically!) “pass the ticket” and impersonate the user whose ticket you’ve harvested. The Windows built-in command klist will provide a list of currently active tickets.
Golden and silver ticket attacks
To generate Kerberosgolden and silver tickets using Mimikatz, begin by running the lsadump::lsa /inject /name:$SERVICE command to retrieve the service SID and NTLM password hash for that service. If SERVICE is krbtgt then this will allow the creation of a golden ticket, otherwise you’ll be creating a silver ticket.
(You can also use a user name instead of $SERVICE, in which case it appears that Mimikatz will just request a ticket granting ticket from the KDC as that user in the next step; this is theoretically just as noisy as a golden ticket, but looks more “normal”.)
To actually create and cache the ticket, use Kerberos::golden /user:$USER /domain:$DOMAIN /sid:$SID /krbtgt:$HASH /id:$TYPE, where:
$USER is the user to create the ticket for (probably the one you’ve compromised).
$DOMAIN is the domain to create the ticket for.
$SID is the SID of the service from the previous step.
$HASH is the NT hash of the service password from the previous step.
$TYPE is the type of Kerberos ticket to create; use 500 for a golden (ticket granting) ticket, and 1103 for a service ticket.
Once the ticket has been created, use misc::cmd to open a command prompt using the newly forged ticket.
Pass the key attacks
“Pass the key” attacks rely on the fact that Kerberos TGTs are granted based on an encrypted timestamp, so if we can get access to these objects we can request TGTs as the corresponding user. Turns out that these also hang out in memory and can be extracted with Mimikatz:
privilege::debug
sekurlsa::ekeys
These keys can be injected into a command environment just like an NTLM hash, though you need to know how they’re encrypted. For example, for an AES256 encrypted key:
Other options include /aes128 and /rc4 for those styles of encryption, though RC4 isn’t something that you’re likely to see as it’s weak and disabled by default. (Because of a historical quirk, the RC4 key is actually not a timestamp, but rather the user’s NTLM hash. So iff RC4 is enabled on a domain, then extracting a user’s NTLM hash is sufficient to request Kerberos TGTs as that user!)
KDC skeleton key
If Mimikatz is run on a domain controller, it can modify the authentication service’s memory using the misc::skeleton command to cause it to attempt to decrypt the AS-REQ using both the user’s NT hash and an NT hash of your choosing (by default 60BA4FCADC466C7A033C178194C03DF6, which is just mimikatz). This means that you can send an AS-REQ as any user using the “skeleton key” hash to gain access as that user, similar to a golden ticket attack.
Obviously this isn’t very persistent itself, as the skeleton key will be lost if the server is rebooted or the authentication service restarted.
Note that Microsoft Defender will still detect the execution of Invoke-Mimikatz and kill the hosting PowerShell process. This is why we need to redirect the output to a file.