I have had requests about understanding Powershell Mimikatz attacks. One great resource is a post from adsecurity found HERE that provides an overview and defense recommendations. Microsoft also posted about Hacktool: Win32/Mimikatz HERE with remediation recommendations. Below is part of the adsecurity post. If you haven’t heard of this attack, you should read this.
It seems like many people on both sides of the fence, Red & Blue, aren’t familiar with most of Mimikatz’s capabilities, so I put together this information on all the available commands I could find. I plan to update as I can with additional content about the most useful commands. This way both Red & Blue teams better understand the full capability and are better able to secure the enterprises they are hired to protect.
I developed this reference after speaking with a lot of people, hired to both defend and attack networks, I learned that outside of a few of the mot frequently used Mimikatz commands, not many knew about the full capability of Mimikatz. This page details as best as possible what each command is, how it works, the rights required to run it, the parameters (required & optional), as well as screenshots and additional context (where possible). There are several I haven’t delved fully into, but expect to in the near future. While I will continue to post articles to ADSecurity.org about different aspects of Mimikatz usage, I plan to keep this as updated and as comprehensive as possible.
This information is provided to help organizations better understand Mimikatz capability and is not to be used for unlawful activity. Do NOT use Mimikatz on computers you don’t own or have been allowed/approved to. In other words, don’t pen-test/red-team systems with Mimikatz without a “get out of jail free card”.
This page and all content contained within is not to be reproduced in whole or part without express written consent by this page’s author.
I did not write Mimikatz and therefore have no special insight. All of the information on this page is derived from using Mimikatz, reading the source code, conversations with Benjamin, his blog & GitHub pages, and my own work/research.
Any errors on this page are my own only. Send comments/kudus here.
Many thanks to Benjamin Delpy for writing and continuously updating Mimikatz. His work has greatly improved the security of Windows, especially Windows 10.
Mimikatz is one of the best tools to gather credential data from Windows systems. In fact I consider Mimikatz to be the “Swiss army knife” (or multi-tool) of Windows credentials – that one tool that can do everything. Since the author of Mimikatz, Benjamin Delpy, is French most of the resources describing Mimikatz usage is in French, at least on his blog. The Mimikatz GitHub repository is in English and includes useful information on command usage.
Mimikatz is a Windows x32/x64 program coded in C by Benjamin Delpy (@gentilkiwi) in 2007 to learn more about Windows credentials (and as a Proof of Concept). There are two optional components that provide additional features, mimidrv (driver to interact with the Windows kernal) and mimilib (AppLocker bypass, Auth package/SSP, password filter, and sekurlsa for WinDBG). Mimikatz requires administrator or SYSTEM and often debug rights in order to perform certain actions and interact with the LSASS process (depending on the action requested). The Mimikatz.exe contains, or at least should contain, all capability noted there.
Mimikatz capability can be leveraged by compiling and running your own version, running the Mimikatz executable, leveraging the MetaSploit script, the official Invoke-Mimikatz PowerShell version, or one of the dozen of Mimikatz PowerShell variants (I happen to be partial to PowerShell Empire, because Empire is awesome!).
The Mimikatz source code and release binaries are available on GitHub and is licensed under Creative Commons with the following detail:
You are free to:
* Share — copy and redistribute the material in any medium or format
* Adapt — remix, transform, and build upon the material
* for any purpose, even commercially.
The licensor cannot revoke these freedoms as long as you follow the license terms.
Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
- Benjamin DELPY
gentilkiwi, you can contact him on Twitter ( @gentilkiwi ) or by mail ( benjamin [at] gentilkiwi.com )
- DCSync function in
lsadumpmodule was co-written with Vincent LE TOUX, you contact him by mail ( vincent.letoux [at] gmail.com ) or visit his website ( http://www.mysmartlogon.com )
“Official” Mimikatz Links:
Mimikatz GitHub Location (Source Code)
Mimikatz Releases (includes binaries)
Mimikatz GitHub Wiki (Documentation, some of which is reproduced here)
GentilKiwi Blog (much of it is in French, use Chrome/other for translation)
Mimikatz & Credentials:
After a user logs on, a variety of credentials are generated and stored in the Local Security Authority Subsystem Service, LSASS, process in memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested. The credential data may include Kerberos tickets, NTLM password hashes, LM password hashes (if the password is <15 characters, depending on Windows OS version and patch level), and even clear-text passwords (to support WDigest and SSP authentication among others. While you can prevent a Windows computer from creating the LM hash in the local computer SAM database (and the AD database), this doesn’t prevent the system from generating the LM hash in memory. By default, Windows Server 2008 and Windows Vista no longer generate LM hashes for users unless explicitly enabled. Starting with Windows 8.1 and Windows Server 2012 R2, the LM hash and “clear-text” password are no longer in memory. This functionality was also “back-ported” to earlier versions of Windows (Windows 7/8/2008R2/2012) in kb2871997, though in order to prevent the “clear-text” password from being placed in LSASS, the following registry key needs to be set to “0” (Digest Disabled):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest “UseLogonCredential”(DWORD)This registry key is worth monitoring in your environment since an attacker may wish to set it to 1 to enable Digest password support which forces “clear-text” passwords to be placed in LSASS on any version of Windows from Windows 7/2008R2 up to Windows 10/2012R2. Windows 8.1/2012 R2 and newer do not have a “UseLogonCredential” DWORD value, so it would have to be created. The existence of this key on these systems may indicate a problem.
Note that running code directly on a target system is rarely desirable for an attacker, so Mimikatz is continuously updated with new capability to be run remotely. This include running Mimikatz remotely against a remote system to dump credentials, using Invoke-Mimikatz remotely with PowerShell Remoting, and DCSync, the latest feature to grab password data for any Active Directory account in the domain remotely against a DC without any Mimikatz code being run on the DC (it uses Microsoft’s Domain Controller official replication APIs, once the correct rights are attained).
Available Credentials by OS:
Benjamin Delpy posted an Excel chart on OneDrive (shown below) that shows what type of credential data is available in memory (LSASS), including on Windows 8.1 and Windows 2012 R2 which have enhanced protection mechanisms reducing the amount and type of credentials kept in memory.
PowerShell & Mimikatz:
The majority of Mimikatz functionality is available in PowerSploit (PowerShell Post-Exploitation Framework) through the “Invoke-Mimikatz” PowerShell script (written by Joseph Bialek) which “leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as dump credentials without ever writing the Mimikatz binary to disk.” Note that the PowerSploit framework is now hosted in the “PowerShellMafia” GitHub repository.
What gives Invoke-Mimikatz its “magic” is the ability to reflectively load the Mimikatz DLL (embedded in the script) into memory. The Invoke-Mimikatz code can be downloaded from the Internet (or intranet server), and executed from memory without anything touching disk. Furthermore, if Invoke-Mimikatz is run with the appropriate rights and the target computer has PowerShell Remoting enabled, it can pull credentials from other systems, as well as execute the standard Mimikatz commands remotely, without files being dropped on the remote system.
Invoke-Mimikatz is not updated when Mimikatz is, though it can be (manually). One can swap out the DLL encoded elements (32bit & 64bit versions) with newer ones. Will Schroeder (@HarmJ0y) has information on updating the Mimikatz DLLs in Invoke-Mimikatz (it’s not a very complicated process). The PowerShell Empire version of Invoke-Mimikatz is usually kept up to date.
- Use mimikatz to dump credentials out of LSASS: Invoke-Mimikatz -DumpCreds
- Use mimikatz to export all private certificates (even if they are marked non-exportable): Invoke-Mimikatz –DumpCerts
- Elevate privilege to have debug rights on remote computer: Invoke-Mimikatz -Command “privilege::debug exit” -ComputerName “computer1”
The Invoke-Mimikatz “Command” parameter enables Invoke-Mimikatz to run custom Mimikatz commands.
Defenders should expect that any functionality included in Mimikatz is available in Invoke-Mimikatz.
There are several ways to potentially detect Mimikatz use on a network, though none are guaranteed. Since Mimikatz’s source code is on GitHub, anyone with Visual Studio can compile their own version. I built my own version of Mimikatz called “kitikatz” by replacing all instances of “mimikatz” with “kitikatz” and the detection rate at VirusTotal was not good (4/54). Windows Defender on my Windows 10 system detected it. I then replaced “Benjamin Delpy” and “gentilkiwi” with the same words, just replacing the e’s with 3’s and the i’s with 1’s. The detection rate was still poor (4/54). Windows Defender on my Windows 10 system did not detect it. So, your mileage will vary regarding detection. While VirusTotal is not the best method to determine AV detection, it is a relatively simple method to get some basic numbers.
- Benjamin Delpy publishes YARA rules for Mimikatz on the Mimkatz GitHub repository.
- Run AntiVirus software with the latest definition files. According to VirusTotal, the mimikatz.exe dated 11/11/2015 (32bit & 64bit) is detected by 35/35 of the AV engines. Renaming the file doesn’t change the scan results. Note that Benjamin has noted real-world results to be less successful. However, AV will usually flag the known bad files. AntiVirus is part of foundational security – the first layer in “defense in depth”.
- Mimikatz (as of October) activates attached BusyLights. [implemented in Mimikatz version 2.0 alpha 20151008 (oe.eo) edition]
- Leverage security software to identify processes that interact with LSASS. Security software that monitors for process injection may also be able to regularly detect Mimikatz use.
- HoneyTokens/HoneyHashes involves placing special credentials in memory on a number of computers in the enterprise. These credentials are flagged so when anyone attempts to use them, a critical alert goes out. this requires some sort of push method as well as placing credentials that are attractive to an attacker. In theory, this could detect credential theft and use in the environment.
- If the WDIGEST registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest) is supposed to be set to “0” in the enterprise to prevent “clear-text” passwords from being stored in LSASS and there are systems where it was switched to “1”, this may be indicative of credential theft activity. This registry key is worth monitoring in your environment since an attacker may wish to set it to 0 to enable Digest password support which forces “clear-text” passwords to be placed in LSASS on any version of Windows from Windows 7/2008R2 up to Windows 10/2012R2 (probably 2016 as well).
- Forged Kerberos ticket detection is covered on this page I published in early 2015. These methods can detect Golden Tickets, Silver Tickets, and Trust Tickets. I also have information on how to detect MS14-068 Kerberos vulnerability exploitation.
- Enable LSA Protection on all Windows versions in the enterprise that supports it. This prevents Mimikatz from working “out-of-the-box” and requires use of the Mimikatz driver which logs events when it interacts with LSASS.
- There are new/updated events starting with Windows 10 and Windows Server 2016 to potentially detect Mimikatz use:
Added a default process SACL to LSASS.exe
In Windows 10, a default process SACL was added to LSASS.exe to log processes attempting to access LSASS.exe. The SACL is L”S:(AU;SAFA;0x0010;;;WD)”. You can enable this under Advanced Audit Policy Configuration\Object Access\Audit Kernel Object.
This can help identify attacks that steal credentials from the memory of a process.
Mimikatz & LSA Protection:
Windows Server 2012 R2 and Windows 8.1 includes a new feature called LSA Protection which involves enabling LSASS as a protected process on Windows Server 2012 R2 (Mimikatz can bypass with a driver, but that should make some noise in the event logs):
The LSA, which includes the Local Security Authority Server Service (LSASS) process, validates users for local and remote sign-ins and enforces local security policies. The Windows 8.1 operating system provides additional protection for the LSA to prevent reading memory and code injection by non-protected processes. This provides added security for the credentials that the LSA stores and manages.
Enabling LSA protection:
- Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and Set the value of the registry key to: “RunAsPPL”=dword:00000001.
- Create a new GPO and browse to Computer Configuration, Preferences, Windows Settings. Right-click Registry, point to New, and then click Registry Item. The New Registry Properties dialog box appears. In the Hive list, click HKEY_LOCAL_MACHINE. In the Key Path list, browse to SYSTEM\CurrentControlSet\Control\Lsa. In the Value name box, type RunAsPPL. In the Value type box, click the REG_DWORD. In the Value data box, type 00000001.Click OK.
- Ensure all Windows systems have PowerShell v3 or newer. Newer versions of PowerShell have better logging features, especially PowerShell v5.
- Enable PowerShell Module Logging via Group Policy: Computer Configuration, Policies, Administrative Templates, Windows Components, and Windows PowerShell,Turn on Module Logging. Enter “*” and click OK. This will log all PowerShell activity including all PowerShell modules.
- PowerShell activity will be logged to the PowerShell Operational Log. Push or pull these events to a central logging server (via Windows Event Forwarding or similar) or SIEM.
- Parse PowerShell events for the following:
- “System.Reflection.Emit.AssemblyBuilderAccess “
Note: While it may be possible to identify Mimikatz usage by alerting on “mimikatz”, “Delpy”, or “gentilkiwi”, a “sophisticated” attacker will likely roll their own version of Mimikatz or Invoke-Mimikatz without these keywords.
Detecting Offensive PowerShell Tools:
Many PowerShell offensive tools use the following calls which are logged in PowerShell Module Logging.
“Sneaky” Mimikatz Execution:
Casey Smith (@subtee & blog) has done a LOT of work showing how application whitelisting is not the panacea many believe it to be. Despite that, application whitelisting is a solid layer in a defense in depth strategy.
Casey also has come up with many creative and sneaky ways to execute Mimikatz.
- Execute Mimikatz Inside of RegSvcs or RegAsm – .NET utilities Proof of Concept
- Mimikatz packed & hidden in an image file
- Downloads and Executes Mimikatz In Memory From GitHub
Most Popular Mimikatz Commands:
Here are just some of the most popular Mimikatz command and related functionality.
- CRYPTO::Certificates – list/export certificates
- KERBEROS::Golden – create golden/silver/trust tickets
- KERBEROS::List – List all user tickets (TGT and TGS) in user memory. No special privileges required since it only displays the current user’s tickets.Similar to functionality of “klist”.
- KERBEROS::PTT – pass the ticket. Typically used to inject a stolen or forged Kerberos ticket (golden/silver/trust).
- LSADUMP::DCSync – ask a DC to synchronize an object (get password data for account). No need to run code on DC.
- LSADUMP::LSA – Ask LSA Server to retrieve SAM/AD enterprise (normal, patch on the fly or inject). Use to dump all Active Directory domain credentials from a Domain Controller or lsass.dmp dump file. Also used to get specific account credential such as krbtgt with the parameter /name: “/name:krbtgt”
- LSADUMP::SAM – get the SysKey to decrypt SAM entries (from registry or hive). The SAM option connects to the local Security Account Manager (SAM) database and dumps credentials for local accounts. This is used to dump all local credentials on a Windows computer.
- LSADUMP::Trust – Ask LSA Server to retrieve Trust Auth Information (normal or patch on the fly). Dumps trust keys (passwords) for all associated trusts (domain/forest).
- MISC::AddSid – Add to SIDHistory to user account. The first value is the target account and the second value is the account/group name(s) (or SID). Moved to SID:modify as of May 6th, 2016.
- MISC::MemSSP – Inject a malicious Windows SSP to log locally authenticated credentials.
- MISC::Skeleton – Inject Skeleton Key into LSASS process on Domain Controller. This enables all user authentication to the Skeleton Key patched DC to use a “master password” (aka Skeleton Keys) as well as their usual password.
- PRIVILEGE::Debug – get debug rights (this or Local System rights is required for many Mimikatz commands).
- SEKURLSA::Ekeys – list Kerberos encryption keys
- SEKURLSA::Kerberos – List Kerberos credentials for all authenticated users (including services and computer account)
- SEKURLSA::Krbtgt – get Domain Kerberos service account (KRBTGT)password data
- SEKURLSA::LogonPasswords – lists all available provider credentials. This usually shows recently logged on user and computer credentials.
- SEKURLSA::Pth – Pass- theHash and Over-Pass-the-Hash
- SEKURLSA::Tickets – Lists all available Kerberos tickets for all recently authenticated users, including services running under the context of a user account and the local computer’s AD computer account. Unlike kerberos::list, sekurlsa uses memory reading and is not subject to key export restrictions. sekurlsa can access tickets of others sessions (users).
- TOKEN::List – list all tokens of the system
- TOKEN::Elevate – impersonate a token. Used to elevate permissions to SYSTEM (default) or find a domain admin token on the box
- TOKEN::Elevate /domainadmin – impersonate a token with Domain Admin credentials.
ADSecurity Mimikatz Posts:
All posts mentioning Mimikatz: ADSecurity.org Mimikatz Posts
- Mimikatz and Active Directory Kerberos Attacks“
- Dump Clear-Text Passwords for All Admins in the Domain Using Mimikatz DCSync
- How Attackers Use Kerberos Silver Tickets to Exploit Systems
- Mimikatz DCSync Usage, Exploitation, and Detection
- Sneaky Active Directory Persistence #12: Malicious Security Support Provider (SSP)
- Sneaky Active Directory Persistence #11: Directory Service Restore Mode (DSRM)
- Kerberos Golden Tickets are Now More Golden
- It’s All About Trust – Forging Kerberos Trust Tickets to Spoof Access across Active Directory Trusts
- Detecting Mimikatz Use
Mimikatz Command Guide:
Read more at HERE ….