Retrieving Meterpreter C2 from Memory

Posted on 8 May 2018 by Jayden Zheng

This blog post will provide a short guide for threat hunters on how to extract the C2 from a Meterpreter payload that has been injected into memory. We will use Jared Atkinson’s Get-InjectedThread.ps1 script to explain the detection process, then dump the process memory and use WinDbg to carve out the suspicious memory region for analysis.

 

We will also share a one click PowerShell script to retrieve the C2 from the carved memory.

 

Meterpreter 101

Meterpreter is one of the most commonly used payloads contained within the Metasploit framework. Once executed on a target its extensible design allows the loading of multiple modules that go beyond simple shell access, enabling such features as hash/password/token stealing, and pivoting and execution of arbitrary post-exploitation modules. Notably it resides completely in memory and leaves no disk artefacts.

 

The downside to the use of memory injection is that anomalous memory regions are allocated and used by Meterpreter. For defensive teams with memory analysis capabilities, this provides an obvious indicator to search and retrieve for analysis.

 

Post Exploitation Scenario

Imagine an attacker has already gained a foothold in your environment and has been discovered using Jared Atkinson’s Get-InjectedThread.ps1 PowerShell script.

 

Jared Atkinsons Get InjectedThread.ps1 PowerShell script

  

From the output above, we can see explorer.exe was found to contain a thread executing from a non-file backed memory region with an allocated permission of PAGE_EXECUTE_READWRITE. This is a strong indicator that someone has potentially injected a payload into Explorer. The base address and size indicates that the starting address is 139264000 (decimal), which is 84D0000 (hex), and the size of region is 208896, 33000 in hex (we’ll use these later).

 

Explorer payload base address

 

 To perform further analysis we will dump the explorer.exe process (PID 4956). You can dump a process directly from Windows Task Manager or use a tool such as ProcDump. In this example though we used Process Hacker to dump explorer.exe, simply by right-clicking and selecting it.

 

Process Dump using Process Hacker

 Carving Memory Sections

To make analysis easier, we are going to carve out and focus specifically on the anomalous region that was found within the process memory space.

 

One of the quickest and easiest ways to extract specific memory regions on Windows is using Matt Graeber’s Memory-Tools.ps1. We simply input the Base Address, Size and the Process ID from Get-InjectedThread.ps1 to dump the suspicious region.

Extracting Specific Memory Regions

However, this is only useful if you know with certainty which region contains the malicious code and specifically the C2.


For more general purpose memory analysis, it can be useful to use Microsoft’s WinDbg. Once installed, open your process dump (shortcut Ctrl+D). After its loaded, head over to the “Command” window (shortcut Alt+1) and enter the command “!address –f:PAGE_EXECUTE”; this will display all information about the memory that the process uses and filter on PAGE_EXECUTE.

Memory analysis using WinDbg

A snippet of the output shown above indicates there are four regions of memory that were allocated with PAGE_EXECUTE_READWRITE permissions. Remember from the output of Get-InjectedThread that the base address is 84D0000, which correlates with this output. Also note that multiple sections begin with “MZ” indicate that they potentially contain executable (exe/dll) content. By running the command “!address 0`084d0000”, we can see more information about that region.

Memory analysis using WinDbg 2

To view the actual contents of the region 0x84d0000, you can open the “Memory” window (shortcut Alt+5) and then enter “84d0000” in the filter box, which will show something similar to the shellcode below.

Memory analysis shellcode

You may notice that towards the bottom of the output we can see the MZ header and DOS header. It’s somewhat unusual to not see this at the start of the section; however, in this specific example, as Meterpreter was migrated into explorer.exe the first section of code is actually the Meterpreter migrate stub.

 

We can now carve out that region by heading back to the Command window and entering the command, “.writemem <filepath> <baseaddress> <offset>”.

Carved memory

Section Analysis

Now we have the individual memory section we can begin to analyze it. There are quite a few potential options. Strings and YARA can often give some quick wins, but for more in-depth analysis you’ll likely want to use either IDA or Radare.

 

To aid with visual analysis, we’re going to use a Hex Editor to open the carved file. Once loaded you can begin to search for key indicators such as ws2_32.dll and metsrv.dll, which are used by Meterpreter. The ws2_32.dll is the Window Sockets Library that is used to handle network connections and the metsrv.dll is the default Meterpreter service.

Using a hex editor to open carved memory file 1

Using a hex editor to open carved memory file 2

Manually looking through the hex dump, we found the C2 address of 192.168.1.178 with the port 443, along with the User Agent. 

Using a hex editor to identify C2 address

Using a hex editor to identify C2 address 2

As mentioned, you can also use the strings tool to dump out the contents and then locate the C2 and other key indicators. 

Locating the C2 strings tool

Speeding Things Up

Another way of rapidly analyzing memory dumps is by using YARA signatures. Countercept’s open source malware analysis platform Snake provides a quick and easy way of performing YARA analysis.

Using Snake for YARA signature analysis

 The carved file showed hits for several YARA signatures, such as the APIs used for code injection, as well as those used for network connectivity. This helps confirm that the sample is likely related to Metasploit.

Analysing memory dumps with snake 1

Analysing memory dumps with snake 2

Retrieving C2 using PowerShell

One of the most common investigation steps is retrieval of C2 as this provides greater context and allows you to find other compromised systems. In analyzing the Meterpreter memory dump, we found a number of static markers existed that could be used to locate and extract the C2 directly from memory:

 

  1. Before the start of the C2 string, multiple payloads had a hex value of “00 00 E0 1D 2A 0A”.
  2. The C2 itself would start with a protocol TCP, UDP, HTTP(s), SMB or Named Pipe in hex value and the C2 would consist of null separated ASCII characters.
  3. After the C2 there was at least ten null bytes.

Markers to locate Meterpreter C2

Based on the above three markers, we created a PowerShell script to quickly retrieve the C2 from the carved memory file:

PowerShell script for retrieving Meterpreter C2

You can access the script on GitHub, here:   https://github.com/countercept/memory-carving-scripts/blob/master/Get-MeterpreterC2.ps1

 

A few things to note:

  • While this script runs quite quickly on carved sections, it can take a bit longer on larger memory captures or full process dumps (although should still work).
  • This script has been tested on a number of payloads including “windows/meterpreter/reverse_tcp” and “windows/meterpreter/reverse_https”. It may not work on all Metasploit payloads, although it could probably be updated to support them.
  • If you use this on a carved memory section (as opposed to a process dump), you need to ensure you use it on one that contains the C2 information. Metasploit and other tools will often inject into multiple memory regions and not all sections will contain this information.

Conclusion

Modern attackers will often try to reside completely in memory to avoid leaving any evidence on the disk. It is therefore essential for threat hunters to be able to detect and investigate these memory anomalies quickly and effectively.

 

While this post has focused specifically on Meterpreter, the same analysis techniques can be used to dissect a wide range of memory anomalies and extract useful information. If you are interested to learn more about analyzing memory anomalies, Countercept gave a talk last year regarding Detecting Meterpreter and Cobalt Strike with memory forensics, which can be seen here.