mimikatz
mimikatz is a tool made in C .
It's now well known to extract plaintexts passwords, hash, PIN code and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets.
Kiwi module in a meterpreter in metasploit is an adaptation of mimikatz.
No installation, portable
Download from: https://github.com/ParrotSec/mimikatz.git
Basic usage
PassTheTicket attack
An Example
1. Enumerating SPNs with setspn.exe
We will focus on user accounts and ignore the computer accounts returned by the tool.
2. Using PowerShell, we can request TGS tickets for the interested account and load them into memory.
3. If needed, we could also retrieve all tickets:
4. Extract Tickets from Memory with Mimikatz
5. Next, we can take the base64 blob and remove new lines and white spaces since the output is column wrapped, and we need it all on one line for the next step.
6. We can place the above single line of output into a file and convert it back to a .kirbi file using the base64 utility.
7. Use kirbi2john.py:
This will create a file called crack_file. We then must modify the file a bit to be able to use Hashcat against the hash.
8. Cracking the Hash with Hashcat
If we decide to skip the base64 output with Mimikatz and type mimikatz # kerberos::list /export, the .kirbi file (or files) will be written to disk. In this case, we can download the file(s) and run kirbi2john.py against them directly, skipping the base64 decoding step.
Evading Windows Credential Guard
What is Windows Credential Guard and how it protects password dumping
Unlike local account hashes which are stored in the SAM, credential information such as domain hashes are stored in the memory of the lsass.exe process. Fortunately, Mimikatz can locate these stored credentials for us. Because of this Microsoft has introduced several mitigations to attempt to combat this.
When Windows Credential Guard is enabled (check with Get-ComputerInfo), the Local Security Authority (LSASS) environment runs as a trustlet in VTL1 named LSAISO.exe (LSA Isolated) and communicates with the LSASS.exe process running in VTL0 through an RCP channel.
Virtualization-based Security (VBS) is a software technology which creates and isolates secure regions of memory which become the root of trust of the operating system. VBS runs a hypervisor on the physical hardware rather than running on the operating system. Specifically, VBS is implemented through Hyper-V, Microsoft's native hypervisor. In addition, Microsoft built the Virtual Secure Mode (VSM) which is a set of hypervisor capabilities offered to the Hyper-V partitions. VSM maintains this isolation through what is known as Virtual Trust Levels (VTLs). Each VTL represents a separate isolated memory region and currently Microsoft supports up to 16 levels, ranked from least privileged, VTL0, to VTL1, with VTL1 having more privileges than VTL0 and so on. As of the writing of this module Windows uses two VTLs:
- VTL0 (VSM Normal Mode): Contains the Windows environment that hosts regular user-mode processes as well as a normal kernel (nt) and kernel-mode data.
- VTL1 (VSM Secure Mode): Contains an isolated Windows environment used for critical functionalities.
The user-mode in VTL1 is known as Isolated User-Mode (IUM), which consists of IUM processes known as Trusted Processes, Secure Processes, or Trustlets.
Microsoft has used VSM as a base for several mitigations including Device Guard, virtual TPMs and Credential Guard.
In this Module, we'll focus on Credential Guard mitigation. When enabled, the Local Security Authority (LSASS) environment runs as a trustlet in VTL1 named LSAISO.exe (LSA Isolated) and communicates with the LSASS.exe process running in VTL0 through an RCP channel.
Mimikatz can peruse the memory of the LSASS process and retrieve cached hashes, credentials and information. With the new process running in VTL1, all the cached hashes and credential information is stored there, rather than in the memory of the LSASS process, meaning we can't access it.
The workaround for Windows Credential Guard: abusing Security Support Provider Interfaces (SSPI)
Given that we can't retrieve cached hashes and credentials, we must change our focus. Instead of trying to get this information after a user has already logged into the box, we could attempt to intercept the credentials while a user is logging in.
Microsoft provides quite a few authentication mechanisms as part of the Windows operating system such as Local Security Authority (LSA) Authentication, Winlogon, Security Support Provider Interfaces (SSPI), etc.
Specifically, SSPI is foundational as it is used by all applications and services that require authentication. By default, Windows provides several Security Support Providers (SSP) such as Kerberos Security Support Provider, NTLM Security Support Provider, etc. these are incorporated into the SSPI as DLLs and when authentication happens the SSPI decides which one to use.
Additionally the SSP can also be registered through the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages registry key. Each time the system starts up, the Local Security Authority (lsass.exe) loads the SSP DLLs present in the list pointed to by the registry key.
What this means is that if we were to develop our own SSP and register it with LSASS, we could maybe force the SSPI to use our malicious Security Support Provider DLL for authentication.
Fortunately, Mimikatz already supports this through the memssp, which not only provides the required Security Support Provider (SSP) functionality but injects it directly into the memory of the lsass.exe process without dropping any DLLs on disk.
The Mimikatz SSP takes advantage of the fact that a SSP is called with plaintext credentials through the SSPI allowing us to intercept them directly without needing to resort to a hash.
Bypassing Windows Credential Guard
When injecting a SSP into LSASS using Mimikatz, the credentials will be saved in a log file, C:\Windows\System32\mimilsa.log.
At this point, we have two options, we can either be patient and wait for another user to remotely connect to the machine or we can resort to additional techniques such as social engineering to coerce someone to log in.
Last update: 2026-01-25 Created: July 12, 2023 19:45:03