Dumping at nanolevel. How I reinvented SafetyKatz to dump LSASS with NanoDump

NanoDump has already gained widespread appreciation among AV/EDR vendors, which resulted in the creation of multiple detectors for it. Therefore, now I can safely share my experience related to the usage of this utility in the course of internal pentesting audits.

Introduction

In the old days, the trees were greener, and antivirus solutions weren’t so cruel to ordinary hackers pentesters. At that time (some five years ago), an interesting tool called SafetyKatz was created as part of the GhostPack collection, and its author, @harmj0y, breathed new life into the well-known Mimikatz (that was easily detected by security tools if used alone).

SafetyKatz decomposes the extraction of authentication data from LSASS into two stages: (1) dumping memory using the dbghelp.dll!MiniDumpWriteDump API handle; and (2) parsing the obtained dump file using modified (with reduced functionality) Mimikatz. The latter one is loaded to memory using the PE Reflection technique and executes the hardcoded commands sekurlsa::logonpasswords and sekurlsa::ekeys in relation to the previously created memory dump. When the utility completes its work, the created artifacts (e.g. the minidump file saved at C:\Windows\Temp\debug.bin) are deleted from the victim’s file system.

At some point, this approach made it possible to reduce the number of detections of ‘live’ usage of sekurlsa::logonpasswords, reduce the time required to extract hashes and keys (by eliminating the need to download large memory dumps to the attacker’s host), and conceal the Mimikatz signature from static analysis. For a long time, my team was using approximately the same approach; the only difference was that I used the new-fashioned NanoDump from memory to create a memory snapshot and a C# library to parse it locally.

This article explains how to create your own ‘SafetyNDump’ for fun ~~ and profit~~, but first, let’s examine the auxiliary tools.

System.Reflection.Assembly. The King is Dead — Long Live the King!

I really like PowerShell and its functionality in the offensive security context. If the combination AppLocker + Constrained Language Mode isn’t enabled in the target infrastructure, the usability of this Windows automation tool in regular pentesting audits is a godsend for a simulated attacker. In cybersecurity exercises requiring covert command execution, it can be adapted to attacker’s needs by patching ETW, calling the System.Management.Automation runspace (I’m looking at you, PowerShx), and performing other tricks.

My goal was to execute precrafted C# code using the System.Reflection.Assembly mechanism, which can further simplify lives of ethical hackers connecting to network nodes via the WinRM (Windows Remote Management) service or, for example, using exec.py scripts from Impacket.

There are plenty of materials on the Internet explaining how to execute C# code using PowerShell, but, as usual, I needed automation… Therefore, I wrote a simple Python utility called bin2pwsh that can convert binaries compiled in C# into PowerShell launchers.

The utility performs the following operations:

• Automatically creates PowerShell launchers from compiled C# executables based on predefined templates (the classic one or using Emit primitives). Bytes of the executables are compressed with zlib and wrapped in Base64 for embedding into .ps1 scripts;
• The cool Donut tool can be used if you need to execute unmanaged code from PowerShell to make system calls: either direct ones (Donut fork by @s4ntiago_p for Linux) or indirect ones (closed Donut fork by @KlezVirus and Porchetta Industries for Windows with on-the-fly rehashing). The unmanaged code is executed thanks to preliminary cross-compilation on Linux (with Mono) or regular compilation on Windows (with csc.exe) of a C# self-injector based on templates by @bohops (Unmanaged Code Execution with .NET Dynamic PInvoke) and @dr4k0nia (HInvoke and avoiding PInvoke). They work without static P/Invoke imports for WinAPI calls; and 
• Implements simple AV evasion techniques: AMSI and ETW patching, RC4 payload encryption using built-in Windows mechanisms, and static string obfuscation.

Let’s examine some usage examples.

Example 1 (a basic one)

This is Rubeus wrapped in a PowerShell launcher on the basis of the standard System.Reflection.Assembly template.

Example 2 (an advanced one)

Now let’s examine Rubeus wrapped in a PowerShell launcher in a more advanced way on the basis of the System.Reflection.Emit template and its execution by running a shellcode self-injector created on the basis of the Donut fork by KlezVirus with dynamic rehashing of indirect system calls (for more detail, see the video on YouTube). In most cases, this method is used with native code, but no one prohibits you from packing managed code this way.

Example 3 (DIY: PowerSharpPack)

And finally, let’s create an analogue of the PowerSharpPack repository (by @ShitSecure) from SharpCollection (by @Flangvik); it will take just a few seconds.

Done with auxiliary tools; now let’s get back to the problem. I suggest to stick to the SafetyKatz decomposition narrative and examine the dumping and dump parsing processes in sequence.

SafetyNDump: dumping LSASS bypassing AV

First of all, you have to dump lsass.exe memory. Importantly, this must be done in the presence of active antivirus tools.

Impersonating SYSTEM from noninteractive console

When I was testing NanoDump on a PC with Kaspersky Antivirus, the -eh/--elevate-handle option (taken from this presentation) turned out to be effective. The main idea was to open a handle to the target process with PROCESS_QUERY_LIMITED_INFORMATION privileges and then elevate them to the required level using ntdll.dll!NtDuplicateObject. As you might know, one of the ways to block access to LSASS is to make it impossible to get a privileged handle to lsass.exe, and the above-described trick allows to circumvent this restriction.

The problem with the -eh option is that you have to run NanoDump with NT AUTHORITY\SYSTEM privileges, which brings additional difficulties. Should you try to drop PsExec on the target host? Or create an immediate privileged scheduler task? Or, perhaps, substitute service binaries? All these options are time consuming, tedious, and noisy.

I decided to use the Token Impersonation technique (MITRE ATT&CK T1134.001) and modify the tokenduplicator utility (I often use it as a fileless alternative to PsExec). First, let’s see how it operates in its original form. I am going to clone the repository, build a release, and transform it into a PowerShell launcher using bin2pwsh.

Then I load it into memory and steal the token from winlogon.exe to start the shell with system privileges.

Everything looks great, but there is a catch: to make it work, an interactive shell is required.

As far as I remember from the OSEP course, to run CreateProcessWithTokenW from a noninteractive session, you have to adjust default values of the environment parameters dwLogonFlags, dwCreationFlags, lpEnvironment, and lpCurrentDirectory in tokenduplicator. Without these options, the started process immediately crashes since the SYSTEM account (the one you impersonate) doesn’t have a correctly defined login session.

I removed the unnecessary information output, and my TokenDuplicator.Program.Main looks as shown below:

Now when you run Invoke-TokenDuplicator from Evil-WinRM, the PowerShell command is successfully executed, and interpreter pop-up window isn’t displayed to the logged-in user. Yes, you don’t capture the output of the executed command, but it’s not actually required.

SafetyNDump.Net.WebClient or Resolve-DnsName?

To fit into the 1024 characters allocated for the lpCommandLine argument of the CreateProcessWithTokenW function, you have to use a boot cradle to extract and execute an external PowerShell script containing NanoDump (transformed into a launcher using bin2pwsh and Donut).

However, antivirus solutions can interfere in such a situation since they don’t tolerate when something like IEX (IWR http://...) is passed as a string to sections of the code where processes are spawned (e.g. objects of the Win32_Process class are created using WMI, or scheduler tasks are started, or interaction with Windows API occurs).

But the old trick with resolving a TXT record of the controlled domain name and its subsequent piping to Invoke-Expression comes to the rescue. This step makes it possible to evade analysis of string artifacts that appear when ‘something unknown’ is loaded and executed (needless to say that such analysis would inevitably trigger the AV). Experiments involving the start of PowerShell via wmiexec.py showed that this trick can successfully fool my favorite antivirus.

Overall, the idea is clear: you go to your domain settings and adjust them as shown below.

After that, you can pass the URL to the payload to IEX:

With this trick, the code that spawns a new process with a cradle looks as follows:

Now all you have to do to complete the first stage (LSASS dumping) is build a PowerShell launcher for NanoDump and make sure that everything works properly.

Time to move on to the second stage: on-site parsing of the created dump file.

Writing SafetyNDump

Parsing MiniDump

In my humble opinion, the main problem that contributed to the creation of SafetyKatz was the lack of flexible open-source software (e.g. written in C#) making it possible to parse the MiniDump format. This feature could be added to the code more elegantly. As a result, all these tricks where reflected PE is loaded to memory were used. However, time marches on; both offensive software and antivirus solutions continuously evolve; and now you can parse LSASS from memory in a more elegant way. For example, using MiniDump by @cube0x0.

To use this utility (that rather resembles a library), let’s hardcode the input arguments and obfuscate the strings with InvisibilityCloak. If you don’t do this, a process memory scan would notice that your code is similar to Mimikatz and raise the alarm. Initially, I also corrected the MiniDump signature prior to reading it (NanoDump deliberately breaks it to avoid generating IOCs when the file is saved to disk), but, in fact, this wasn’t necessary.

Then I compile the binary and… use bin2pwsh again to convert it into a PowerShell script.

Let’s check whether all components work properly and proceed to the final step: putting everything together in the form of a PowerShell script.

Putting results together

For clarity and simplicity, I just provide the final code with required comments:

Finally, let’s replace stubs with Base64 byte strings TokenDuplicator and MiniDump — and everything is ready for the final test! At the present time, the above-described method won’t work on Kaspersky Antivirus; accordingly, there’s no point in demonstrating the result on it. Instead, I will try to reproduce my actions performed during real-life pentesting audits using a demo stand.

The following actions were performed:

1. Checked that the resulting files don’t exist on the victim host (see step 2 to find out where lol.txt comes from);
2. Called Invoke-SafetyNDump.ps1 using wmiexec.py without requesting command output (flags -silentcommand -nooutput). For the sake of demonstration, to redirect the output of Invoke-SafetyNDump, I changed its start as follows: Invoke-Stage 2 > C:\Windows\Temp\lol.txt. The payload.txt file contains the NanoDump PowerShell launcher; and 
3. Demonstrated that NanoDump has successfully done its job by reading the results from the file C:\Windows\Temp\lol.txt. As a result, the much-desired hashes were gained.

This is how you can craft advanced ‘malware’ (of course, for the purposes of ethical hacking!) using open-source software and a few lines of PowerShell code.

Protection

Instead of drawing conclusions, I am going to provide a list of recommendations that can help you to mitigate potential abuses of PowerShell capabilities by cybercriminals. It’s assumed that you are dealing with a corporate Active Directory environment and your primary objective is to secure terminal servers and user workstations.

• Enable the Constrained Language mode to block potentially dangerous PowerShell functions (e.g. the Invoke-Expression cmdlet);
• Disable the possibility to create COM and .NET objects, add custom data types using the Add-Type cmdlet, and other features widely used in malware;
• Configure script execution security rules using the AppLocker tool or the SRP (Software Restriction Policies) mechanism to prohibit the use of third-party PowerShell scripts;
• Disable the insecure PowerShell 2.0 engine (that doesn’t support the AMSI protection mechanism) and disable the PowerShell ISE development environment; and 
• Introduce Windows Defender Application Control (WDAC) security policies to control the start of executable files in accordance with the employee workflow specifics.

Good luck to you and have fun during pentesting audits!