Testing Malware in one Virtual Machine which is running side by side along with other Virtual Machines

Question

I want to harden the security of my host system and side by side running virtual machines while testing some files for malware in one of the virtual machines. Here comes a list of questions that I hope you can answer.

- Network Adapters
One thing that I am worried about is the possible spreading of malware from one virtual machine to another. Most of the virtual machines i am executing side by side at the moment are using the same network adapter. Could I somehow minimize the risk by allocating a separate virtual network adapter to the virtual machine I am using for malware testing purposes?

- Separation of Networks
I have read about separating the networks in some other threads. Could I achieve this by connecting an additional network card to my pc and connect the machine that i use for testing the malware to one of the cards? Furthermore I have read that one way to achieve separation would be to disconnect the machine from the network. For my work the internet connection inside all virtual machines and inside the host system is essential at all times so I will have to exclude this possible solution.

- USB Device Drivers
Studying another interesting thread covering the same subject I have come across the claim that a mouse driver could possibly allow a buffer overflow attack. Here is the link to the addressed thread, the post was created by Tim Williams.

Could somebody please explain if the mousedriver would have to be installed inside the guest system or would it be enough to have it running on the host system to cause the vulnerability?

- Mouse integration
Furthermore I have assimilated the information that the mouse integration (the plugin or option that makes mouse movement from the guest to the host machine flawless) could be a possible vulnerability. Is it really better or even necessary to disable this option to harden the security?

- Separating CPU Cores.
Do I have to worry about the guest VM using the same CPU cores like the host system? Is there a way to allocate for example one CPU core to one VM?

Answer 1

Network questions: All your network related questions are basically down to the malware been able to talk with other computers on the network to. So, if the other devices outside of your guest machine are vulnerable then you're exposing your whole network. You'll want to have different NATs so they can't talk to your host machine or any other device on your network.

Separating CPU Cores Yes, you can allocate certain cores and set an execution cap (Though this would depend on what VM software you download.)

How secure is my VM It is possible for malware which executed inside the guest machine to execute outside of the VM. I'll get you references when I'm at home. So, don't believe because you are running VM that your host machine is secure.

Answer 2

Just as a general rule, virtual machines cannot isolate against kernel mode malware that is VM aware. They are really only an effective containment for user mode malware. For user mode malware, or kernel mode malware that is "passive" (ie does not attempt to screen the kernel environment), the VM will contain it reliably so your measures are unnecessary.

If, on the other hand, the malware operates in the kernel and is VM-aware you cannot reliably contain it by adjusting interfaces, because one way or another it will be able to escape if it wants to.

There are several reasons for this, but the first thing to understand is the difference between emulators and VMs. An emulator actually pretends to be the actual hardware, so for example, you could install a wierd new driver for the hardware on the VM and it would theoretically work because the emulator (theoretically) behaves just like the real device. In reality, even if the emulation is absolutely PERFECT (which it never is), malware can always tell it is dealing with fake device because the device will be really slow compared to a real one. Nevertheless, as long as the emulation is perfect and perfectly firewalled, there is nothing the malware can do because the emulation prevents access to the real device.

A VM on the other hand does not emulate the hardware (except in a limited way). To get better performance it just passes through commands to the real device, acting as sort of a buffer. If the malware is running in the kernel, not only can the malware talk to the real device, but it is easy for it figure out it is talking through a VM interface, because the interface is runt. For example, Qemu emulates a Cirrus Logic GD5446, an ancient card that nobody would really use. If you see it, you know you are talking to Qemu. Since the malware is in the kernel, it can do anything a kernel driver can do and it can see all the other "drivers", including stuff like guest additions that make the VM obvious. So, there is no way to fake it out with the synthetic drivers VMs use.

Why You Don't Have to Worry

Having said all that, you don't really need to worry about isolation, because 99.999% of malware will not do anything that will affect the host system. Nearly all VM-aware malware is only interested in detecting a VM so it can do one thing: stop. A situation where the malware detected it was in a VM and then attempted to move around in the host system would be so rare as to be nothing you would have to worry about. And, trust me on this, if you are dealing with malware that is interested in and capable of penetrating to a host system, you are dealing with an entity way beyond your ability to control with some simple measure like fooling around with network adapters.

Anyone who has the money, time and motivation to write code that will compromise a VM will not mess around with devices. He will just write an exploit for the hypervisor and gain direct control of the system. You are talking about a handful of teams in the world that can do this, and even then you have to ask "why would they want to?"; people running VMs are not their targets.

Short version: don't worry about it.

Answer 3

So I have some advice about the Networking side of things. Here's a nice little setup I use:

1. The malware machine. Put it on an internal network adapter, and assign it a static IP address. Take note of the netmask and the gateway.

2. The listener. Put it on the same internal network adapter as the first. Assign it the IP address of the malware machine's gateway, and give it the same netmask. Then, change the gateway of the listener to 0.0.0.0. This stonewalls all packets, so the malware doesn't actually reach the outside world. Additionally, remove all other adapters so traffic doesn't accidentally escape.

Now, run Wireshark on the listener for network activity. Everything is flowing to the "gateway", so you can hear everything. From there, you can build the malware a facsimile of what it is looking for. It's looking for 134.123.123.xx:8080? Add that ip address to a virtual adapter on your listener, and open a netcat listening session to see what it does next. It wants an IRC server that accepts its credentials? No problem, we can spin up a customized IRC server for it.

This is all very tedious, but it's safe as far as I can tell. For added insurance, you can run Wireshark on your host os, and listen to traffic on your subnet. If strange packets start appearing, just kill the machines.