Hacking Virtual Machines pt 4 - Targeting a Virtual Machine

Tuesday, December 07, 2010

Bozidar Spirovski


Hacking Virtual Machines Part 1 - Sniffing HERE.

Hacking Virtual Machines Part 2 - Virtualization Environments HERE

Hacking Virtual Machines Part 3 - Unpatched Hyper-V HERE

Virtualization is considered to be the new renaissance in computing. Suddenly, all those over sized servers are put to great use by putting multiple Guest OS's on them.

But running IT services in a virtualized environment brings a whole host of new opportunities for hackers.

In this article, we'll review the ways an attacker will know that the target is a Virtual Machine. When attacking a virtual machine it is very useful to know that your target is a virtual machine.

This is important for the following reasons:

  • Isolation - once you gain access to a virtual machine, there are a number of isolation vulnerabilities that can be attempted
  • Sphere of trust - all virtual machines on the same Host are part of the same sphere of trust
  • Impersonation - in most implementations, virtual machines on the same host communicate with the rest of the network via the same physical NIC. Therefore it is extremely simple to modify the MAC address of the compromised host and attempt to impersonate another host on the network. The network defenses will have a difficult time locating who is the impersonator, since there are multiple virtual machines on the same host
  • Nobody looks at a screen of a VM - Virtual Machines do not have a console screen. So tools that throw feedback on the console (like VNC) do not appear anywhere.

Identifying that you are attacking a virtual machine can happen in two phases:

Before you penetrate the target - identification of a VM can happen if the attacker is on the same LAN, and can therefore investigate the characteristics of the target.

You can easily locate a Virtual Machine through the MAC address. You can check a MAC address for it's descriptive name here.

Here is the list of MAC addresses that get assigned to Microsoft and VMware Virtual Machines:

  • 00-15-05-xx-xx-xx Microsoft Corporation MAC Address
  • 00-0C-29-xx-xx-xx VMware, Inc.
  • 00-50-56-xx-xx-xx VMware, Inc.

This approach can fail if the VM Engine has a method of changing it's MAC address to 'seem' like a real host. Most often Realtek MAC addresses are used for this change , but this leads to an inconclusive check.

After you penetrate the target - This is a bit like a 'Catch 22': Once you penetrate the target, you have a lot more options, but all these require that you penetrate the target :). And these are your options:

  • MAC Address - just as the previous approach, you can look at the MAC address. And of course, you can hit the same obstacle - the replaced driver with one that is brought by the VM engine which is inconclusive
  • Attack toolkit checkup - Metasploit, Core Impact and most other serious attack toolkits have a module that checks whether the compromised target is a VM. But these can fail miserably, as is presented on the screenshots below. This is why you need a second opinion.


Internal windows tools - there are a whole host of tools that windows brings with itself that can be used to make sure whether you are on a virtual machine.

Here are two driverquery - a simple command-line tool that queries all loaded drivers. If a VM Engine driver set is installed, you'll find a lot of reported information as on the screenshot below:


wmic - WMI command-line tool that can be used to query every possible aspect of a machine. The simplest query is wmic baseboard list which returns excellent information.

In a Microsoft Virtualization, you'll see the following string: "Microsoft Corporation Base Board TRUE Virtual Machine".

In a VMware virtualization you'll see the following string: "Intel Corporation Base Board TRUE 440BX Desktop Reference Platform".

Cross-posted from ShortInfosec

Possibly Related Articles:
Hacking Virtualization Virtual PC Metasploit VMware
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.