Utilizing Mimikatz for Advanced Post-Exploitation Lateral Movement and Persistence Attacks.
Introduction
Mimikatz is an amazing post-exploitation tool that has critical functionalities in what relates to dumping credentials, hashes, and Kerberos tickets. In addition to its dumping capabilities, lateral movement can be facilitated with Pass-the-Ticket (PtT), Token Impersonation, and Pass-the-Hash (PtH) attacks. Finally, it also provides persistence capabilities as well.
Getting Mimikatz to run by an attacker with elevated privileges in your environment could be really damaging. An attacker can use many other methods, but for the purpose of this article, the focus is on Mimikatz.
All of the techniques mentioned below are valid on Windows 8, Windows 10, Windows Server 2012, and Windows Server 2016. The mentioned OSs prevent LSASS from storing clear text passwords in memory by default.
The significance of the article is displayed by touching on several critical topics. In security-conscious organizations where strict security implementations are present, common lateral movement techniques that rely on passing the hash or abusing cached credentials through WMI and net.exe are not possible. Making the post-exploitation and lateral movement phases of an attacker more difficult. The significance of extracting clear text credentials on new Windows OSs is displayed here. Especially that modern and security-aware organizations are shifting their management and administration activities through PowerShell-Remoting (PS-Remoting) that does not allow cached credentials to be abused. Extracting clear text credentials comes in handy at this point especially if an attacker’s lateral movement is based on PS Remoting which would be considered normal traffic throughout the environment if it is being monitored.
The second significance of the article is that it emphasizes the importance of having high detection capabilities and early incident response through continuous monitoring and threat hunting for the early detection of and response to malicious activities. Relying on the first line of defense (AV) is not sufficient for hindering a determined attacker even with advanced protection interfaces such as Anti-Malware Scan Interface (AMSI) in place since customization of payloads still defeats static based detections, and reflective loading techniques help evade dynamic based analysis.
For presenting the results of the article, the screenshots and video below show the testing being made on a Windows 10 Pro machine Build 18363. The machine is fully updated to the most recent patches, updates, and the most recent Microsoft threat intelligence feeds.
Mimikatz version used Is the most recent version released on May 2nd without any customization or custom compilation.
At the end of this article, we will demonstrate how a security analyst can detect those attacks using EDR solutions (e.g., CarbonBlack) and other tools, like Kansa, with custom rules.
Updating Invoke-Mimikatz.ps1 Script
Invoke-Mimikatz.ps1 is the PowerShell implementation of Mimikatz. The PowerShell script loads Mimikatz.exe reflectively into the process memory. However, the scripts available need to be edited in order to work on the new Windows 10 build with recent patches, since the available scripts contain a version of Mimikatz that doesn’t support the current patches. So the first thing we need to do is getting the Invoke-Mimikatz.ps1 script to work on a fully updated and patched Windows 10 Pro machine.
Below is a representation of how the available scripts respond when executed:
In order to mitigate the issue, we will need to update the Mimikatz version embedded in the script to the most recently released Mimikatz version.
In the Invoke-Mimikatz.ps1 file, we will need to change the value of the variable “PEBytes64” with our new Mimikatz.exe. We will need to convert the new version of Mimikatz.exe to a Byte string. This can be done using a simple PowerShell script or certutil.exe as follows. In the PEBytes64 variable, paste the newly created byte array.
In short, here are the steps to do this update:
- To encode the new version of Mimikatz, issue the following command in CMD: certutil -encode Mimikataz.exe Mimikatz_Encoded.txt
- Open the Invoke-Mimikatz.ps1 file in a text editor, and locate the variable PEBytes64. It should read: $PEBytes64 = ‘TVqQAAMAAAAEAAAA/… … AAAAAAA=’
- Replace the entire value with the generated output in the Mimikatz_Encoded.txt file.
We confirm that the new script is functioning and that the loaded Mimikatz is the most recent release dated to May 2, 2020:
Evading Defender and AMSI
Evading AV and AMSI is indeed a cat and mouse game that requires a lot of experimenting and tweaking of code. However, as you will see by the end of the article, that it is doable on a fully updated Windows 10 machine Pro with Defender enabled including AMSI.
- Changing functions that could be clearly indicative as malicious (Invoke-Mimikatz!)
- Removing all comments from the script
- Altering script parameters that could be flagged such as the Invoke-Mimikatz –DumpCreds flag.
- Altering all argument instances
- Altering all CallDllMain instances.
- Altering Win32 function instances
After implementing the above changes, an additional obfuscation step is taken. Obfuscation is made through randomizing functions, parameters, variables, literal strings, and converting commands to aliases.
A third layer of obfuscation can be added where we can use standard PS obfuscations. Be careful that heavy obfuscation could break the script.
Now we attempt loading the Invoke-Mimikatz script using a remote download cradle that will execute the script in memory:
AMSI Evaded and Mimikatz.exe Loaded In Memory
Success. Mimikatz.exe is executed reflectively in memory. The first couple of errors are due to the obfuscation but nothing damaging the functionality of Mimikatz.exe.
https://www.youtube.com/watch?v=q8DQw4aKzI0
Bypassing Mimikatz Patch
Now, if we attempt to dump credentials, we will see that all values are null:
Null Valued Password
This is due to the LSASS patch where it does not store clear text credentials in memory. To bypass this issue, we will edit the WDigest registry keys as follows. Then we will force locking of the machine and wait for the user to log in:
Upon the user logging in, we attempt extracting the log-on credentials in clear text. In the below screenshot, we see that clear text passwords were extracted, also we see that Windows Defender and AMSI did not detect any malicious activity:
Clear-Text Credentials Extracted
Detection and Analysis
Detecting PowerShell attacks has become much more efficient throughout many organizations, however, there remain many evasion capabilities an attacker can abuse to use scripts through direct PowerShell usage.
The evasion capabilities start from abusing many different download cradles in addition to execution of scripts in memory using methods other than Invoke-Expression.
Also, the use of obfuscation techniques and methods could evade basic query-based detections. The significance of EDR solutions is that they allow the monitoring team to detect malicious behavior at a low level.
At Axon, using Carbon Black Response we can detect the several different ways PowerShell can be abused by monitoring for critical functionalities. For example, setting a rule that detects the loading of the ws2_32.dll module through PowerShell indicates a connection was made through PS to a remote server. This could be indicative of possible malicious activity that is worth investigating in an early stage regardless of what the attacker is using as a download cradle even if obfuscated.
cb.urlver=1&q=(process_name:powershell.exe AND modload:WS2_32.dll AND netconn_count:[1 TO *])
Additionally, we can use a query to detect certain know Mimikatz related DLL modules if they are being loaded into a PowerShell process:
cb.urlver=1&q=(modload:samlib.dll AND modload:vaultcli.dll AND process_name:powershell.exe)
If we look at the attack inside CBR, we can see that the injected Mimikatz has opened a handle with change access rights to a thread in LSASS.exe. This is not a normal behavior, so setting a detection on such instances with a parent process of PowerShell or CMD might be useful.
Additionally, using tools such as Kansa throughout the environment to detect process injections is extremely useful. Especially when the injection method is abusing PowerShell.
Reviewing the MITRE Technique T1055 — Process Injection describes methods of detecting process injections of both DLL’s and PE’s.
For effective detection, monitoring certain sequences of Windows API calls may be indicative of such malicious behavior. API calls such as CreateRemoteThread, SuspendThread, SetThreadContext, ResumeThread, QueueUserAPC, NtQueueApcThread, and those that can be used to modify memory within another process, such as WriteProcessMemory, may be used for this technique.
The WDigest registry key (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDIGEST) should be set to 0 by default. Monitor for changes or editing of its value by the following CBR query:
cb.urlver=1&q=(regmod: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDIGEST)
Make sure that PowerShell v3 or newer is being used by all systems. Enable PowerShell Module Logging via Group Policy, and parse PowerShell Events for the following:
- System.Reflection.AssemblyName
- System.Reflection.Emit.AssemblyBuilderAccess
- System.Runtime.InteropServices.MarshalAsAttribute
- TOKEN_PRIVILEGES
- SE_PRIVILEGE_ENABLED