Memory Acquisition on Virtual Machines and Cloud Environments

Memory Analysis | Part 4

Similar to the two previous parts, we must make some decisions regarding the memory acquisition process. For this part, we will focus on getting a memory dump from hypervisors and cloud platforms during regular business hours.

We will then choose the right tool or method for the right job. There are two ways to acquire memory from hypervisors and cloud platforms:

• Login into the VM and use the techniques seen in the previous writeups.
• Use the built-in tools of the hypervisor or cloud platform to extract memory without interacting directly with the VM. This can be done via the GUI or the command line

We will learn the methods to acquire a memory dump on the most common hypervisors and cloud platforms, including:

• Microsoft Hyper-
• VMware vSphere
• VirtualBox
• KVM
• Cloud platforms

We will focus on providing a memory dump that is compatible with Volatility.

Acquiring a Memory Dump on Hypervisors

The method for acquiring a memory dump from a hosted VM is similar for each flavor of hypervisor. First, we need to take a snapshot or pause the VM. Then, we can take a copy of the memory state file that each hypervisor creates when snapshotting or pausing a VM. Depending on the flavor of hypervisor we will need to convert the memory state file to be compatible with Volatility.

Note: There are alternative methods to acquire memory. This part will focus on using the built-in tools and/or utilities when available.

Microsoft Hyper‑V

Acquiring memory on a Hyper‑V hosted VM can be done with the native functions of Hyper‑V. We can choose to use either the GUI or the PowerShell command line. The terminal below shows the process using PowerShell. The steps for GUI and PowerShell are virtually the same:

• Save the VM or take a checkpoint via the GUI or PowerShell cmdlet (Checkpoint-VM or Save-VM)
• Navigate to where the snapshots are stored and copy the .vmrs file, which contains the RAM content
• Calculate the hash to ensure integrity when analyzing the memory dump later on
• Use the volatility windows.hyperv plugin to process the file

get-vm | FT VMId, VMName
get-vm -Id c5f1b464-ffea-4904-bc7b-974c74b10159 | Checkpoint-VM
Get-VMSnapshot -VMName 'Ubuntu 22.04 LTS' |FT Id,Name,Path
cp C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\97DBBAE5-3F91-4E5E-B177-FBB970E8703E.VMRS C:\temp\hostname-17-04-2025.VMRS
Get-FileHash -Algorithm MD5 -Path C:\temp\hostname-17-04-2025.VMRS

vSphere

In vSphere, we can use the built-in tools (vCenter server + vSphere client) to take a snapshot of the VM. We can use either the GUI or the ESXCLI tool. The steps to acquire the memory are similar:

• Take a snapshot of the VM
• Navigate to the datastore where the VM is located and copy the .vmsn file
• Calculate a hash to ensure integrity
• Volatility supports the processing of .vmsn files, so we don't need to convert them

KVM

The easiest way to acquire a memory dump of a VM hosted on KVM is to use the command line utility. The steps are similar to other hypervisors:

• First, find the name of the VM. Use the virsh list command to list all VMs
• Then, dump the memory of the VM by entering:

virsh dump vmname /path/to/dump.raw --memory-only

• Lastly, create a hash of the memory dump file:

md5sum memdump.raw

VirtualBox

The recommended way to acquire the memory of a VM hosted on VirtualBox is by using the VBoxManage tool. On a Windows installation, we can find this command line utility in the installation path of VirtualBox (e.g., C:\Program Files\Oracle\VirtualBox). Follow the next steps to take a memory dump of the VM:

• List the VMs running and find the name of the VM
• Take a dump with the debugvm command
• Calculate a hash to ensure the integrity of the file later down the analysis process
• Volatility supports the processing of .elf files, so we don't need to convert them

.\VBoxManage.exe list runningvms
.\VBoxManage.exe debugvm "Kali_purple" dumpvmcore --filename C:\temp\kali_memdump.elf
Get-FileHash -Algorithm MD5 -Path C:\temp\kali_memdump.elf

Acquiring a Memory Dump on Cloud Platforms

Unlike hypervisors, the process of acquiring a memory dump from a VM hosted on a cloud platform like Azure or AWS is not straightforward. Neither platform comes with a built-in tool to accommodate taking a memory dump. In this case, we won’t be able to avoid interacting with the VM directly. One of the main reasons cloud providers don’t offer this tooling is due to the shared nature of the hardware resources.

Get Iram Jack’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The recommended way to acquire memory dumps from a VM hosted on a cloud platform is to follow the steps specific to each OS that we discussed in the Windows and Linux parts.

There is, however, an alternate method that is used in some scenarios. This method involves the following steps:

1. Configure a full memory crash dump on the host
2. Trigger a manual crash via the cloud platform
3. Detach the disk where the crash dump was saved
4. Connect the disk as a read‑only data disk to an analysis VM hosted within the same, or different, tenant
5. Extra step: Export the disk so it can be used in a different tenant

Special Mention for Azure

Microsoft released a tool named Acquire Volatile Memory for Linux (AVML) to make the process of acquiring volatile memory on VMs hosted on Azure easier. One of the main advantages of this tool is that it does not require any installation or kernel loading — it can be run as a standalone binary. Note: The tool is intended to acquire memory on Linux distributions only.

Challenges with Memory Acquisition

Memory acquisition does come with some challenges. Take the following difficulties into account before starting the process of memory acquisition:

• Anti-forensic techniques: An attacker can employ anti-forensic techniques to impede proper memory acquisition. E.g., encrypting memory content, interfering with acquisition tools, and more
• Timing: It is essential to get the timing right when acquiring memory. As mentioned in task two, memory is volatile, and its content is continuously changing. Keep an eye on the Indicators of Attack and Compromise to choose the right timing
• (Physical) Accessibility: To do a memory capture, you need to have access to the system, locally or remotely. Sometimes, servers are in data centers that are not accessible without proper verification. Ensure that the correct people have the correct access rights
• No admin rights: To do a full memory capture, you must have administrator rights. This can be on the host level, domain level, or resource group in the cloud platform
• Lack of an Information Security Management System (ISMS): Before even thinking of forensics, you must have a proper ISMS in place. An important part of an ISMS that lists essential information required for memory acquisition is Asset Management. It helps you know each asset’s:
• Details (Hostname, IP, OS, users, physical location)
• Criticality
• Operating hours
• Baseline configuration
• Baseline behavior
• And more
• No transparent incident response process: Failing to take all of the topics in task two into account will impede you in doing proper memory acquisition. Ensure to include the memory acquisition process in your incident response plan

Conclusion

In this part we learned how to capture memory on a Windows host, a Linux host, a VM hosted on a hypervisor, and a VM hosted on a cloud platform. We noted multiple ways to get a memory dump, either via the GUI or a command‑line utility. Lastly, we observed that cloud platforms generally don’t offer built‑in tools to take a memory dump without interacting with the VM.

Taking a memory dump isn’t exactly rocket science, but there are several important considerations reiterated from previous parts:

• Timing — capture when artifacts are present and avoid high‑change windows
• Permissions — ensure administrator or equivalent rights on the target host
• Tool selection — use a tool that fits your use case and platform
• Naming convention — define and follow a consistent naming scheme for memory dumps
• Integrity — hash every capture and record the filename and hash for later reference
• Documentation — ensure all steps, tools, filenames, and hashes are part of your IR playbook

[Keep your IR playbook close. Your dumps, your rules.]