Creating memory dumps for Volatility using Tycho

April 3 2020

by Philipp Barthel

In this article I present a python script that combines Tycho and Volatility in order to analyze physical memory from a target machine. This is especially important when dealing with unknown malware samples. Unlike other approaches, Tycho allows an analyst to carefully monitor processes without ever having to fear that the malware could detect the analyst - read more about this here. For example if a machine is suspected to be infected by some unknown malware, Tycho can be used to extract the possibly malicious program for further analysis using Volatility and a special Tycho Python script, that I developed during my internship and present in this article. The script is able to reliably create memory dumps of a target PC which have the right format to be analyzed by Volatility.

The Situation

Let’s stick with the example we were just talking about: Unusual network behavior has been detected, the computer that is causing these issues has been identified and you are tasked with finding out what is going on. So what do you do when you expect a computer could be infected without altering the machine’s state or even destroying evidence? You start the PC and check your preferred AV-Software for abnormalities, check if any popups appear, check if the machine seems slower than it should, etc. - you know the drill. But there is no apparent issue that would account for the suspicious network activity.

As a result, you decide to take matters in your own hands and dig deeper by analyzing the machine’s physical memory. Offline analysis of the memory is key here, so dumping the machine’s memory is the way to go. But installing or executing tools on the machine itself would, on the one hand, alter the machine’s state, which could lead to an altered outcome, and on the other hand, could be detected by malware which is trying to conceal itself. Therefore we have to act somewhat remotely and without being detected while dumping the memory.

First of all we have to identify the process that is causing the suspicious communication patterns and then verify if this process is faulty or even malicious. To check on a specific process, extracting the executable is key, because malware often tries to conceal its signature by loading code from DLLs or the web. By extracting the executable from physical memory an analyst would possess the finished malicious code as the malware was running and therefore completely loaded.

What Is Needed

A working Tycho setup is crucial for this as our virtualization platform Supernova needs to run beneath the operating system of the suspicious machine. But do not worry, setting up the system to boot Supernova before continuing to boot the already installed OS is done very quickly. Since Supernova is able to unrestrictedly access the machine’s physical memory, it can also see memory we do not want to include in the memory dump. This for example includes memory regions used by devices to communicate with the CPU and the space Supernova has to claim for itself but we only need the regions that are considered RAM by the OS.

Fortunately there is a Microsoft tool named RAMMap which tells us exactly what memory regions - in RAMMap they’re called Physical Ranges - we need. We will also need the memory dumping script to actually dump the physical memory and Volatility for analysis. Volatility is a very powerful open-source memory forensics framework which is widely used to analyze memory dumps, for example in order to combat malware.

How Other Memory Dumpers Work

Usually a memory dumper can by default only access the system’s user mode memory but not kernel memory, because of privacy reasons. These dumpers would fill the kernel memory regions of a memory dump with zeros or random data to ensure all existing offsets are still sound. Naturally, the Tycho-based memory dumper is superior to these dumpers as it can dump kernel memory as well.

Now there are ways existing dumpers use to dump kernel memory too. Using Microsoft’s own memory dumping functionality within sysdm.cpl for example is able to generate complete dumps but you have to make the machine crash in order to do so. Crashing the machine also has one advantage though as all physical memory remains exactly the same it was when the machine crashed. This means nothing can change within the physical memory while it is being dumped. This is quite impractical when trying to analyze malware at specific points, as you wouldn’t want to stare at the screen for the right opportunity to crash the machine.

Lastly there are dumpers which can create full physical memory dumps by providing their own drivers. These drivers have access to kernel memory and can therefore create full dumps. But there are drawbacks here as well as these dumpers often have their own formats which do not comply with Volatility.

Why You Should Use the Tycho Memory Dumper

Tycho grants the great benefit of being undetectable by the target PC since it is not running on the analyzed machine itself. Seeing as it’s even undetectable for the OS, malicious software could never detect Tycho or realize that it’s being spied on. The other dumpers on the other hand have to be executed from the target PC itself, which can lead to problems, as malware could detect the dumpers or to some extend prevent dumping in its entirety. This is because malware often tries to hide from analysts because once it’s spotted and extracted, AV Software can add the malware’s signature to their database or it could be reverse engineered.

Though the Tycho-based memory dumper needs the overhead work of configuring the machine file once per target PC, it still offers the most stealthy approach. On top of that the dumper can be used at specified breakpoints, e.g. whenever the malicious software creates, or writes to a specific registry key which could be analyzed by using Volatility. One downside though would be the time needed to dump all physical memory. In my tests it needed about 45 minutes to one hour for 4GB of RAM, which results in the possibility for processes to basically slip through while dumping. The problem could be solved by halting the machine or all user processes though.

Volatility

Volatility is the tool to pick when analyzing physical memory, as it is not only able to determine the Windows version of the machine but can do a whole lot of things, including:

  • creating a rough screenshot of what the desktop showed at the time the RAM was dumped: screenshot
  • extract the clipboard (copy/paste): clipboard
  • extracting values from specific registry keys: printkey
  • show task list and processes which try to conceal themselves from the active process list: psxview
  • extract an executable that was running while the dump was made: procdump

How the Tycho Memory Dumper Works With Volatility

In our case the Tycho-based memory dumper creates a .raw file that is fed into Volatility. As mentioned before, especially interesting is identifying the process that is causing issues and extracting the corresponding executable for more in depth analysis. This can be accomplished by running psxview for example, as every process that tries to hide itself in the active process list is most certainly malicious. The next step is to extract the executable by using procdump. Doing this enables the analyst to reverse-engineer the process for further analysis or upload it to sites like virustotal. Compared to analyzing the executable from the target’s hard drive, extracting it from the memory dump ensures that dynamically loaded code is present as well, which is not necessarily the case otherwise. This makes for a higher chance of yielding results overall.

RAMMap

RAMMap is very easy to use. Once we have downloaded and unzipped the folder simply execute RAMMap.exe with elevated rights. Navigate to the tab Physical Ranges and it will show all values that are needed to configure the machinefile.json on the analyst PC. Both the Physical Ranges tab and the machinefile.json are shown below.

This image shows how RAMMap could look like on a target machine.
This image shows how RAMMap could look like on a target machine.

The corresponding machinefile.json on the analyst PC would look like this:

The Memory Dumping Script

At first the script validates all parameters and prerequisites. It also allows the user to specify a custom machine file in case the user has several machines they want to check regularly. The machine file is also used to determine what regions have to be dumped. The space in between the regions is filled with zeros to ensure all offsets within the memory dump remain intact. After the padding is done, read_physical(start_addr, size) allows to read physical memory directly from the target PC.

Summary And Prospect

Memory analysis is key when working with malware and as malware does not particularly like being analyzed it is best to stay undetected while doing so. The most commonly used tool to analyze physical memory is Volatility and thanks to Tycho’s ability to work without being detected, an analyst would never risk altering the state of a target machine or have the malware realize it’s being spied on. This pair has proven to be very effective in accomplishing this task.

It is noteworthy that dumping physical memory with Tycho can be time-intensive - in my tests dumping 4GB took about 45 minutes to one hour. This is not as bad though, because Tycho allows an analyst to dump automatically at set breakpoints. Although this can be somewhat mitigated by the fact that Tycho allows the analyst to automate the dumping process, the time could possibly be reduced if chunks of memory transmitted from the target PC to the analyst PC could be either compressed for transmission or the amount of memory to dump could be reduced. The latter can be achieved by dumping just as much physical memory as needed by Volatility. It would therefore be worth researching if it is possible to have Volatility tell Tycho what memory regions are important instead of dumping all physical memory.

On top of all that, it can be advantageous to always have an inactive Supernova and Tycho instance running on some machines or servers if these are prone to being attacked. This would run with neglectable overhead and whenever something out of the ordinary happens, all processes on the specific machine could simply be halted, the physical memory dumped for offline analysis and the processes could be continued.


Share this article: