Rethinking Credential Theft

Modern defensive security solutions use sophisticated techniques to prevent, detect and/or respond to malicious actions. These solutions are effective and are starting to hit red teamers where it hurts.

WithSecure has previously released presentations and tooling around most of the elements of the kill chain, most notably Custom Command & Control (C3) in September 2019. The team behind C3 found that their command and control (C2) channels kept getting caught by the blue team and so they wanted to push back. They found that they could leverage existing communication methods often found within enterprise environments to tunnel their C2 and have been using it successfully ever since the tool was released.

We wanted to push back too, and felt that lateral movement would be an interesting space to investigate due to the attention it receives from  defensive security solutions. One of the most important aspects of lateral movement is credential theft which was the focus of this research - the process of using privileged access to an operating system to extract credential material. 

There are a number of different techniques that can be used to retrieve credentials from an endpoint. The details of all of these techniques are beyond the scope of this post, here we'll be focusing on the process of retrieving credential material from the Local Security Authority Subsystem Service (LSASS).

Mimikatz is the de facto standard and most comprehensive tool for credential theft attacks. Initially, it was possible to execute Mimikatz on a target host directly, but security tooling quickly started to prevent against it. In certain situations it was possible to use obfuscation to evade detection. But, the simplest way for offensive security professionals to push back against these preventative measures was not to run Mimikatz on the endpoint at all, and so Mimikatz began providing support for 'minidumps' of LSASS. The beauty of this approach is that an attacker can first create a minidump of the LSASS process on their target system, exfiltrate it to the relative safety of their attacking machine, and then use Mimikatz offline to retrieve credentials far removed from any defensive security products.

There are legitimate reasons to create minidumps of processes, which is why Microsoft provides the functionality required to create them. The simplest approach is to right-click the LSASS process in Task Manager or use procdump from Microsoft’s Sysinternals suite. There are of course several custom implementations of the above tools, as well as some more esoteric approaches like using comsvcs.dll, a Dynamic Link Library (DLL) that ships with Windows by default. These approaches have been documented on a number of security blogs, but the use of comsvcs.dll was recently introduced into LSASSY and as a result is featured heavily in an excellent blog post by @Pixis titled Extract credentials from lsass remotely:

The problem with the techniques described above is that security vendors are well aware that security professionals and criminal hackers want to gain access to the LSASS process’ memory space. As a result, there are an increasing number of techniques to monitor access to it. In order to defeat the blue team on the battle field of credential theft, we felt that it was not enough to refine an existing technique, we needed a fresh angle and that led us to the following problem statement:

How can we access credential material without interacting with the LSASS process?

A key observation from our research was that credential theft attacks and consequently the defensive measures used to prevent them focus on access to the LSASS process, not the credential material. These concepts ultimately rely on virtual memory, but, at a very high-level, virtual memory is just an addressing method for data stored somewhere in physical memory. Anyone familiar with memory forensics knows that it is possible to analyze a physical memory image and obtain access to any process within it and its data - including credential material. We wanted to find out if we could incorporate this approach into our red team operations.

We started to work on a Proof-of-Concept (PoC) by searching the Internet for Volatility and Rekall plugins that would create a minidump of specific processes. You probably guessed that we did not find any. We did come cross an impressive tool by @skelsec called pypykatz which has a number of features including a Rekall plugin that retrieves credential material from a physical memory image. However, we specifically wanted a tool that could create minidumps for a very simple reason: nobody does it better than James Bond Mimikatz. In addition, we already had internal automation for retrieving credentials with Mimikatz and posting them to post exploitation toolkits.

When we started working on the tool in August 2019, the choice between Volatility and Rekall was easy. Rekall identified the exact operating system version faster and read significantly less data (although the playing field leveled later in 2019 with the beta release of Volatility 3). We used Rekall to write a simple Python module that could analyze a physical memory image and create a minidump of the LSASS process with the help of the Construct Python module. Most of the effort went into writing the data to the minidump file format. It is worth pointing out that our implementation is far from comprehensive. This is because we only write the streams and values that Mimikatz is interested in.

This prototype allowed us to retrieve credential material without interacting with the LSASS process on our target system. We also found that it did not cause an alert in our EDR software which gave us the encouragement we needed to continue. However, the approach was clumsy in terms  of operational security. We needed to exfiltrate the entire physical memory dump which could be anything over 4GB on a modern operating system. Not very subtle. We knew that any savvy blue teamer or security product would identify the exfiltration of such a huge amount of traffic and that we needed to do better.

Incident Response teams have been analyzing the physical memory of devices remotely for quite some time. We wanted to adapt this approach and create something that could be used on our red team operations. We felt the following approach could be used over an existing command and control (C2) channel.

1. Expose the physical memory of the target over a TCP port.
2. Connect to the TCP port and mount the physical memory as a file.
3. Analyze the mounted memory with the help of the Rekall framework and create a minidump of LSASS.
4. Run the minidump through Mimikatz and retrieve credential material.

We already had #3 and #4 but covering items #1 and #2 required a couple of additional components.

Instead of dumping the physical memory to a file with the winpmem tool as we did in our Proof-Of-Concept, we implemented a 'physmem2profit server' which loads the winpmem driver and exposes the host's physical memory over a TCP port on the loopback interface. It is written in C# so that it can be used with Cobalt Strike's execute-assembly command.

Mounting the physical memory as a file was implemented using the Filesystem in Userspace (FUSE) driver. The fusepy Python module is the best thing since sliced bread and Mimikatz. It offers a simple interface to FUSE and with less than 100 lines of Python it was possible to achieve our objective by proxying the read requests over the network to our 'Physmem2profit server'.

Here is a video of physmem2profit in action. Please note, the video was edited to reduce its running time:

The command used in the above video has been provided below. This command assumes that the C# component is already executing on the target and does not account for a SOCKS proxy.

Physmem2profit was developed and tested with a fully patched versions of Windows 10. A typical execution time with a good network connection is around two minutes. The amount of data transferred over the network depends on whether you already have a Rekall profile for the target system. There is some overhead related to parsing the OS data structures. As an example, a Windows 10 system whose LSASS minidump created with Task Manager is 48 MB results in a 88 MB minidump with physmem2profit and a total of 122 MB of data transferred.

You can find Physmem2profit on GitHub.

It is important to note that the purpose of Physmem2profit was not to create a silver bullet that magically bypassed all EDR software (even though that would be great). The purpose was to rethink credential theft, propose an alternative approach and create a modular framework that can be extended to support additional drivers. The tool is still in its infancy so we welcome feedback, ideas, pull requests, and bug reports.

What we have at the moment is a PoC that supports winpmem. But, we hope that in time Physmem2profit can become a part of the red teamer's toolbox. Several drivers provide opportunities to read physical memory (including most EDR products), adding support for them is as easy as creating a C# class that inherits some existing functionality.

More information on contributing to the project can be found on the GitHub page.