Easy VM Memory Dump/Forensics using VMware

Getting a raw memory dump of a VM is super easy when using VMware. After the VM is up and running, simply pause the VM. This will create a *.vmem file in the directory the VM is stored. This vmem file is the raw memory dump.

windows_vmem

you can now take this file and run memory forensics tools against it, like Volatility, without the need for any sort of conversion.

volatility_vmem

Note: This process is only this easy with VMware products. After a quick test on virtualbox, it turns out virtualbox doesn’t store the memory as it’s own raw dump file when pausing the VM. If you take a snapshot of the Virtualbox VM while it’s running, it will create a *.sav file in he Snapshots directory where the VM is stored.  According to forum posts I read, this file includes raw memory data, but also includes a lot of other information, so you cannot use this file directly for memory analysis. I tested volatility against a .sav file, and it didn’t work.

VMWare Workstation – Working Around Lack of SPAN Ports to Monitor VM Traffic

VMWare Workstation lacks the ability to create a SPAN port, or any other method to mirror traffic and direct it to an IDS. The below will outline my quick and dirty method to work around this limitation. I have not tried this with VirtualBox or VMWare Player, but I am guessing it would work the same way. The main thing is to make sure all systems are on the same virtual network.

TL;DR: On the IDS system, assign an IP address to the monitoring interface and set up a netcat listener. On the machine you want to sniff traffic to/from, use tcpdump or windump to write data to standard out and pipe it to a netcat connection to the IDS netcat listener.

Detailed Description & How-to:

Scenario: You have 2 VMs, an attacker system and a victim system. You want to add an IDS VM to see how traffic and attacks look when exploiting the victim from the attacker.

For this example, the OS in each system is as follows:

  • Attacker VM – Kali Linux
  • Victim VM – Windows XP SP2
  • IDS VM – Security Onion

If you are not using Security Onion as your IDS, the steps should be the same. Ensure the IDS has an IP assigned to its monitoring interface and that it’s in promiscuous mode. Then set up the netcat listener and connection as outlined below.

Changing Security Onion’s monitoring interface configuration:

The default Security Onion monitoring interface is configured like so:

default monitoring config

You will need to change the interface configuration type to static, with a static IP and netmask, and turn ARP back on. Example configuration below.

updated monitoring config

Once changed, restart networking or reboot the system so the changes take effect. Then set up a netcat listener on the IDS/Security Onion system.

Setting up netcat to receive data:

Example command on IDS (in terminal):

nc -lnp 54321 >/dev/null

We are redirecting the output from the netcat listener to /dev/null because we don’t want to see the data on the screen, we just need the data to hit the interface so snort/bro/whatever can see and process it.

Setting up netcat to send data to IDS:

Example command to send all traffic to and from monitored host to IDS (in terminal):

tcpdump -w – not host <IP of IDS> | nc -n <IP of IDS> 54321

Note: In the above scenario, this could be done on the victim or attacker box, it doesn’t matter.

This will run tcpdump, writing the binary data to standard output (the ‘-w -‘ options do this) while excluding traffic to and from the IDS system. We then redirect the output to a netcat connection to the IDS.

If you want to do this on a windows platform, you will need to use Windump instead of TCP dump but the syntax is the same. However, neither Windump nor netcat come with Windows, so you’ll need to download these programs onto the Windows systems first.

And that’s it! A quick and dirty way you can test IDS rules and signatures in your home VMware environment.