What are the limitations when performing a penetration test with a virtual machine instead of a physical one?
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).
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?
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.