Memory acquisition

For many years, the main technique for conducting digital forensics was analysis of hard disk images. Certainly, if a hard disk image is available, we have a good chance of getting a lot of data to resolve the incident. However, this approach has some disadvantages.

Modern hard drives have a huge size, or sometimes we have to deal with RAID arrays, so analysis of such large amounts of data will require a long time. Also, Full Disk Encryption technology could be implemented and without encryption keys it will be not possible to get access to the files on the disk. Moreover, analysis of hard disk content does not always give the whole picture of what was happened at a particular point in time. Also, today there is a lot of bodiless malware; in this case, malicious code is not presented in the filesystem as a file.

All these listed facts force a forensics specialist to seek new alternative ways to solve forensics tasks. So, researchers look at the RAM as an alternative source of information.

As well-known and modern PCs are built on the von Neumann architecture, any piece of code which is executed on the computer should appear somewhere in the memory. The memory could be a useful source of evidence. Another advantage of using memory is its small size. Despite the fact that nowadays a user's workstation has more and more RAM, it still has a far smaller size than modern hard drives. However, for a long time analysis of memory was not widely used. The process of memory analysis was just scanning dump memory to search some strings. This situation changed when tools such as Volatility Framework appeared.

So today, memory forensics is no longer optional but is a compulsory step for a professional investigation. However, before memory analysis, we should first get to the dump of the memory, and we should do it in the right way. Otherwise, even with powerful tools, such as Volatility, the analysis of memory will be unsuccessful.

There are a lot of tools which allow creating memory dumps for any operating system—MS Windows, Linux, or Mac OS X. Some of them are very simple, and all you need to do is just push the button. However, the professional should understand how it works and be ready to fix problems in case they happen.

Issues related to memory access

Now, let's discuss some of the issues that are related to memory access on MS Windows. In MS Windows, there is a \Device\PhysicalMemory kernel object, which presents direct access to the physical memory of the system. To get the contents of the memory, we should read this file. Before Windows Server 2003 SP2, a given file was accessible from the user's space. However, starting from this update and in all later versions of MS Windows, this object is accessible from kernel space only. User space applications can read this file, but to open and edit it, the kernel space code or driver is required. Moreover, any manipulation of this object is a dangerous operation. The device memory is part of the physical memory, which is mapped to other devices in the system. This is the area of memory for devices, such as graphics cards, mapped to this part of physical memory in such way that the operating system could send data to such devices. Some particular blocks of memory are reserved for these devices and data that is written to these addresses are sent to the device. Thus, the writing or the request for access to this area of memory that is reserved for the device is translated into a request, which is sent to a real device.

How the request will be handled by a device depends on the device. Also, it could cause the system to hang or crash and destroy evidence. So, the software and the hardware that are used to dump memory should exclude these areas of memory from the process. We suggest testing all tools before using them. Besides the problem just described, there are malware which could change the behavior of tools and change the result of memory dumps.

Although we have never faced such malware in real life, there are a few PoC written by some researchers which could prove this threat. So, if the process of memory acquisition fails, this could make the system crash and cause a loss of data as well.

Choosing a tool

To choose a tool we need to answer the following questions:

  • What is the supported OS version?
  • What is the supported hardware architecture (x32, x64)?
  • What is the required privilege level?
  • Where are the results stored?

Today, there are a lot free and commercial tools on the market that support all versions of MS Windows that we could use to dump memory:

We need to note that the commercial tools are not always better. Which tool we should use depends on the case of usage, experience, and qualification of responder, and on other factors.

Despite all the possible options, the principles that we suggest for you to follow are the same:

  1. Minimize impact to the system.
  2. Run the tool from a safe environment.
  3. Store results outside the system.

We will divide all use cases into three groups with two approaches, hardware and software:

  • Locally
  • Remotely
  • Post mortem

Each of them has their own advantages and disadvantages. For example, let's take a look at the hardware approach. In this case, administrator privileges are not required, but you should have local physical access to the PC under investigation. The given approach is based on Direct Memory Access (DMA) and some technologies, such as Fireware, Thunderbolt, ExpressCard, or PCI. The disadvantage of this approach is that you need to install some hardware and software into the system before you can use it. Also, this action requires a reboot of the system. So, doing this could destroy some evidence. Another disadvantage is the limitation of the 4 GB memory size, which we can dump using the FireWare technology. However, solutions based on PCI are rare and expensive.

As we mentioned earlier, there are a lot of variants of use cases. Therefore, it is impossible to observe every one of them in a single chapter.

The most simple and prevalent case is the local software approach. In this approach, we can use a number of utilities, and we will look at some of them now.

DumpIt

In cases where the system has no more than 4 GB of RAM, the DumpIt utility is a good choice. DumpIt has a very simple command-line interface, and it is easy to use even for an inexperienced person. To dump the whole system memory, you should copy it to some removable device with enough space to store the memory dump. Then, plug this device in to the system and run it from the drive. After running this, DumpIt will create a file that contains the memory dump of the system in the same path from where DumpIt was executed:

Unfortunately, the free version of DumpIt doesn't work correctly with memory more than 4 GB.

If you have 8 GB of memory or more, we suggest using Belkasoft Live RAM Capturer. This software also has a simple graphical interface. It works on both architectures: x32 and x64 bits:

FTK Imager

One more popular utility for memory dump is FTK Imager. It is also free. There are two versions of it. We suggest using the FTK Imager Lite version. It does not require installation, has an easy-to-use interface, and has a lot of useful features:

Acquiring memory from a remote computer using iSCSI

Another common scenario is the acquisition of memory from a remote computer. Consider the case when we need to dump memory from a remote Windows workstation using different operating systems including MS Windows, Mac OS X, and Linux. To do this, we can use the iSCSI protocol. Internet Small Computer System Interface protocol was developed in 1998 by IBM and CISCO. This protocol allows clients (named initiator) to send SCSI (CDBs) to SCSI storage devices (named target), which are located on remote servers.

Initiator is an iSCSI client and it works as an SCSI adapter except that it uses the IP network rather than physical bus. The iSCSI target is a server that provides a network interface to a storage device. Thus, we should install the iSCSI target on workstation of investigator where we will store the memory dump. There are a few free implementations of iSCSI for Microsoft and StarWind. Also, F-Response provides features to access a remote PC by iSCSI. Most operating systems have a free built-in initiator client software, including MS Windows 2000 SP4 and higher.

So, in our use case, we will use our own written iSCSI target software, KFA (Kaspersky Forensics Agent), and the iscsiadm utility as initiator on a Linux station.

To dump memory using Kaspersky Forensics Agent, run the utility on the target system with the -mountphysmem option:

To provide access with authorization, we can use the chaplogin and chapsecret options:

It is now possible to connect to the selected media using any iSCSI initiator:

  1. Now, we test the connection:
    sudo iscsiadm -m discovery -t st -p TargetAddress
    
  2. Having verified that the iSCSI connection is in working order, we establish a full connection:
    sudo iscsiadm -m node --login
    
  3. Make sure that the memory is visible in the Ubuntu environment as a new device.
  4. Now, you can dump it with the dd utility as usual.

Now, you have a memory dump, and you are ready to analyze it!

Using the Sleuth Kit

We want to discuss one more use case. It is possible that an investigator has only a hard disk image and no opportunity to dump memory from the system of interest. In this case, we still have the ability to receive some kind of system memory information. MS Windows saves the contents of memory in the hiberfil.sys file when the system goes to hibernate. So, if we have a disk image, we can extract hiberfil.sys from the disk.

To do this, we need to use the Sleuth Kit. Let's take a look at how we can do this:

  1. To obtain information about partitions on the disk, use the following command:
    mmls image
    

    The output will be as follows:

  2. Then, use fls to list files on the root directory of the NTFS partition:
    fls -o 2048 image.dd | grep hiberfil.sys
    r/r 32342-128-1: hiberfil.sys
    
  3. Finally, extract hiberfil.sys:
    icat -o 2048 image.dd 32342 > hiberfil.sys
    

Now, you can analyze hiberfil.sys with an analysis tool, such as Volatility.