Penetration test limitations with a virtual machine

Question

What are the limitations when performing a penetration test with a virtual machine instead of a physical one?

Answer 1

In my opinion performing a penetration test from a virtual machine is actually the preferred way of doing it from opsec perspective (i.e. to maintain separation between your clients' data).

Limitations may arise from the fact that you can't access the underlying hardware directly, in particular:

• Wired network interfaces: some host operating systems (e.g. OSX) will continue using the wired network even if you explicitly disable it in host OS and bridge the virtual machine to it. From the network perspective that means two separate MAC addresses on the same port, which sometimes triggers the NAC.
• Wireless interfaces: most hypervisors don't emulate wireless devices at all
• GPU: if you want to use something like oclhashcat for password cracking, you need direct access to the GPU

That being said most of these problems can be solved by dedicating the necessary hardware to the VM (e.g. PCI or USB passthrough).

Answer 2

I use docker-machine and packer/vagrant with vmwarefusion as my provider. I can check the status of my machines with:

docker ps
vagrant global-status

Vagrant is used for Windows and OS X images while Docker is used for Linux and FreeBSD.

My Kali 2.0 Docker image, for example, started at around 550MB and is now around 1.8GB. I save a lot of disk space this way, and am capable of diffing my images easily to determine what changed and how it changed. I have images for Arch, CentOS, Debian, Fedora, FreeBSD, Kali, Qubes, REMnux, RHEL, Scientific, and Ubuntu.

Accessing my containers is very easy. I can have a brand new OS X or Windows image booted in 15 or so seconds. Docker is much faster -- fractions of a millisecond to attach to a freshly-created running container. I use CTRL+P CTRL+Q to detach, almost like screen or tmux.

In my opinion, it's the opposite effect: I feel limited in my penetration-testing capabilities without virtual machines. I especially feel empowered with containers and Docker-based workflows. Using a single, host-only OS is the real limitation. How else are you supposed to emulate environments, stage tools, or develop new ideas without a constantly-evolving lab?

Answer 3

You may have some packet injection issues as the VM will see the virtual interface instead of the physical interface. This will only effect some wireless attacks.

Other than this I cannot think of any other issues.

Answer 4

In my personal experience, virtual machines don't really matter as long as you do not have programs running which sometimes need direct interaction with certain hardware.

For instance scenarios where you want to directly address the GPU (password cracking) or where you want to perform some low-level network operations it might give you issues.

Furthermore it also depends on the type of virtualization you use.

Answer 5

Theoretically, the only limitations you could face when using a virtual machine are inherent to hardware limitations themselves and this depends fully on the nature of the pentest you want to perform. In practice, you can say there are no limitations in (very) most and common cases.

Answer 6

In my experience with MSF (Metasploit Framework) the more horsepower you can throw at it the better - you will prefer a big powerful VM with a fast WAN connection over a dedicated i3 notebook with 4GB RAM.